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

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