Viva la (service management) revolution

One of my favourite expressions within service management training is the concept of ‘evolution, not revolution’.  I use this concept to explain that, for instance ITIL, is not an ‘all or nothing’ proposition that should be dismissed if it can’t be achieved ‘just so’.  My explanation is that most Foundation training courses describe a perfect world situation.  However, whilst your environment may never be perfect, that doesn’t mean you can’t use the concepts to IMPROVE your current practices.  Hence ...  evolution.

The other reason is that no best practice guidance will tell you that everything must be done ‘exactly so’! If your current practices are working, or even if they are merely ‘sufficient’, there is no reason to ‘wipe the slate clean’, ‘throw out the baby with the bathwater’, completely get rid of them and implement the best practice ones instead.  After all, a much-loved saying recalls that ‘if it ain’t broke, don’t fix it’ and a common consulting approach is to start with the area where there is the biggest pain (and thus the biggest potential gain, and where it is easier to obtain commitment to change etc.).  Again … evolution.

Evolution is the gentle cycle of Continual Service Improvement (CSI) where bit by bit, step by step, we improve towards the perfection of the ‘theoretic’ practice.  So, by applying an evolutionary CSI approach, not only do we start where there is likely to be more commitment and where there is more benefit to realise (and thus generating Deming’s or Kotter’s cycle of successful change), but we are already embedding the concept of CSI into the new practices.  Pretty cool move!

But … sometimes existing practices are so ‘rutted’ in, that gentle improvement is like trying to rock a cart out of these ruts (in order to change direction).  A small improvement or motion may be observed, but relatively quickly the cart will resettle into the old ruts and continue its previous (and probably doomed) course.  In this case, the only option is revolution: thrust the cart out of the ruts, topple it, disrupt it … and then reset it on whatever new course is required.

Not an easy choice, and certainly not a popular one … but sometimes necessary.  I had a professional acquaintance whose job was just that: pushing the organisational cart out of the established practice ruts.  He would be invited into an organisation seeking to make substantial change.  As such he would basically come in, change everything and make himself hugely unpopular.  After a few weeks or months, he would leave (or was ‘made to’) and whomever followed him in the role, not only was ‘free’ of all the old practices (which had been changed and dismantled), but also was instantly welcomed after the horrendous experience the staff had just been through.  The ‘shake up’ had paved the way for the new manager to establish new, best practices with a higher acceptance and create calm where there had been chaos.

I think that, on some occasions, in service management, we have reached this position of being ‘in a rut’, ‘down a hole’ or ‘at a dead end’.  Many of us have been working with service management practices for a long time, but in some cases, have not progressed much past the operational, reactive processes.  Even then, how have we truly matured these processes to a point of excellence?  Who dares to stand up and sing the praises of their perfect change or problem management processes?

For some reason, it appears to be difficult to ‘elevate’ our service management practices to the proactive service design processes, let alone into the strategic arena.  In my opinion a critical factor in that is the lack of getting the business involved in these processes.  And that is not just about getting input from the business, or the business taking an overseeing and authorising role (although there are many challenges with those aspects of governance that make these common obstacles), but I’m talking about a customer that truly participates in the planning & defining activities of those processes (or services … or products).

I’ll come back to that (customer participation) later, but I think that after a more than a decade of evolution we can conclude that that is not going to get us much further with the tactical\design elements of our service management model.  We are ‘rutted’ or, to switch analogies, we’re stuck on a track that is going nowhere. 

A new approach is needed … a revolution!

And, the timing is right as, in my opinion, at this point, two developments are converging to create the opportunity to consider a revolution.

The first is the emergence of new best or enabling practices.  These new practices advocate a new approach that is arguably more aligned with the modern technical and business environments, and thus provide more suitable solutions for our current challenges.  Agile, SIAM^© and VeriSM™, to name but a few, are offering practical guidance, structure and progressive practices.  Note that these practices often align with existing, more traditional ones (like ITIL^©, for instance) and that thus -at least on the surface- perhaps a revolution would not be required (but instead we can utilise these new practices through the customary evolutionary approach, ‘splicing’ them into the old, established processes).

But, the second development currently emerging is that of enterprise service management, or business service integration.  Again, this is not something that is revolutionary on its own, and some of us have been preaching service management in the enterprise for a long time, but the business is, perhaps only now, realising that IT truly is an important business enabler, and therefore needs to be integrated within the business processes, business services and business management. 

That’s right, the keyword here is ‘integration’ and not ‘alignment’!  IT alignment is nice, but it still presents IT as separate to the business, whereas what we’re after is true integration.  Add a term like ‘digital disruption’ (or the more palatable ‘digital transformation’) and we may find a business that is receptive to adopting service management practices to improve their business model.  But these businesses may not be keen to follow established IT practices, like ITIL for example (especially if their success is contentious), but rather look to emerging practices that have the business at the forefront.

So, whilst there is still the potential to simply evolve and embrace either newer service management practices or enterprise service integration, by slowly improving and expanding your existing practices, I believe the stars have aligned to allow for consideration of a more radical approach and hit these two birds with one stone …

A revolution, which can more quickly establish new practices with the business, rather than ‘allowing’ the business to utilise and become ‘part of’ well-known IT practices.  This might be the time to design a new service operating model, from the ground up: purpose-built, with business input and participation, based on existing practices that we know that work (remember the baby and the bathwater?) but augmented with new, progressive practices to utilise their strengths (especially where those old practices failed, or at least were insufficient).

I believe that VeriSM offers a great start to approach the development of such a revolutionary service management operating model.  VeriSM outlines the need to create a model that considers Governance, Service Management Principles and the wonderful new concept of a Management Mesh.  This mesh combines the various practices, technologies, resources and the environment (market, culture, …) available to an organisation and through which it can develop and provide products and services.

This openness and flexibility is a theme that is mirrored in other progressive practices.  For instance, SIAM describes a structure which allows an integrated approach to managing multiple providers to deliver end-to-end service, focussing on collaboration and culture. It does so without prescribing the specific ‘how’ to the parties involved.  For this ‘how’ we look towards best-of-breed practices like Agile, ITIL (and half-a-dozen or more others), which can be selected based on suitability to a specific project, customer or environment and applied.  The point is that all these practices offer useful elements and indeed can and should be utilised where they will deliver benefit.  One size doesn’t fit all and it’s a case of picking and choosing elements based on a particular project, service, customer, culture or geography.

So, why not start a revolution? I believe, now is the time to ‘throw of the shackles’ of the past and seek to achieve those goals that perhaps used to seem out of reach, but which are also those that are critical for future growth of an organisation! When doing so, perhaps the following might be helpful:

• Be brave – Evolution is always a safe option, whereas revolution gives you that feeling of ‘burning your bridges’.  But ‘no pain, no gain’ and in order to make that next, quantum-leap forward you cannot keep doing what you’ve always done (see Albert Einstein’s definition of insanity -or maybe it was Rita Mae Brown-).

• Start with the business – The business is your friend and partner in this.  It’s them that need the IT integration (whether they realise it or not, remember ‘digital transformation’?) and it’s them that will push the need to do things differently (and thus will support revolution over evolution).  Start a conversation with them on IT integration, on digital (business) services, on enterprise support (automated, self-help, …) and on agile project management and product innovation practices … all things this revolution can bring about for them and which would drive true business benefit.

• Start from the top – A ‘golden oldie’, but therefore not less true.  With a revolution it is important to establish the required outcome first, before planning your attack.  Make sure the governance, service management principles and Management Mesh are in place, before worrying about the details such as which practice, which technology etc.  If you get too gung-ho and start selecting practices, rewriting processes or -worse- implementing new tools you may score a short-term victory, but may lose the overall war due to lacking direction or no ownership (see previous point) and thus no long-term commitment.

• Mix-‘n-Match – No one practice will do everything, for everyone, every time.  Surprisingly, although different practices have different strengths (and weaknesses), they are remarkably similar in principle and thus can be combined.  After all common sense is (supposed to be) common, no matter who writes it down or which perspective you take.  The revolution will allow you to pick new & best of breed practices and mesh them into your model for maximum flexibility and benefit.

Good luck!

the ITIL Zealot

February 2018

Making deliberate mistakes!

For a few days now I have been pondering what to write about for this new\my next blog. In this ever-changing world there is actually remarkably little happening in the service management space. I guess we’re all waiting to see what AXELOS will bring to the party next year (or perhaps we're secretly plotting a defection to COBIT).

Mostly people are providing (excellent) examples of how to actually apply the service management concepts, or they are bashing the (perceived) rigidness of ITIL, especially compared to AGILE or DEV-OPS. And in particular on that last topic, I have felt the need to ‘come to the rescue’ of ITIL to explain how its generic concepts apply, even in the modern, fast-paced world of DEV-OPS.

At the core of ‘my’ argument is that ITIL is a best practice, and my favorite definition of that is: “common sense... written down”. Now admittedly common sense isn't always common (and in ITIL's case doesn't always immediately make sense either) and it definitely isn't written down.

The thought behind this is that we need to move from ‘best-effort’ to ‘best-practice’. Best-efforts are individuals doing their individual best. In itself nothing wrong with it, but individuals are just that, and best-effort often means that different people are dealing with the same issues in a different way. The end result of that is a differing experience (for the customer) and something that is not repeatable, consistent or guaranteed.

Those last two words (repeatable & guaranteed) are key in delivering a service. Customers want to be able to rely on the value provided, which is why we negotiate SLAs etc. and try to provide measurable targets. After all: You cannot manage, what you cannot measure.

But in extension: You cannot measure what you cannot define!

And this is one of ITIL's greatest strength, it defines processes and concepts (like Incidents, Problems, Events, Changes, CIs, SLAs, …) within the IT service provider, allowing them to become measurable and manageable.

So, defining something allows you to make it (more) manageable, and then writing it down allows you to share it with others, making it repeatable & consistent.

I think most people understand the benefit of ITIL here: the one language, the structure and definition of the processes are all very helpful in building a more effective and efficient service organisation.

However, the writing down bit is where things often go wrong with ITIL. It manifests itself as procedures, flow-charts, RACI-matrices, forms and that often becomes bureaucracy.

Now, I've lamented before that we need a level of documentation (a pilot landing a plane without a checklist is .. scary) and that ITIL actually doesn't specify how big procedures need to be (80 pages, 8 pages, 8 paragraphs or 8 words). In this context I've referred to size, risk and complexity are factors that determine the amount of documentation that is applicable.

I guess we all agree that ITIL needs to be adopted, based on your organisation and objectives. As much as we look for a prescriptive silver bullet, this was never what ITIL was intended to be. It has always been positioned as guidance to help you.

In determining HOW to adopt ITIL, it is important not just to understand WHAT ITIL is defining as best practice, but -more importantly- WHY ITIL thinks this should be done.

And I believe that a lot of the detractors of ITIL are focusing on the WHAT (and sometimes on very specific phrases in the publications) and not on the WHY.

So, take DEV-OPS. Change Management is all about (the WHY) delivering new\better value to the business and minimising impact (of not changing or badly changing). DEV-OPS (or AGILE), in my opinion, is not different to that, it is just focusing on rapidly changing. Traditional ITIL may perhaps focus on preventing all (or at least most) errors (through assessment, CABs, testing, ELS, …) but that is just an interpretation.

There is nothing wrong with making a ‘fast change’ (emergency change would be the defined concept) is that provides a better value to the business.

And now we’re getting closer to the title and thus the message of this blog. I believe that almost everything we do in life is based on a risk-reward judgement: is it worth the risk (of failure) to obtain the reward?

Often we try to make this measurable, and then again often in financial terms (ROI, TCO). But in essence this can be a very subjective, individual judgement.

And we don’t like individual actions\decisions in the service management world, or at least we’re trying to make sure that different people make the same decisions, and preferably the right one (although who is to judge which decision was right in the end).

To me, this is a key principle behind ITIL: it is not a silver bullet, a straight-jacket of procedures to be followed, a regimented framework which will avoid errors at all costs (through design, transition and operation). But it is a framework that allows an organisation to collect better information (measurements) which will lead individuals to make better (, more consistent, repeatable) decisions through which to deliver more value to the customer.

Now, no-one is perfect, and I don’t think ITIL (processes or rather their documentation) should be something that an individual should hide behind, afraid to make a decision.

After all a process never covers all eventualities and if people follow process-for-process-sake it’s the equivalent of announcing that the operations is a success, but the patient died (but look at the stitching … beautiful, consistent, text-book)!

With service management, we also need to create a culture of people understanding the WHY and giving them the ability, confidence and security to make decisions.

Even if those decisions are wrong. I often say that I don’t mind people making mistakes, as long as they were deliberate mistakes!

Deliberate mistakes you can learn from, and the next time you will change your frame of reference, and make a better decision. ‘Random’ mistakes however have no inherent learning built in, and there is no guarantee the results will be better (or worse) next time.

Most of this is based on an anecdote of IBM CEO Tom Watson. There are various versions of this, differentiating in time, people\departments involved and the amount at risk, but this version explains the message quite well.

Trust your people, and use ITIL as a tool (, framework, guidance) for them to structure their work better, and to provide them with better information, to make better decisions and deliver better value.

the ITIL Zealot
September 2013