Friday, 26 March 2010

Brandon Lane CIO: Episode 4

The Road to the Corner Office

"Thanks Kelly. I want to sit in on the desk at some point and see what it is like. Can you get Richard to come and see me when he gets in. That is as soon as he gets in, don't even give him time to get his coat off."

"Will do Boss, catch you later."

As Kelly walked away Brandon's mind was racing. He was used to cursing IT every Monday morning when the systems were slow or he couldn't get in, and now it would be him in the firing line. He made a mental note not to schedule his hour on the desk for a Monday.

He wondered what the changes were that had gone wrong. Looking around the department it looked very calm, no one seemed to be running round  like headless chickens. In fact everyone seemed to have their heads down over their screens. A dreadful thought crossed Brandon's mind*. You can take the auditor of audit,but you can't take the audit out of the auditor. It was time to play dumb.

He wandered a few desks away to where he was fairly sure no one had been paying attention to his discussion with Kelly, though being honest he thought he needn't have bothered judging by the number of white earphones in use.

He headed for a vaguely awake desk jockey with  and tapped him on the shoulder. The reaction was as electrifying as a piece of  silica aerogel

Eventually there was some sort of reaction and a slo mo unfolding of limbs.

"Thanks for joining me in what some of us consider to be reality. I'm new here. Can you tell me what you are doing?"

"Err, not really it is difficult."

"OK, is that difficult as in I'm probably too dumb to understand it, or you are too dumb to explain it?"

Brandon noticed the total absence of a meaningful pause before the DJ responded.

"No offence, but you look like you are too dumb to understand it."

"Well thanks for that vote of confidence." Unlike the DJ Brandon did understand the value of a well timed pause


"So I guess you don't need me to tell you that you've got a buffer flow vulnerability in that code."

To be fair the kid didn't miss a beat.

"Oh yeah, I was going to sort that. Anything else I can do for you, only I'm busy. "

"You know there is rumour that is about to start going around that you've really p****ed off the new CIO. Oh Hai there BTW, I'm Brandon Lane, your new CIO. And you are?"

"Hi Brandon. I'm Jake."

"Jake,Is there any chance you could tell me what went wrong over the weekend?"

"Err, I think it was something to do with static IP addresses"

"Tell me more..."

"Like the MFDs all had static addresses but... did you just say you were the new CIO?"

"I did"

"Should I shut up?"

"You can.but you might as well continue digging."

"You aren't going to sack me?"

"You know, something tells me that you can't actually dig a deeper hole than you are already in, but you can start to climb out of it"

*"I bet they are all playing WoW "



I've worked with some great people over the years. Too many to mention.

But today I'm going to single out one individual.

Scott Standen, come on down!

Scott ran the programme office for the European Central Bank's ITIL project.

I have many things to thank Scott for.

He introduced me to the best curry house in Frankfurt.

He...well, OK, that is pretty much it.

No seriously, he also came up with the best ever ITIL white paper/conference session that has never actually been delivered.

It was Scott who came up with the concept of "Walking backwards to ITIL" If you want a great practical session book him to deliver it.

It was Scott who realised that for an ITIL project to be successful you have to understand the desired end state and then work backwards to understand what you have to do to achieve it.

It was Scott who dissected the requirements of ISO 20000 to develop a meaningful project plan.

It was Scott who came up with what I think is one of the greatest ever ITSM ideas.

Here it is: Set a criteria for a service to enter the service catalogue.

Simples? Yes. Powerful? Yes.

Do not put anything into your service catalogue until you are are certain you can manage it and can deliver the specified service.

Let us call it "Scott's Law"

And congratulations Scott on passing your Service Manager's exam.

Monday, 22 March 2010

A Professional Training Scheme

This is a follow up to an earlier post, Is ITSM a Profession?

To save you the tedious task of reading it I'll sum up what I said very briefly that as things stand:
ITIL based ITSM fails the tests that define a profession, 
That isn't necessarily a bad thing 

I want to expand on the second of those points at a later date. Today I want to focus on my opening statement from that previous entry.

A profession lives or dies by the quality of its training.

Having spent a long period of my life training both professional auditors and v1 ITIL service managers I have a high regard for the great work done by many in the training game, but I believe that the time is ripe for an honest appraisal. Clearly I'm not alone.

I don't intend to go on at length about what is wrong with the current training.That doesn't mean I won't, of course.

So what is wrong with it? 
  • Tutors with insufficient practical experience 
  • Too much focus on passing the exam 
  • No development of practical skills 
  • No challenges to conventional thinking 
  • No dialogue with "Castle ITIL
  • Rampant Short-termism 
  • Questionable objectives and outcomes 

    Lets stop there and look at that last point. Now sadly I think there are some people who see ITIL training as nothing more than a cash cow revenue stream. That isn't really what worries me though. What worries me is a lack of clarity and realism about what those paying for the training, and those undertaking the training, get out of it.

    I've just paid to put myself through the v3 managers bridge course. How did I do in the exam? Did I fail and this is just a sour grapes posting? No. I got 20 out of 20 questions right. 100%. I am, apparently, now an official ITIL v3 Expert. Sadly, if Linkedin is to be relied upon, there really are people who think that passing a twenty question multiple choice question exam has turned them into instant experts.

    Leaving such self-delusions behind is the much more worrying question of what employers and agencies seem to think the v3 qualification indicates. Suddenly it seems to be a life or death necessity that you have the v3 qualification to get a job in ITSM, even if it is for a role in a company that has struggled to use v2.

    All the v3 Bridge examination proves is that you know some of the terminology has changed between v2 and v3. Any notion that it indicates you are an expert in v3 is, frankly, farcical.

    Of course in the good old v1 days....things weren't really that different. I'll argue the training was better because we didn't focus quite so much on the exam, and the exam was more challenging because there was a greater variation in questions, but beyond that getting the managers' certificate didn't prove you were an expert in practical service management. It showed you understood the basics and could think about how to apply the ideas. We weren't turning out course after course of fully fledged service managers even with a target audience of early adopters.

    So what would a professional training scheme look like, and how far away are we from such a scheme?

    Let me borrow from my audit training experience at the Civil Service College (now the National School of Government)

    Training took place over several weeks spread over at least a couple of years. That allowed time for ideas to sink in, and for things learnt in the modules to cross fertilise each other. it also meant students could try the tools out in the workplace, and bring workplace situations into the classroom.

    Employers were seen as an integral part of the training scheme, with a significant responsibilities to ensure the best possible outcomes. For instance they were required to ensure students undertook a suitable mix of assignments whilst being trained.

    The training also depended heavily on involvement from practitioners who were doing the job for real coming along to share their experiences.

    Whilst theory was a necessary element in the training the emphasis was on developing practical skills and techniques.

    Qualification did not just depend on exam results but also required the completion of work based assignments signed off in a log book.

    The examinations allowed for for a degree of specialism, recognising for instance that though all auditors need to know something about computer audit those specialising in it needed dedicated training and a separate examination.

    The exams were designed with incredible care to ensure they were relevant, and fair but testing. Hours were spent reviewing the wording to ensure it was absolutely clear what a question was asking. Every question was on the exam paper because it tested something important, not just to make up the numbers. The presumption was that an answer that was competent and relatively complete would result in just getting a pass mark, with additional marks available for "delighting the examiner". It was expected that a set proportion of students would fail each question, and that the bulk of students would be bunched either side of the pass mark.

    Are we so far away from such an approach with ITIL?

    Perhaps less so than it sometimes seems.

    The move towards a more modular approach means that training can be spread out over a relatively longer period.

    A major rethink would be required about the role of employers and also in assessing how students are actually applying what they are being taught on the courses.Reality is that it isn't as easy to move between roles as is it to move between assignments.

    Personally I believe a real weakness currently is that we have too many trainers who have been taught how to run courses parrot fashion without having an underlying depth of knowledge.

    I believe considerable work would be required to change the focus of the training away from basic ITIL knowledge towards the application of ITIL and the use of specific techniques, but it isn't an impossible task. It was a feature of much of the early ITIL training, and of course several courses already make use of an integral ITIL simulation.

    prISM seems to offer a way forward for how to integrate workplace experience with examination success.

    The modular approach of the new exams allows for the recognition of some specialisation within the ITIL fold. Perhaps a bit more work is needed there to make the streams more recognisable to employers.

    So that leaves us with the quality of the current exams. Is the effort required to maintain a professional approach to setting the exams compatible with the current student levels? Would the market accept a change in direction towards an examination process that took as read that a significant number of students would have to resit at least one exam during the course of their training?

    I suspect not.

    Thursday, 18 March 2010

    Is ITSM a Profession?

    A profession lives or dies by the quality of its training.

    The training that qualifies someone to be a member of a profession must not only prepare the new professional for their role, but must also provide others with confidence that they are capable of fulfilling their professional obligations.

    The question we must honestly ask ourselves is whether the current state of ITIL based training  provides a sound basis for a claim that  ITSM can be considered a profession.

    This is a subject I, and others, feel very strongly about. I have been prevaricating  about publishing this post for some time. I have drafted and abandoned several blog posts on the subject out of concern that my comments here should be balanced and fair.  The catalyst for doing so  has been yet another request  from someone who has suffered the consequences of an ill thought out approach to ITIL training.

    Before I go further let me say that I think Aidan Lawes, amongst others, has done an excellent job of raising his concerns about ITIL training with both passion and conviction.

    Those who have read previous posts here will know that my original profession was as an Internal Audit. Like ITSM Internal Audit faced the challenge of becoming established as a profession in its own right.

    There is an extensive literature on what constitutes a profession. Let me very quickly prĂ©cis it.

    • There should be a distinct body of knowledge
    • The body of knowledge should be enshrined in a regulative code
    • Members are bound by a code of ethics
    • The governing body should be composed of qualified members
    • Qualification to practice is based on a combination of practical work experience and examinations.that evaluate professional competence
    • Exclusion of those who do not meet the required standard.
    If we look at Internal Audit we can see it passes all those tests. There is a distinct body of knowledge, that is only directly relevant to internal auditors. The IIA, amongst others, has a set of audit standards and a code of ethics. Full membership of the IIA is restricted to fully qualified individuals, and to be qualified you need to pass both a challenging series of exams and log sufficient hours work across a range of  areas of expertise. As for the exclusion aspect, the exams are deliberately challenging and competitive with a "good" exam paper designed to pass a certain proportion of students. This is a key point that I will return to in my next post.

    Let me briefly look at how ITSM compares to the overall criteria. Superficially it does not look too good.

    Whilst we have grown used to the size of the ITIL books increasing with every new version this is largely the result of ITIL embracing ideas from other distinct disciplines. Far from having a regulative code that enshrines our knowledge it seems that the dominant message amongst ITSM 'experts' is actually that you can do pretty much what you want and still call it ITIL thanks to the mantra of "adopt and adapt".

    Meanwhile what many mistake for our professional body is no such thing, and nor does it claim to be. Membership is purely down to the payment of a fee, and corporate membership and sponsorship is actively encouraged.

    In theory there are requirements for exam delegates to have an amount of practical experience before being entered for the exams, though I have to say I am not aware of this ever being queried or independently verified. As for the exclusivity, apart from the point already made that membership is open to anyone with a credit card it has to be said that the pass rates for ITIL exams are well above those you would  expect to see for most professional exams.

    If that sounds pretty damning it isn't meant to be.

    ITSM does not have to be a profession to be valuable. There is nothing wrong with looking for best practice in other disciplines. A well known barrister specialising in IT cases once said "Of course I have principles. But if you don't like them I can change them." There are many highly respectable and successful trade associations and there is nothing wrong in my eyes with a training course that is designed to provide the delegates with everything they need to ensure they pass the exam at the end of it.

    It just doesn't make it a profession.

    The trouble is deep down in my heart I believe ITSM can be and should be a profession.

    Tomorrow: A Professional Training Scheme

    Tuesday, 16 March 2010

    ITSM Weekly: The Podcast

    The ServiceSphere weekly podcast has been mentioned on these pages before as an excellent source of up to date gossip information on the ITSM scene. Chris DancyMatt Beran and Matt Hooper are the regular presenters, but this week Chris invited me to step in and cover for Hoop.

    You can hear what happened here. 

    We covered a lot of ground. It massively increased my admiration of what the guys do every week in producing an increasingly popular and professional podcast. I know it has become a 'must listen to' for some key people in the ITSM world.

    And Hoop, I think your position as co-host is safe - though Chris has some great guests lined up for future shows.

    Friday, 12 March 2010

    Customer Journey Mapping

    Read This!

    I want to share this link to an article by Arne van Oosterom with you:

    Customer journey mapping

    This is exactly the type of activity that should be central to any ITSM initiative, but it never is, because IT people are so keen to hunker down in a bunker and produce MS Project plans and Visio flowcharts to deal with every possible worst case situation except the ones that occur 100 times a day and leave the user fuming on their journey home.


    Arne is on twitter as @designthinkers 

    Thursday, 11 March 2010

    Brandon Lane CIO - Episode 3

    The Start of a New Week

    Episode 1

    As the lift doors opened before him Brandon Lane had a brief image of herds of wildebeest, zebras and other prey animals on the African plains. He pushed his thoughts of outsourcing aside as he in turn was pushed aside. The culprit was wearing a T-shirt that was already smelling surprisingly stale for so early on a Monday morning.

    Brandon had spent some time thinking about how he was going to make his first appearance as CIO.

    It was a wasted effort.

    His presence on the first floor was greeted with more indifference than patch Tuesday. It made him wonder why his predecessor  was known for his habit of using the fire escape to get to his office with the minimum chance of making eye contact with the staff.

    Wandering between the quasi-cubicles Brandon recognised the dull green coffee stained carpet as being the design that had been stripped out of the rest of the building three years ago. Although it was several years since the IT staff had been prised out of the actual basement, now given over entirely to the machines, the first floor was still referred to by others as "The Basement" and Brandon could see why.

    One thing was very clear, IT didn't get the idea of open plan offices, and they clearly weren't too keen on natural light either. Not only that but... [Editor's note: The rest of this passage has been removed to avoid causing offence to any readers working  in IT who believe that the business retains a stereotyped and outdated perception of what IT staff are really like.]....would all have to change, as well.

    It came as a shock, as he stopped to look at yet another developer's twin screen set up with an 'interesting' screen saver, to actually be spoken to.

    "Hi Brandon, what brings you down here? Lost your dongle again?"

    It was Kelly, one of the Help Desk team leaders. Except he wasn't allowed to call it the Help Desk any more, it was a Service Desk. Brandon wasn't sure he'd noticed any difference since the change.

    He got on well with Kelly, most people did, she was a likeable person. Brandon sometimes wondered if she had to work hard at it or if she was just like that naturally.

    "Kelly, Hi. Busy morning so far?"

    "Hey tell me about it. Someone put in a couple of changes over the weekend and the phones have been going crazy. So a typical Monday really."

    "So why aren't you busy on taking a call then?"

    "Ohh, like you are my boss now, Mr Auditor? We've got it all under control, at least my team has."

    Brandon smiled, he knew Kelly could shift persona in an instant depending on who she was talking to and what the situation was, that was one of her skills. It was a skill he was about to test out.

    "Kelly, just out of interest, who is your boss?"

    "Richard, oh he doesn't get in until after nine on a Monday."

    A glance at Kelly's face, which wasn't much of a hardship on Brandon's part, showed that cogs were whirling and pegs falling into place.

    "Or did you mean Jacques? There were some odd things going on last Friday, Maarten from security was involved. Is there something I should know?"

    Brandon sighed. It was going to be a long first day.

    "You mean no one has told you anything about the changes? Jacques has gone and you've got a new boss."

    By now every peg and cog was in place.

    Illustration copyright Kelly Greening 2010

    "No one ever tells the Service Desk anything in advance, it is Hell. A new boss could change all that"

    She smiled knowingly.

    "Brandon, or should I call you Boss now? .....Welcome to our Hell."

    Brandon Lane now tweets as BrandonLaneCIO.

    Wednesday, 10 March 2010

    CoreITSM 101: Call a call a call

    Contract and SLA negotiation is always an interesting experience., especially when they've already been signed, which is when I usually end up getting involved.

    Here is a typical scenario. The original negotiations have been intense, both side think they've got what close to what they want. The big guns have sorted out the sexy clauses. What nobody has noticed is the time bomb lying in wait. Nobody has noticed it because they think it is something they all agreed on, and anyway it is trivial and obvious what the contract means.

    What is the time bomb?

    It is the clause about the volume of activity that the service desk will handle.

    You see for all the good stuff about service strategy in ITIL v3 it is the simple stuff that trips us up time after time. Like saying "calls" when we mean "incidents" or "incidents" when we mean "requests" or...well it goes on, and ITIL, for all the talk of providing a common vocabulary, doesn't always help.

    Let me give you a couple of real world examples of the chaos that can be caused both by not using the right words and by not understanding the implications when it comes to setting performance targets and penalties.

    An organisation that should know better - not least because it claims to sell ITIL consultancy - outsourced their Service Desk in a separate contract to their main outsourcing deal. The contract specified the number of incidents the Service Desk supplier was supposed to handle and the target time to answer and first time fix rate.

    What the supplier did not realise was that the customer considered the number of incidents to be both a target in itself and independent of the other metrics.

    Think this through.

    The Service desk supplier has limited control over the number of incidents it has to handle. It has rather more control over the number of calls, but we'll save that for the second case. The number of incidents is driven by the underlying quality of the service. In this case they were also classing requests as incidents, and requests are driven by service demand, which again is largely out of the control of the Service Desk.

    So we have a supplier being judged against a target that is almost entirely out of their control.

    Needless to say the underlying quality of service was not there, and a rapidly changing business model meant large numbers of requests. As far as the customer was concerned this was all the Service Desk's problem.

    It goes without saying that handling 25% more incidents the Service Desk struggled to meet the targets for call answering.


    The customer invoked the penalty clauses against the Service Desk provider.
    The customer did not renew the Service Desk provider's contract.

    The tragedy is it what was a really, really great Service Desk.They were performing miracles to handle the extra calls and stay within budget - a budget that also had to take the hit of the penalty payments.

    OK, I hope most people wouldn't be so profoundly stupid, would they?

    Case number two is more understandable.

    The customer's in house IT had always provided a good basic service and whilst the internal Help Desk wasn't the greatest on the planet it fulfilled the "log it and flog it" role quite well, and because they were good at pro actively informing the user of what was happening the ratio between calls and the combined total of requests and incidents was pretty much 1:1. Unfortunately they didn't really track the difference between incidents and requests. I'm sure you do though, don't you?

    For really good reasons they outsourced both the IT infrastructure and the Help Desk to the same supplier, and combined it with a massive change in technology.

    In the contract they specified how many calls the service desk should be able to handle.

    The supplier did a validation exercise and agreed on the number of calls being dealt with prior to the handover.

    This isn't the place to discuss why the technology shift didn't work out as planned, but it didn't.

    What is important is that because in the past there had been a 1:1 relationship between calls and incidents/requests the contract only specified expected call volumes.

    So what happened?

    The technology didn't work, so there were lots of incidents. Because there were so many incidents the desk got overwhelmed, so any pro-active communication went out the window. As a result the number of calls per incident also shot up dramatically to something like 3 calls per incident/request.

    The supplier blamed the customer for generating more requests, although they weren't tracking the ratio of requests to incidents despite it being a contractual obligation.

    The customer blamed the poor quality of service and the lack of communication back to the users.

    And I invoked the penalty clauses and cursed whoever had signed the contract.

    It wasn't pretty.

    In this case there was happy ending of sorts because a period of stability proved that the customer had specified the call volumes to be expected with a stable service and that the desk the supplier provided could cope with those volumes.

    But all that pain could have been avoided if there was a clear understanding of the differences between calls, requests and incidents.

    Next we will look at the use and meaning of call, incident, request, ticket, alert and event with an emphasis on their importance in producing meaningful management reports

    Monday, 8 March 2010

    Once more with feeling

    You might have gathered by now that I am a fan of ISO/IEC 38500.  That is why I find myself torn between two different approaches. Personally I rather like dealing with a bit of tension between  world views, but when you are thinking about an elevator pitch you can only nail your colours to one mast.

    The first is to to promote the value of the standard by highlighting how well it dovetails with other frameworks. This route takes us down the line of mapping 38500 on to COBIT and ITIL and anything else we can think of. Of course this will work, because we can map pretty much anything on to anything and the resulting diagrams always look good. I like the idea of  people not having to change direction just because a new idea comes along, and positioning ISO 38500 as a mechanism to bring cohesion to the mix has some attractions.And yes one of the first things I did when I got my hands on a copy of the standard was to start mapping it on to ITIL v3.

    So why do I feel a little uncomfortable about it?

    First of all I worry that mapping will lead us to try and de-construct 38500 and reassemble it from existing components as an intellectual exercise. Secondly I worry that once it has been disassembled  people will be tempted to cherry pick the bits that they want, and they won't end up choosing the most important elements of it.

    Anyone who has been involved with SOX will know there is a corporate tendency to sit there and think "Can we get away with not doing that?"

    So what is the second approach?

    I think it is about looking forwards not backwards.

    Rather than thinking about how we can use ISO 38500 to validate what we have already done think about how we can use it to move beyond the limitations of the existing frameworks. In particular think about how we can use it in ways that are distinctive from the way IT normally does things.

    Why don't we use it to put some heart and emotion into IT.

    More to follow...

    Tuesday, 2 March 2010

    Are you too competent to give advice?

    "Trust me, I know what I am doing"
    Inspector Sledge Hammer

    Why do they cancel all the best TV shows? Take "Sledge Hammer!", it only ran for two seasons. Crazy.

    Recently I've written a couple of posts on Instant IT Experts and ITIL as a Cargo Cult that have attracted some attention. Both of them highlight examples of the Dunning-Kruger effect summed up by their excellent paper "Unskilled and Unaware of it". For those who haven't come across it before the paper provides evidence that those who lack a skill are not capable of judging how bad they are at that skill compared to others, or how good others are at that skill. Hence they tend to massively over estimate their own ability and underestimate that of others. 

    I first became aware of this effect at an organizational level during my involvement with the BQF and the EFQM Excellence Model. Organizations that were new to the scheme tended to self assess themselves at a level that exceeded what you would expect from world class operations.

    In the educational world a model of concious competency has been around for may years. This posits that people move through four stages:
    • Unconscious incompetence
    • Conscious incompetence
    • Concious competence
    • Unconscious competence
    The point I want to make in this post is that we have a responsibility to identify which of those stages people and organizations are at before we offer them advice, and the advice we give should be tailored to the stage they are at. 

    A lot of the "bad" advice I'm seeing out in ITILland is not intrinsically bad, but it becomes dangerous when handed out without due care and attention. I suspect a particularly dangerous kind of advice is the sort that is intended to only apply in specific instances, but which can be taken as a general rule.

    And I guess most of us have fallen into that trap at one point or another. As a trainer I became very aware that a throwaway comment could often be picked up on as a guiding principle by a student who totally ignored the bit which you went out of your way to say was really really important.

    Where ITIL is concerned I think it is particularly dangerous because ITIL itself does not conform to any clear sound generic principles. Hence attempts to characterize it, including my own, are probably doomed to failure.  Bits of it are proven good practice, some of it might be considered best practice, other parts might be sub-optimal and yet others untried blue sky thinking. Some of it might be considered descriptive, other parts are clearly intended to be prescriptive for all practical purposes. In places it tells you the why, in others it tells you some of the how, but  not always. We live in a world though where people struggle with ambiguity and want black and white answers.

    There is a tendency when talking to others to take their own assessment of their competency at face value and to see their understanding through your own eyes. The less concious you are of your own ability the less you might  realise that not everyone shares your wisdom and some still need to learn the basics of ITIL 101.

    A physicist I know put it like this.

    "At school in the lower grades they teach you that physics explains how the world behaves, but they lie to you about how it does that.

    In the higher grades they tell you that how it really works is like this....but when you get to university theyt ell you that was a lie as well and how it really works is like this...

    Then you become a professor, and realise nobody has any real idea about how it really really works."

    Monday, 1 March 2010

    The Campaign for Real Audit

    Matt Hooper recently mentioned on one of the excellent ServiceSphere podcasts that he and I have been discussing the use  and abuse of audit terminology in the ITSM world.  It is something I've got used to over the years, but then around the same time Matt was raising his queries my hackles were raised by someone on Linkedin claiming expertise in audit after completing just the ISO 20000 auditor's course - which actually presumes you should already be a qualified auditor, and then on my v3 Bridge Course the tutor made a throwaway comment that reminded me ITIL still doesn't seem to understand what audit is all about.

    Why does this bother me? Have you ever noticed that the more familiar you are with a subject the less accurate and more controversial the Wikipedia entry for it is? Well as it says on the right somewhere I was a professional internal auditor before I got drawn into the crazy world of ITIL.

    I'm actually going to leave ISO audit to one side for now. Let us just says it does what it says on the can and nothing more.

    I want to focus in particular on internal audit. In fact let me say that again, slightly differently. I want to focus in particularon Internal Audit. Notice the difference? No? Oh well I guess that means you probably aren't cut out for a career as a stereotypical tick and turn auditor. You might still make it as a professional auditor though if once you spot the difference you can see the implications of it. Of course it isn't as easy as that. You'll need to do some exams, get some independently verified experience under your belt, and commit to adhere to your professional body's standards.*

    If that sounds too much effort, what about reading a book?

    Yes it is a little expensive, but then it does weigh in at 7.5 pounds and nearly 1500 pages.

    Too busy huh?

    A Brief Guide To Internal Audit

    Well let me sum it up for you, though my apologies to any currently practising auditors if I'm a little out of date.

    Let us begin with where audit should sit in the organization. Internal Audit should have no executive responsibilities and report to the board and/or the audit committee. In some organizations the Chief Internal Auditor can only be removed from post by a vote of the board. Why? Because internal audit needs to be, and to be seen to be, independent and objective in the assessments and recommendations it makes.

    What does Internal Audit assess and make recommendations about? Systems of internal control.

    In the words of Sawyer

    "Control is a force, it gets things done"

    A process without controls is, well, out of control.

    So how do we assess the system of internal controls?
    • We need to understand the objective of the system.
    • From that we can derive the control objectives.
    • The control objectives allow us to identify appropriate control mechanisms.
    • We use techniques such as statistical sampling to check the controls are in place and working.
    Just knowing about individual controls doesn't give us sufficient assurance. It might be there is a very good individual control but it can be circumvented, or is weakened because of a lack of control elsewhere. Alternatively it might be that a number of controls that are not individually effective work together to provide an acceptable level of control. That is why we look at systems of internal control. 

    In theory if all the controls are in place and working we can predict that the process they are controlling will be effective, efficient and economical, which has led to the concept of Value for Money (VfM) audits where we assess activity against those 3 criteria.

    Some of this might be starting to sound familiar to you, especially if you use COBIT, because COBIT was first developed as a framework for auditors.

    Audit and ITIL
    So what are the implications for ITIL?

    To go back to Matt's original question to me I don't think we should use the term audit unless the element of independence and objectivity backed up by organizational position, reporting lines and adherence to professional standards is in place.

    A review of your "ITIL maturity" carried out by a consulting firm with an interest in bidding to deliver your ITIL training and transformation programme is not an independent audit. Oh just sit bolt upright and smell that scent of freshly brewed Java with a double shot.

    Neither is a review carried out by a function or an IT department to assess its own capability an audit. That doesn't mean you shouldn't do one, by the way.

    I said I would leave ISO certification audits out of this discussion, but I will say that if I ever employed an ex ISO auditor as an Internal Auditor I would expect them to go through the full professional training scheme. I make that point without meaning to undermine what they do, but I want an IS auditor who can do things ISO auditors don't do, such as a code review or recreating an interrogation of the service management tool..

    One of the biggest shortfalls for me with how  ITIL is currently understood is the willingness of professional advisor's to say IT departments have total freedom to pick and chose which elements they implement.  As an ex-auditor doing a review I would have to point out that leaving out certain elements of ITIL can effectively undermine the value of an entire process, and the processes that depend on that process.That in turn exposes the organization to enterprise level risks. If I didn't point out that to a client as an auditor I would leave myself open to a charge of professional malpractice.


    *To avoid any allegations of misrepresentation I've used the IIA standards as an example because I find them accessible and straightforward. I will point out though that although I taught students undertaking the IIA UK examinations for seven years the professional standards I was bound by myself were those of the Chartered Institute of PublicFinance and Accountancy and the UK Government Internal Audit Standards (GIAS) . I am currently a member of ISACA and have passed their CISA examination, but since I do not practice I am not eligible to use the CISA designation.

    Fore readers outside of the UK who might not be familiar with it here is a link to the real CAMRA