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

The Alternative to ITIL …

If I follow the social media ITIL seems to be over the hype-curve, with many people predicting its impending demise, often due to various reasons:

• The joint venture with Capita (AXELOS) will make it too commercial
• COBIT (or …) is better
• DevOps will replace it
• Cloud computing has made it obsolete
• BYOD has made it obsolete

In our MALC course we actually debate the relevance of ITIL, whereby I as the facilitator take the opposing view, often using the very reasons I’ve highlighted above. It is refreshing to go over to the ‘dark side’ and attack the ITIL framework for all its weaknesses (or heralding the benefits of those mentioned above). At one stage we nearly decided to quit the course and start doing COBIT Foundations instead!

But it also makes me realise all the good things about ITIL and how to actually, practically apply it. I will address the ‘negative’ reasons in reverse order, but first I think it is important that at the heart of all this we are talking about IT service management. Service management is all about delivering (IT as) a service to the customer: a fixed-price, black-box, repeatable, guaranteed, managed & measured value.

This immediately invalidates any reasoning that a new kind of technology (for instance Cloud, BYO) will replace ITIL. ITIL\service management is not about technology, but which processes (\activities) to follow to make sure the technology delivers the benefits (=value) they’re supposed to. So, whilst Cloud and BYOD may make it easier to manage the technology, it is still required to define business value, guarantee the design, transition this, operate it and measure to validate or improve.

Service management is also a ‘best practice’, of which my favourite definition is ‘common sense written down’. And common sense doesn’t really change, so any ‘movement’ or development (like DevOps, return-to-core, rightsize, … even Agile or Lean) can at best only marginally change our opinion of common sense, but not completely invalidate it. Thus they won’t replace ITIL, but provide a different perspective on the guidance it provides.

ITIL is nothing more than the best-known proponent of the IT service management best practice. It has been around for a long time (25 years+), is recognised globally and arguably is the most accepted of the methodologies (certainly in terms of people certified, tools sold and ‘implementation’ performed).

This does not mean ITIL is perfect (despite the nom-de-plum I’ve chosen, even I don’t believe that). I fully recognise the weaker points of ITIL: its generalisms, inconsistencies, less-than-complete or defined strategy processes, its lack of dealing with the real-world (although complimentary publications like the ABC of ICT, Planning to Implement Service Management etc., do a good job of that).

As a consultant (and trainer) it’s these imperfections that make ITIL such as rich source of work: it has to be understood and adapted before it will succeed!

But ITIL has a few things going for it that will make it hard to ‘usurp’ as the leading service management methodology:

· Its ‘completeness’
· Its ‘installed base’

ITIL (since v3) now covers a lifecycle, which means that it just about covers everything you want\need in an IT organisation. Sure, there are some glaring omission (organisation & risk management, or a better defined governance framework) but by-and-large everything is covered.

Many of the other framework focus on one particular element (PRINCE2 for project management, Agile for development, Lean Sigma for process improvement, ISO2700x for security management) which at best makes them complimentary to ITIL, not a replacement.

There are but a few other ‘complete’ frameworks out there. MOF (the Microsoft Operations Framework) is not vendor-neutral and Microsoft hardly has the right audience (too many techo’s, not enough business managers). Plus it is by-and-large based on ITIL anyway. ISO\IEC 20000 is also based on ITIL and its prescriptive nature makes it less friendly to adopt & adept (though together with the additional guidance that is being released it certainly provide a good source of content, perspective and ideas).

This leaves us with COBIT (OK, potentially TOGAF or USMBOK but this is not meant to be an exhaustive comparison). Without going in too much detail, I’d consider COBIT the biggest ‘competitor’ to ITIL. In many perspectives COBIT is better than ITIL (more consistent, contains better governance and risk, provides a quick start, has ‘default’ RACIs, …). In fact if I were to start with a greenfield organisation I might even consider using COBIT instead of ITIL … but, be honest, how often do we come across this.

And so, based on the installed base of ITIL-trained people in the market (including consultants), the number of ITIL-based tools deployed (and/or available) it is very hard to ignore ITIL as the premier service management methodology. Again, this does not mean ITIL is perfect and many of the other frameworks referred to in this blog can be used in conjunction with ITIL, but they’ll not replace it.

Thus the best alternative for ITIL is … an updated ITIL. Which bring us to our last argument: the new joint venture AXELOS who now owns ITIL. A great opportunity lies before them to invest in ITIL (and the other best practices in the portfolio) and bring an update to the market that includes lessons learned in the market, benefits from other methodologies but above all in a consistent package with supporting products (quick guides, implementation guidance, …).

Currently they’re making all the right noises, so I will remain cautiously optimistic that AXELOS will improve ITIL. However, there is a very real risk that AXELOS could instead be the death knell for ITIL too: if they overemphasise the commercial side or focus too much on the UK\home market they will restrict the use and global involvement of the community in the on-going development of these best practices.

In that case I might switch my allegiance to COBIT or USMBOK, but for now I’ll remain the ITIL Zealot.

the ITIL Zealot
July 2013

Capacity or Availability Management?

We all know (or should know) that ITIL originally was written as one process in one book, often by completely different authors. This is where the L for Library in ITIL comes from. Consequently one of the downside of ITIL v1 is the inconsistency across the various processes/publications.

ITIL v2 (around the turn of the century) packed a number of processes together (Service Support and Service Delivery most notably), but barring some minor changes, modifications and updates it still seems it was mostly a copy of v1, and thus the inconsistency remained.

And whilst v3 (2007) was more of a rewrite (than a ‘mere’ copy), different writers contributed to different publications of the lifecycle and thus the inconsistencies across these processes & publications wasn't completely removed. In fact the introduction of new processes caused some additional discrepancies (Release & Deployment Management still called Release Management in Service Design, Problem Management not referring in any shape or form to Knowledge Management, CSI hardly mentioned at all in any of the other lifecycle publications).

The most recent 2011 ‘update’ tried to remedy some of this, by swapping writers around (writers of one publication, reviewed & updated another) and by introducing further structure within and across the publications. And admittedly they have not done a bad job, but I am still left with the suspicion that some of the text in the current books is an almost verbatim copy of the original version 1 processes.

Of course: universal truth remains universal truth and common sense doesn't change over time. And thus some of the v1 ‘goodness’ certainly deserves its place, even in the current publications, more than 25 years later. But I cannot escape the feeling that this has been a missed opportunity where a bit more consistency & standardisation would have made some the more ‘difficult’ processes a lot more accessible to the audience.

All this was triggered this week, when I was delivering the PPO (Planning, Protection & Optimization) Intermediate Capability course. I have always thought that Capacity and Availability Management have a lot in common, but this week I played the game whereby I showed the Capacity Management slides (theory) and replaced the word ‘Capacity’ with ‘Availability’ and surprise, surprise it still made sense.

Actually no surprise as both processes are trying to achieve the same objective or goal of ‘ensuring cost-effective meeting of the current and future needs of the business’ (one for Capacity, one for Availability). They both have a plan (forward looking plan, describing the current situation, SWOT, foreseeable future scenarios and recommendations), they both have a MIS (Management Information System, storing relevant information for the process), they both support Service Level Management and they both have activities to do with impact assessment (Change Management), design, monitoring & analysis (Operations) and proactive improvements (CSI).

Sure, there are differences: Capacity Management has three sub-processes which look at capacity at business, service and component level. But really, don’t those sub-processes also exist in Availability Management: looking at the availability of a component, a(n end-to-end) service or a business (PBA)?

IMHO the only real differences are the specific terms in Availability Management (availability, reliability, maintainability & serviceability) and the techniques used (CFIA, SOA, FTA, …).

Although some of those do translate to Capacity Management. After all reliability include things like resilience and redundancy which requires capacity. And in the end an incident which impacts capacity (for instance performance degradation) could also impact availability (if for instance the response time become too slow to be ‘workable’).

So, my suggestion is to rather than look at Availability and Capacity Management as two separate processes, each requiring separate process manuals etc.etc., it would be beneficial to leverage both (with perhaps specific roles and procedures at a lower, more technical level).

Also realise that many of the activities (design, test, monitor, analyse, report) will already be there, especially at a technical level, and ‘the trick’ is to combine or centralise these across the technical functions and ‘lift’ them up to a service level and to provide a business-centric focus on capacity and availability. The next challenge is then to involve the customer (through Service Level Management) to obtain enough forward-looking information to increase the effectiveness of the processes.

It will remain a challenge for many organisations, but hopefully slightly less so …

the ITIL Zealot
May 2013

Around ITIL in 30 Analogies

This week I received acceptance of my presentation proposal for the itSMF Australia national conference LeadIT 2013 (in August, in Canberra). My topic of choice is ‘around ITIL in 30 analogies’.

Yes, I’m realising that these details will make it possible for you to discover my identity as I have submitted the above under my own name (and will not be on stage dressed in a black robe). However, after all this time it now is time for me to ‘dis-robe’.

Anyway, back to the topic. I love analogies, I think that analogies are just about the best thing since sliced bread (is that an analogy in itself?). When it comes to training there is no better way than to quickly explain a concept than to relate it to something already (and/or easily) understood by the participant.

This is not a matter of ‘dumbing’ things down or ‘populising’ a concept, but a valid way to provide a better understanding. And let’s face it: the ITIL theory is full of concepts and whilst they may claim to be ’common sense written down’, sometimes common sense isn’t common (and it doesn’t always make sense either).

My favourite analogy is that for a service. After all, this is the most basic concept of ITIL Service Management. The official definition of a service is “A means of delivering value to Customers by facilitating Outcomes Customers want to achieve without the ownership of specific Costs and Risks.”

True of course and there are many things to be learned from just slowly reading the definition and looking at the keywords. Apart from analogies, another technique I use to explain concepts is to bring them down to one or two key expressions, in this case value.

I then boil it down to that fact that for the customer the service is a ‘black box’: a guaranteed, fixed-price, repeatable, managed & measured delivery of value.

Or rather this is what it should be, never forget that ITIL is descriptive and that not all of us can do all of it, all at once. If ITIL is maturity-level 100, and you’re at 25; it is not required to reach 100 in one step, but rather use the ITIL guidance to reach 30 (and then 40, 50, …).

See, there is another analogy to explain the use of the ITIL theory in practice.

But, to put the concept of a black-box service into perspective I normally use public transport, particularly the bus (rather than the more commonly used analogy of a restaurant).

When you take the bus, you go to the bus-stop and wait for the bus. Now I keep mentioning ‘bus’ which really is a kind of technology. But, as a user or customer of this service you are perhaps unaware or at least not overly interest in the type of bus: petrol, diesel or natural gas powered, articulated, double-decker, new or old … it doesn’t really matter (you may have a preference, but you wouldn’t not go on a bus because it is not the type you like\want) … black box.

When you get on the bus, you pay. In my area we have smartcards and you pay per ‘zone’, currently $1.45 for 1 zone. Now this is $1.45 every day, unrelated to the price of fuel, the salary of the driver, the depreciation of the bus, the costs of maintenance … fixed price.

The bus will take you to where you want to go (into town in my case), within a certain timeframe. You don’t have to worry about this and can read the paper (or play Angry Birds on your phone as I do) … guaranteed & repeatable.

Sure, the ‘guaranteed’ part is relative: the bus could have an accident, break down or a major traffic jam could delay it, but these are fairly big/high-level risks. All the smaller (technical) risks are covered by the bus company and more-or-less invisible to me as a passenger.

So services do not defer ALL costs, and\or ALL risks, but make them more predictable and higher-level. More importantly, as services support the business in their outcomes, it is the business who is responsible for defining them. 

In my case this is getting to work. Now note that if I arrive late, I cannot blame the bus (or at least not all the time). As a customer it is my responsibility (or accountability really, but more on those two some other time) to select the appropriate service provider and negotiate the required service levels: instead of the bus, I could have driven my car in (faster, but more expensive to park), or taken a taxi (faster, more expensive), my bike (slower and harder to take stuff with me, not to mention my inadequate level of fitness), private helicopter …

Analogy and lesson 1: Customer define the services, but then expect fixed-price, black-box, repeatable and guaranteed delivery.

the ITIL Zealot
March 2013

One CAB to rule them all

Once again I find myself providing ‘practical’ advise by explaining that ITIL is not a rulebook that needs to be (mindlessly) followed as this will invariable lead to unsatisfactory outcomes (which then often are blamed on ITIL).

This is pretty much my key message in ITIL Foundations courses, but as I am doing an RCV (Release, Control & Validation) course this week, I thought I’d apply it to the Change Management theory.

I love Change Management and I think it is one of the key processes (after all, if you cannot manage your changes, what chance do you have in maintaining any semblance of control?). At the same time I have seen many organisations fall into the trap of implementing a dogmatic ITIL-based Change Management process, only to see it become a bureaucratic bottleneck. The demise of this not only leads to mistrust in any other ITIL process (paperwork, too formal, …) but often leaves a situation which is more disorganised and 'out-of-control' than it was prior to the ITIL implementation attempt.

First is the critical understanding that absolutely EVERYTHING can be classified as a change (the addition, modification or removal or any supported …). This because absolutely anything can threaten the service\value\business … from minimal, routine patches to big new systems & applications. But this doesn’t mean that every change is equal and I believe on the keys to Change Management is a good classification system, differentiating between various changes.

The ITIL theory gives us already normal, emergency (for when the ‘normal’ process can’t be followed) and standard (for repetitive changes for which the ‘normal’ process would be overkill). Good sound advice and in particular the ‘standard changes’ save Change Management from becoming a bottleneck (but more about that in another blog, another time).

Within the ’normal’ category ITIL does mention a further differentiation (significant, minor, medium, …) but kind of ‘heaps it together’ and sends all the normal changes to the CAB. Aah, the Change Advisory Board .. an often misunderstood concept.

First the advisory part: the CAB doesn’t actually authorise the change, that is done by the Change Authority. Of course the CAB can be the Change Authority, but it could be someone else, or another committee as interestingly enough ITIL allows a Change of be authorised by a group of people (where is the accountability in that?). Often in reality you’ll find the CAB actually approving the change, and if not the CAB-as-a-whole than one or two individual members of the CAB.

So, in the CAB we find anyone who’s got anything useful to say in terms of the advice of approving the change or not: developers, operational staff, customers, users, contract focused people … anyone. Well, not everyone\anyone as before the CAB an assessment should have taken place covering some of the angles. Nevertheless the CAB becomes an eclectic bunch of people who are supposed to meet regularly.

We all know how well flexibility (anyone who’s got anything relevant to advice with regards to a specific change) goes together with regularity (weekly CAB meetings). Thus many organisations will forgo one or the other, mostly choosing to have regular (weekly) CAB meetings with a wide-variety of people present.

The risk here is two-fold: firstly of course that the relevant people are not here. The consequence of this is that even after the CAB has reached a verdict these people will need to be involved and sometimes change the discussion 'down-the-track' (or just repeat it, wasting time). Worse: not involving those people can lead to a bad decision and ultimately an unsuccessful change.

But more common would be to have ‘too many’ people in the CAB, including all the relevant people but also several ‘irrelevant’ ones. For these the CAB meeting might become a tad tedious & boring and they may not show up the next time. Now be mindful that just because someone is not relevant to one change, they can still be essential for the next (so you don’t want them to ‘turn off’)!

How to reconcile this flexibility with regularity then? I don’t think I have THE answer, but it starts with realising that there is no one CAB to rule them all. The CAB is relevant to the specific change and thus different CABs should be formed to deal with the different type of change (hence my previous ramble on ITIL sub-categories for normal changes).

The 7-Rs can help, but in general it is a matter of assessing each change on its business impact, technical impact risk and costs (or ROI). Based on whether each of these assessment-dimensions is big or small the change can be categorised as big or small, and then further assessed by a big or small CAB (I often refer to a big change to be advised by a big committee and a small change by a small person (less than 5 foot).

Another useful approach is to split technical and more business\financial\contractual advice. The people involved in either are often not interested in the other and by letting them all loose in a single CAB(-meeting) it is bound to either become a highly technical discussion, or one about fiscal prudency.

In one organisation I’ve worked with, they have created a TAG or Technical Advisory Group. Here all the technical aspects of a change will be assessed first (development, transition and operation) before an advice is passed on to the actual CAB, which contains people with more a view on business reason, contractual complication, financial viability etc. For small changes (low cost, no business impact etc.) the TAG even has the ability to directly authorise the change, without the need for the CAB. The bigger the change, the bigger the CAB (either more or more important people).

It is not perfect, but it certainly works better than the one CAB option. In one organisation there were even different CABs for different business units (which each worked with different, highly specialised and frequently changing systems\applications). An overarching CAB dealt with changes that impact multiple business unit, or where a CAB couldn’t make a decision.

Ultimately I think ITIL has three steps here within Change Management: assess - advice – authorise (funnily enough, even though there is a Change ADVISORY Board, ITIL doesn’t make this activity very clear in the process diagrams). Within these steps anyone who’s got anything to say should have the ability (or the requirement) to do so … or forever hold their breath (and accept that & how the change is approved without their input).

The CAB is a big part in that, but there are other way to make this more practical (TAG, assessment forms\checklists\reports, different CABs for different changes, electronic approval flow, …). Whatever works within your organisation, for your (different) changes!

the ITIL Zealot
February 2013

Service Management basics

Happy New Year

Somehow I thought I would be able to write my blogs ahead, and then release them fortnightly (or at least two-a-month). Reality has taken over and I now find myself in January without any pre-prepared blogs. So, with this in mind and as we’re starting a new year, I thought perhaps I should go back to the basics.

As an ITIL zealot, I of course am strongly inclined to see ITIL as the one true way of ‘implementing’ service management. But I am certainly not that myopic not to recognise that there are some excellent ‘other’ frameworks around which offer complimentary and sometimes even superior advice (I am particular enarmoured with COBIT5 and may devote a future blog to that).

But more than any specific methodology I find that recently I am spending more time (in ITIL training etc.) explaining to people the basic concept of Service Management (and then how ITIL fits in). So, the basic concept of service management is the management of services (yes, sometimes things are THAT simple). A service, in turn, is the value we deliver to the business, which is not related to any specific technology used (but rather the utility and warranty, which are a great set of concepts, although ITIL could have used them better and more consistent).

So, my first and possibly most basic teaching is that we (i.e. all ‘IT-people’) need to focus on our deliverable\value rather than our delivery\technology. This is most evident in a process like Incident Management that deals with break-fix. ITIL provides a great objective-statement for this process which is ‘to restore normal service as quickly as possible, and minimise impact on the business’.

I always highlight three key parts in this statement, the first being ‘restore’. Incident Management is not about fixing, improving or anything permanent\long-term, but merely about restoring the normal\working situation, sometimes using workarounds (the equivalent of taking an aspirin …). The second highlighted part is ‘as quickly as possible’, which then leads to the priority-setting (impact and urgency), which is driven by the customer, business or at least the service targets of the SLA.

The last part of the Incident Management objective that is of importance is ‘minimising impact to the business’, which brings us back to the core of service management: delivering value. If a user can’t email, then it is important of us to restore this service (and for future purpose perhaps do a root cause analysis). But of immediate importance is the business process which was trying to communicate (the value), something that perhaps can be achieved otherwise (print & fax, phone, …). A good service desk agent will think with the user, about the business and not restrict themselves to the service levels in place and/or the technology used.

Once you grasp that the basic meaning of a service is the value delivered, then the next\second basic concept is that of the ‘management’ part: the value has to be delivered repeatable & guaranteed. This is where ITIL (or your favourite methodology) plays its part as it provides the structure that allows providers to deliver services repeatable, manageable & guaranteed. 

In ITIL this is done through the processes which provide ‘structured activities’. This is why a good methodology is also known as ‘commons sense, written down’ as those activities are common sense and most people would do them anyway, most of the time (I sometimes joke that there are yet undiscovered tribes in the amazon who are using Incident Management). The structure of a process makes sure that everyone does the activities, all of the time and thus establishes repeatability. By documenting a process (procedure manuals, work instructions etc.) and measuring activities (and outcomes) we make the delivery manageable, repeatable & guaranteed.

But … remember that it was not about the delivery, and thus not about the process, but rather the outcome\value\service that is being delivered. Processes\ITIL are merely a means to an end (even though sometimes zealots like myself get lost in the intricacies of the means, thus forgetting the end)!

Focusing too much on process is the equivalent of declaring the operation a success, even though the patient has died! (but look at the stitching ... textbook).

So, these are the basics of Service Management: it is about delivering value in a repeatable & guaranteed way. Ultimately (or ideally) a service is a fixed-price, blackbox ‘thing’: as a user\customer I don’t care how it happens, as long as I get the value, every time I need it!

Best wishes for 2013.

the ITIL Zealot
January 2013

Process for Process' sake

One of the most heard (negative) comment about ITIL is that it introduces bureaucracy. If have dealt with this topic before, but recently I was reminded again of how people sometime implement (and follow) process for process’ sake, without an understanding of the reason for the process, and thus the outcomes required.

Let’s start at the beginning, or rather with the theory. ITIL defines a process as

A Process is a set of coordinated activities combining and implementing resources and capabilities in order to produce an outcome, which, directly or indirectly, creates value for a customer or stakeholder

As many other people\trainers do, and as you can see from the highlighting\bolding above, the easiest way to explain a process is that it coordinates the activities you’re supposed to do (which makes it easier than ‘making it up as you go along’, more repeatable and manageable than ‘just doing what you think you should be doing’ and all those other behaviours we don’t want to see in Service Management.

To me this is the key of a Best Practice (something which is accepted and used), or rather the opposite of best effort. Best effort means that each individual is doing his or her best, but often without any structure, documentation, management. Introducing a process of coordinated activities means everyone will do those activities and everyone will do them the same way, thus creating a repeatable, manageable process.

Therefore the first characteristic of a process is that it is measurable. After all if you can’t measure it, you can’t manage it and the coordinated, uniform nature of a process allows it to be measured (of course this is also where\when we introduce bureaucracy but that has already been dealt with in another blog).

A second characteristic of a process is that it has a trigger. In other words, we don’t just do something, whenever we want, but based on a particular trigger we start a particular process. I have a visual image of ITIL whereby all 27 process manuals (or 26 or ...) are standing on a boardroom table ... which process to follow? Fortunately above each process is an arrow indicating the trigger for that process: a call to the service desk triggers incident management, a submitted RFC triggers change management, the 2^nd Monday of the month triggers service level management (reporting). 

Maybe this is why the Strategy & Design processes in ITIL are so much more difficult to define. Cause where the Transition & Operations processes are quite linear (one trigger, one set or flow of activities, leading to one outcome), the Strategy & Design ones have multiple triggers, flows and outcomes. Again, I digress.

The last two characteristics of a process are that it has a defined outcome (the reason for the process in the first place) and a customer. Or stakeholder, there is some confusion here as it is not always the ‘business’ customer we mean here, but someone who wants the outcome of the process (after all why would you perform the process if no-one wanted the outcome).

And this is the ‘trap’ of ITIL. Because ITL defines the process, trigger & activities perhaps we sometimes to blindly just ‘implement’ what the book tells us, without considering the outcome or customer. This is the WHY of ITIL which is no readily apparent but certainly within the context (see by blog on that). Or perhaps after we have created a process (taking the outcome and customer into account), we proceed to merely follow the process, reviewing the KPIs but never verifying the original outcome, objective, customer and\or CSF\KGI.

It has now become process for process sake. My stock analogy for this is: ‘the operation was a success, but the patient died ... but look at those stiches, textbook!’. 

The other day I got a reminder phone-call from my dentist. This is a nice service they deliver as mostly I make my appointments 6 months in advance and this why I get reminded and it gives us the chance to reschedule if it is no longer convenient (from their side it avoids patients not showing up and thus increases utilisation and thus business revenue).

However, in this particular instance my previous appointment had been cancelled, and we had only rescheduled it to one day later. Thus receiving the phone-call reminding me of an appointment booked less than 24 hours before now didn’t add any value (or outcome), but instead felt like ‘process for process’ sake’.

the ITIL Zealot
July  2012