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

What I learned at itSMF-A LEADit

Last week was the annual itSMF-A LEADit conference. Three days of presentations, keynotes, workshops, hot topics and yes, even some fun. But what did I learn in those days?

Firstly that there is nothing new under the sun: ITIL is still ITIL, no new version or revolutionary changes (perhaps AXELOS will provide those in the coming year). No new version of COBIT or any shocking development around any of the other frameworks (AGILE, LEAN, PRINCE2, ..), standards (ISO20000, …) or regulations (governance, outsourcing, …).

The ‘newest’ thing that I personally saw was a presentation on SFIA. Not that that is new, but I hadn't personally been told about a case study of a company actually using it. Great example of mapping less tangible skills (capabilities in ITIL Service Asset terms) onto people and roles, and then managing the gaps.

What was new though, or rather more prevalent than the previous year, was the tendency to do some ‘ITIL-bashing’. In more than one presentation, including a keynote, ITIL was described as old-fashioned, overly rigorous (read bureaucratic) and no longer fit-for-purpose.

Aale Roos in his keynote spoke about ‘unlearning ITIL’ and highlighted several of the idiosyncrasies of ITIL (including the ‘silly’ ITIL v3 Service Strategy publication). He proceeded to explain how the use of the ever-increasing number of processes in ITIL can lead an organisation to be lethargic. He used Nokia as an example and how it failed to quickly respond to the iPhone and smartphone market.

I think Rob England had the right idea by illustrating how ITIL is now at the bottom of the hype-curve (the 'trough of disillusionment'). He lamented that rather than being skeptical of, he found himself in recent times more often defending ITIL.

He continued the picture by showing how dev-ops is currently at the peak of the hype-curve (the 'peak of inflated expectations'). In fact various presentations during the conference highlighted both the need for rapid change, as well as the methodologies that supported this (dev-ops, AGILE .. note NOT ITIL). Case studies for Amazon and Netflix showed their large number of changes and their ability to not only absorb this, but also deal with unfragile systems (not robust, but not fragile either).

This was epitomised by the remark (again from Rob) that it was quicker for dev-ops to put a new version\patch in, than for ITIL to convene an Emergency CAB.

As self-appointed zealot I need to come to the defense of ITIL as in both cases (Aale’s and dev-ops’) it is not so much unlearning or bypassing ITIL, but rather applying it in a practical way. As I have said many times: nowhere in the ITIL publications does it speak about procedure-manuals and how many pages they ought to be. Instead it describes the activities to be undertaken and suggests some rigor to make sure these activities are performed repeatable (for the best outcome).

And the fact that ITIL has more processes now than ever before, doesn't mean there are more activities required (or people, or tools), but it allows each process to be managed separately (from an accountability and reporting point-of-view). If not required, these processes can be easily ‘collapsed’ into a single process(-manual).

It is all about how much rigor  documentation is required, which is dependent for each organisation or even each service. Personally I refer to PRINCE2’s definition of tailoring, which is not about deciding on WHETHER to use any of the theory but on HOW to use it. The level of documentation is then dependent on the size, risk and complexity of the project\organisation\service.

Little side-note: I thought it was comical to, in one of the sessions, see Rob England try to avoid ‘dead cats’ by having an Operations function getting involved in design & test; (i.e. more rigor  and then straight after, on the big stage in a keynote, he is searching for KAMU: a middle-ground between ITIL stability and dev-ops responsiveness (i.e. less rigor).

This is not immediately contradictory  but also not congruent. However I kind of see the point of and agree with both: using Ops-involvement (and sign-off) is great for medium/major changes (on critical services), whilst some of the dev-ops & AGILE principles are more aligned with how Change Management deals with minor or standard changes (with devolved authority and less formality).

So, Aale, we don’t have to unlearn ITIL. And dev-ops and AGILE are just utilising fast-tracked ITIL processes. The basics (of ITIL, of the service lifecycle, and the process-activities) are always applicable, whether you call it ITIL or not (that’s the definition of Best Practice: Common Sense, written down).

ITIL may be at the bottom of the hype-curve, but this is perhaps the time to push it back up to a ‘normalised’ level (the ‘plateau of productivity’), where we can see it for what it is: guidance on how to structure and organise IT activities, in order to deliver value through services to the business. Not a silver bullet but certainly also not old-fashioned.

And here lies the task for AXELOS (and the wider ITSM community) to work towards an ITIL that is more readily applicable. Because I do agree with Aale that some of the sections in the book are ‘silly’, inconsistent and perhaps too open to interpretation. ITIL is never going to be prescriptive, but it would be nice if the next version (4?) was a bit more practical, perhaps with more templates (RACIs etc.) and quick-starts.

And maybe next year there will be more to learn at the conference!

the ITIL Zealot
August 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

Common sense written down

Once again I find myself ‘improvising’ this blog, pushed by my self-imposed deadline of two articles a month (I was on holiday in January, hence the ‘lapse’ then). Extra pressure this time, as I've almost breached the threshold of 500 twitter-followers so perhaps this article will add those last few and get me across the line.

The title is my current favourite description of best practice: ‘Common sense written down’. I use this in my training courses, at the beginning. Not just because I need to explain the concept of best practice in the beginning (and the justification of ITIL), but also to take away any anxiety from the students … this is just going to be ‘common sense’. In fact I go as far as sometimes proclaiming that people will not actually learn anything (new) in the course, as hopefully they already possess common sense. Then again common sense isn't all that common, and in some cases (including in parts of ITIL) doesn't actually make sense!

This came to mind when I saw a twitter-discussion recently. It was started by Rob England (@theitskeptic) and a ‘review’ of a CSC Cheat Sheet (http://www.itskeptic.org/content/how-embarrassing-csc). In here it was recommended to start ITIL ‘with a manageable list of 10-15 carefully chosen subsets of the processes’. Rob’s comment was that ‘you are gonna have all of them, like it or not’. This was followed up by Stephen Mann (@stephenmann) who wondered how many organisations do more than 10 ITIL processes, and once again Rob responded with ‘how many DON’T do all (of them)?’

I am with Rob here: common sense is already in place (in most cases, there may be an exception or two) and thus you already DO ALL processes. Using ITIL doesn't mean doing more or less than you are currently doing but you can change and formalise your existing activities to be more aligned to the ITIL recommendations, terminology etc.

The word DO is perhaps wrong here, though not as wrong as the word IMPLEMENT. I have to admit that I too have been part of ITIL implementations, but over the years I've grown to detest this description. For one as it indicates ITIL is a goal and not a means but mostly as it implies a beginning and an end (as in a project). ITIL (or more generically ITSM, service management) is continuous: you did it before you knew ITIL, you’re doing it (better) after you've written some processes and you’ll have to keep doing it after (see also CSI).

We need to once and for all understand that ITIL is DESCRIPTIVE. It describes a perfect world, greenfield, best practice organisation and none of us will ever do everything, exactly as ITIL describes it. But that it not what it is there for!

The benefit of a best practice, of common sense written down, is that it allows you to verify that the activities you are performing are aligned with this best practice\common sense. Chances are you’ll find that you may not be doing all activities (or not all the time, or not as rigorous as required) or maybe you are doing too many. Thus a best practice like ITIL can help you to become more effective and efficient, not by dogmatically adopting everything it says, but by judiciously adopting your activities & practices (yes Rob, I’m ready to start that discussion) along the described theory.

One of my more recent analogies I use in training (I love analogies as it makes theory more palatable for the students) is that there are yet undiscovered tribes in the Amazonian rain-forest that are using ITIL Incident Management. Not that they would have ever heard of it, or have any procedures, but if something breaks, they’ll fix it!

They’ll notice it (logging), try a quick-fix (initial diagnosis), ask someone else to help (escalation) and end up with a temporary (workaround) or permanent (problem\known error\change) solution.

Writing things down, formalising things into process manuals and procedures (and work instructions and …) is often seen as the key to an ITIL implementation. It is also the ‘downfall’ of many ITIL implementations as it now becomes bureaucracy. I have put my thoughts on this down many times (for instance in http://itilzealot.blogspot.com.au/2012/11/process-for-process-sake.html) so in short: documentation helps to make a process repeatable, manageable and guaranteed (including the activities within). Whether and how much documentation you need depends on your current situation (are your actions already repeatable, manageable and guaranteed?), and the size\risk\complexity of your organisation.

DOING an ITIL process is not determined by whether or not you have formally implemented process manuals, staff training etc. but whether you are following common sense, preferably aligned with the best practice theory. So indeed, as per Rob’s comment: who DOESN’T do common sense (across all lifecycles, processes, …)?

the ITIL Zealot
January 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

Practical tips for Process Manuals

Bureaucracy is one of the greatest threats to the ‘application’ of ITIL. Actually there are many things wrong with even using the word ‘application’, but one of the common mistakes I see people & organisations make is throwing themselves into writing process manuals (, procedures, work instructions …) and ending up in a world of documents that hardly anyone uses (or even knows of).

First of all never forget that this paperwork only comprises ONE of the four Ps, namely the PROCESS one. You cannot forget the other: PEOPLE, PRODUCT & PARTNERS, which together make up a Service Management organisation. I often remonstrate that out of these the people-aspect is the hardest one to establish and this most certainly will not happen through the creation of documents (alone).

Yet, having said that: ITIL excels in describing processes and expects (and in some cases demands) that these processes are formalised in order to provide agreed, uniform, guaranteed and repeatable outcomes. Note however that nowhere in the ITIL publications it mandates a particular level of details or volume of this documentation. I always borrow from PRINCE2 which describes tailoring as a requirement and states that it is not about deciding WHETHER to use the best practice guidance, but rather HOW to implement this. And further it identifies that this implementation (roughly translated it means the amount of rigour and documentation required) is based on the SIZE, RISK & COMPLEXITY of an organisation.

Thus ITIL is introducing a level of documentation (one could say bureaucracy), but PEOPLE need to understand the need for this. You would not want your pilot to announce that he\she has found a new way of landing the plane, but rather that he\she is following a tried-and-tested procedure (with the co-pilot auditing this) to provide the best possible outcome\value to you as a passenger.

In this article I will provide two ways of quickly establishing procedures and work instructions. PS: I will be using the terms process manual, procedure, work instruction and documentation without prejudice. I do have certain thoughts on this, but the theory seems to be somewhat ambiguous on this topic (in particular across various frameworks). It does make sense in your organisation to develop succinct definitions for each to make sure people understand which is which.

                          

My first suggestion is a top-down approach based on a RACI matrix. Personally I think RACI matrices are the best things since sliced-bread as they show in one matrix, diagram, page, view … both the activities (of a process) and who is doing them (, involved in them, informed about them etc.).

So: start with the ITIL process activities. These should easy enough distilled from the theory, where each process is described in a number of steps\activities. Next put your staff (or teams) on the other axis of the matrix and determine who is R(esponsible), A(ccountable), C(onsulted or participating) and I(nformed) for/about the activities.

For writing the work instruction, focus on the RESPONSIBLE parties only. They are the ones performing the activity and thus in the best position of creating the documentation. If there is only one person\team responsible this can remain relatively ‘light’, but if there is more than one party involved not only do they need to agree on the procedure of HOW to perform the activity but also on how to transfer responsibility between the groups (for instance functional escalation in Incident Management between 1^st, 2^nd and 3^rd level support on ‘investigation & diagnosis’). You would expect more rigour and thus more detail in these work instructions.

Finally the Accountable person for the activity will need to sign off on the documentation produced.

 

As a second suggestion you can start bottom-up (and not use best practice theory at all, but rather current practices). Ask each team to identify the team’s top 5 activities by volume (what are the things we do x times a day?). Assign one activity to each person within the team and get the work instructions written in one afternoon. 

Do this 3 times and the result of 15 work instructions will likely document the activities that the team spends 80% of their time on.  There will always be 20% of activity that is done less often, that won’t be well documented ... don’t sweat the small stuff.

Of course you do need some cross-team coordination and ownership, but at least you’ll have some documentation to start with.

 

Both methods are only half the battle as once documentation is created it will need to be maintained, reviewed, updated, improved, communicated etc. I am mainly looking towards the ‘owner’ (accountable person) to do this, but there are some ways in which you can ‘institutionalise’ this.

New staff should, as part of their induction and probation, not only be trained in the work instructions, but used as an ‘unbiased’ observer. Let them spend some time on reading (all) the documentation and then discuss with them what makes sense & what doesn’t. Perhaps repeat this again (and the end of probation) when they know how the actual work takes place (and make them update it).

Similarly when staff has gone to (ITIL) training, they should ‘apply’ their knowledge by reviewing the relevant procedures and suggesting updates\improvements based on their experience (practice) and new knowledge (theory).

All these suggestions make staff responsible for creating the documentation and thus hopefully instils a sense of ownership\acceptance. This as above all, all staff should have the culture, awareness, attitude and understanding that the work instructions are there for a reason (like the pilot’s checklist) and that not only should they be followed, but actively used. Staff should be rewarded for suggesting changes to existing work instructions and\or promoting the use of them within their teams.

But that brings us back to the PEOPLE element, which as I mentioned is the hardest one of all. More about that some other time.

the ITIL Zealot
October  2012