Are we truly working together?

Government wants to work smarter with citizens and deliver high quality end-user services that provide transparency to the end user through omni-channel and cross-organisational working.

A key word to aid this, is ‘collaboration’:

  • Collaboration between service providers and users (through user research, user testing, product increments, etc)
  • Collaboration between organisations (sharing of data, joint decisions on process development, sharing human and technical resources)

Or at least that’s what we think it means. Considering the two main definitions perhaps we can understand why there is confusion on what collaboration actually means:

1. work jointly on an activity or project
2. cooperate traitorously with an enemy

Working on cross organisation projects to improve the sharing of information I’ve seen issues with this in practice. Collaboration should be 1, but sometimes appears more as 2. Why is this?

In my experience people are willing to ‘work jointly’ as long as their own organisation’s agenda isn’t put at risk. Consider from my previous blog post ‘Lead by listening’  when I suggested that it’s “important not to be too protective of your domain. If a decision elsewhere could greatly affect your area of the business, but is better for the positive growth of the organisation, then perhaps embracing the change is the better option?”

Surely this must be true for effective cross-organisation collaboration. What I see in reality is programmes of work that stall with the realisation that one organisation’s vision or current way of working may suffer distruption even if it’s for the common, overall good. Often we arrive at this junction where one organisation must invest for another to save.

perhaps we need to re-define what collaboration means.

Perhaps we need to include empathy in how we collaborate. By stepping into the shoes of our partner organisations and seeing how proposed changes affect them directly could help us understand how to genuinely work together to make the positive change we seek. If we can’t manage this then we’ll find we need to re-invent the definition of collaborate:

Collaberate : verb. (collaborate merged with berate) – being happy to work together, right up until the point you feel your domain is threatened by those you were collaborating with, and then turning on them.

Let me know what you think by leaving a comment below.

Is ITIL dead?

Why ITIL must adapt if it is to remain relevant in the Digital era

ITIL is dead! A contentious view? Almost certainly, and I don’t think I’d need to throw a stone too far in any direction before I hit somebody that fervently disagrees with me.  So why do I say this?  One word – Digital.

Don’t get me wrong, ITIL still has its place, and many, many organisations are still using it just fine, thank you very much. But the writing is on the wall.  Digital is here to stay, and slowly but surely (and in some cases very quickly!) we are beginning to witness a wholesale shift in enterprise technology strategy from traditional, legacy IT service delivery to a model that is embracing the Cloud (in all its guises), platform and device mobility, automation (everywhere!), and focus that places customer experience front and foremost on the list of priorities.

Whilst ITIL can and does still enable the delivery and support of these technology objectives, it is rapidly being considered ‘clunky’, and organisations are increasingly seeking to adopt more flexible operational governance that aligns more sensitively with the change cadence required, nay dictated, by such advances.

Digital technologies, by their very nature, tend to be fast moving and highly volatile. Development of these technologies predicates an equally fast moving service lifecycle to ensure that customer expectations are both met and maintained in a customer environment that now demands swift and constant improvement and innovation.

Agile is one part of the industry’s response to this challenge.

The recent proliferation of tools and techniques to support Agile delivery frameworks is an indicator of the steady rise in adoption of iterative work cadences, and the reality is that many traditional ITSM framework implementations simply aren’t geared up to support this approach.  In many cases, ITSM actively works to impede the delivery of change in an agile manner, and this creates a very real dilemma for IT service management leaders.

The crux of this dilemma is as follows:

  1. Many of the core ITIL processes have been designed to protect production operations from the impact of change, and manage any impact of that change accordingly
  2. Agile (and supporting frameworks) have, however, been designed to increase the velocity of change, and the flexibility by which it is prioritised

As every Change Manager will no doubt surely confirm, increasing the rate of change (potentially to daily or even hourly increments) can put major stresses on a process not necessarily designed to work at this pace. Equally, the concept of ‘trust’, so fundamental to the Agile methodology, may sound great in theory, but is not so alluring in practice when you’re the Head of IT Operations with SLAs to meet and audit controls to adhere to.

In the Waterfall world change, to a degree, works coherently with ITIL and the phased approach to delivery (design, build, test), gives service management functions the time and space to perform the necessary activity required to protect service.  In an Agile world, however, this paradigm is challenged, and what were very well structured, methodical, and well understood governance controls, suddenly become a blocker to the realisation of business value (at the pace with which the business wants to realise it). In some cases this can happen almost overnight, as businesses take the decision to cut to iterative software development methodologies in a big bang approach, often with scant regard for the impact on service management and operations functions.  Almost instantly we witness the clash of worlds (Old versus New).  And word to the wise my friends, the business is normally championing those in the New camp.

It is at this point that we hit the dilemma.  What takes priority – the rapid realisation of business value through the swift release of change, or the protection of production systems (and thus the customer experience) from potential availability or performance degradation as a result of change?

The answer depends heavily on the type of organisation and system/service being changed, but of course the real answer is that both are equally important.  The issue, however, is that Agile is considered new, revolutionary, and progressive (it isn’t really but that’s beside the point). ITIL, on the other hand, is considered by many to be overly bureaucratic and a constraint to the realisation of business value. And remember, perception is reality, especially when those doing the perceiving also happen to be holding the purse strings.

The result is that IT service leaders, in the face of a business strategy that promotes a fast pace of change that it is perceived to be constrained by service management control, quickly become guilty by association. An inability to respond quickly to this challenge will only compound the issue.  The next logical step from there is the disintermediation of IT altogether, as business change leaders look to more flexible ways to deliver value to their customers, unhindered by legacy constraint.

To avoid this scenario IT service leaders, and the processes that they adopt, must adapt. Long term proponents of existing models must wake up to this notion. This change train is most definitely coming and it’s not showing any signs of slowing down.  We have a lot of baggage to carry, so getting on the train will be hard, but it’s also absolutely necessary (I think I may have stretched that analogy a little thin).

Thus ITIL, whilst perhaps not dead per se, is certainly badly wounded and in desperate need of triage.

As Ralph Waldo Emerson is famously quoted as saying, nothing great was ever achieved without enthusiasm. Well now is the time to get enthusiastic, because if enough of the community are, perhaps ITIL might just survive after all.

What do you think? Leave a reply below or contact me by email.

Improving outcomes with multi agency partners

I was recently speaking to a senior local government officer about her experiences of the difficulties in creating shared services and multi-agency arrangements with local organisations. We agreed that the logic of collaboration to improve performance and generate efficiencies is compelling, but in practice achieving such arrangements has proved to be more complicated. We concluded that although the business logic is often sound one of the biggest hurdles to climb is the practical issues that often have to be overcome to create collaboration.

These difficulties may surface because of differing priorities, differing funding methods, complexity or just simply due to timing.

Recently Sopra Steria has been considering how our experience in developing IT and digital solutions can support the development of the multi-agency arrangements that are becoming more and more important in improving outcomes in some of our most crucial public services. Increasingly, agencies are coming together to ensure that by working more closely together they can improve outcomes to particularly vulnerable sections of the community. We see many excellent examples of partner organisations coming together to break down traditional barriers to put the service to the customer to the fore- front.

However, as in my recent conversation, we often hear how difficult it is to achieve and also how difficult it is to achieve the desired outcomes even when arrangements are developed. It has become clear that whilst multi agency approaches are now being seen primarily to support safeguarding and protection agendas. There is also further opportunity to embed the approach across the public sector to improve wider outcomes and to perhaps support more efficient ways to deliver diverse services.

We have considered how we can best support multi agency arrangements through initiatives such as improved use of shared data to support strong business intelligence and analytics that can help to predict and understand service demand. But, in a recent thought leadership paper, we have also considered seven key steps to consider when planning and implementing a multi-agency initiative. We believe that these steps will help put multi-agency programmes on the right footing from the outset, and create an environment where the specific challenges can be openly and constructively addressed.

  1. Challenge the way things are done culturally – treat it as a cultural and business process change programme for all, rather than imposing any one approach
  2. Contain multi-agency initiatives within relatively small localities – use data analysis to agree an operational boundary based on common need, not organisational simplicity
  3. Build services around the individual – involve service users in the design process
  4. Understand stakeholder needs – build a vision that can be shared by all
  5. Think collaboratively as part of your stakeholder awareness – agree which services are best delivered together – from a strategic and operational perspective
  6. Develop data sharing protocols – agree how data about an individual will be shared securely to deliver the best results
  7. Include cross-sector partners from the public, private and third sectors – consider innovative contractual arrangements that share risk or reward outcomes

Read more in my thought leadership paper “Embedding the Multi-Agency approach” and I welcome feedback on the seven step approach and your view on whether this is useful or if we can improve it from your own experiences. Leave  a reply below or contact me by email.