How to conduct an ITSM assessment that actually means something

ITIL (Information Technology Infrastructure Library), a standard framework for managing the lifecycle of IT Services, is sweeping the U.S.   Based on a 2011 analysis of 23 ITIL studies, Rob England concluded that the compound annual growth in ITIL adoption was 20%± and that ITIL training attendance increased at a compound annual rate of 30% for the past ten years.  Despite this apparent surge of adoption, enterprises continue to struggle with ITIL’s daunting framework.

Recognizing the confusion inherent in ITIL alignment, numerous vendors have created “ITSM assessments” with varying degrees of complexity and debatable value.  These assessments draw upon frameworks such as ITIL, CMMI-SVC, Cobit and, occasionally, BiSL or more specific constructs such as KCS and IAITAM.  Where does one begin?  What is most important?  Where will improvement deliver the best payback?  How can one ensure that all phases of implementation share a common and scalable foundation?

Fundamental Assessment Approach
Figure 1: Fundamental Assessment Approach

All assessments follow a pretty basic formula:

  1. Determine and document the current state of ITSM in the organization.
  2. Determine and document the desired state of ITSM in the organization.
  3. Establish a practical path from current to desired state (roadmap).

Simply stated, the objective is to successfully execute the ITSM roadmap, thereby achieving a heightened level of service that meets the needs of the business.  But don’t let those vendors through the door just yet because this is where ITSM initiatives go sideways.

Current state, desired state and roadmap mean nothing without first establishing scope and methodology.  How comprehensive should the assessment be?  Does it need to be repeatable?  Which processes and functions should be targeted?  Should it be survey-based?  Who should participate?

Rather than seeking input from the ever so eager and friendly salespeople, one can follow a simple three-step exercise to determine scope and methodology.  These steps, described in the following sections, may save you millions of dollars.  I have seen dozens of large enterprises fail to take these steps with an estimated average loss of $1.25M.  For smaller enterprises ($500M – $1B in revenue), the waste is closer to about $450,000.  The bulk of this amount is the cost of failed projects.  In some instances those losses exceeded $10M (usually involving CMDB implementations).

Three Steps to a Meaningful ITSM Assessment

Though these steps are simple, they are by no means easy.  For best results, one should solicit the participation of both IT and business stakeholders.  If the answer comes easily, keep asking the question because easy answers are almost always wrong.  Consider using a professional facilitator, preferably someone with deep, practical knowledge of ITIL and a solid foundation in COBIT and CMMI-SVC.

So, the three steps are really three questions:

  1. Why do you need an ITSM Assessment?
  2. What do you need to know?
  3. How do you gain that knowledge?

Step 1:  WHY Do You Need an ITSM Assessment?

IT Service Management aligns the delivery of IT services with the needs of the enterprise.  Thus, any examination of ITSM is in the context of the business.  If one needs an ITSM assessment, the business must be experiencing pain related to service delivery.

  1. Identify service delivery pain points.
  2. Map each pain point to one or more business services.
  3. Assign a broad business value to the resolution of each pain point (e.g. High, Medium, Low).  Divide these values into hard savings (dollars, staff optimization), soft savings (efficiency, effectiveness), and compliance (regulatory, audit, etc.).
  4. Map each pain point to a process or process area.

There should now be a list of processes with associated pain points.  How well can the business bear the pain over the next few years?  With this preliminary analysis, one should be able to create a prioritized list of processes that require attention.

For now, there is no need to worry about process dependencies.  For instance, someone may suggest that a CMDB is required for further improvements to Event Management.  Leave those types of issues for the assessment itself.

Step 2: WHAT Do You Need to Know?

 

Four Assessment Needs
Figure 2: Four Assessment Needs

Now that the organization understands why an assessment is required (of if an assessment is required), it can identify, at least in broad terms, the information required for such an assessment.

Referring the chart in Figure 2, IT management need only ask four questions to determine the needs of an assessment.

Is ISO/IEC 20000 Certification Required?

If the organization requires ISO/IEC 20000 certification, a Registered Certification Body (four listed in the U.S.) must provide a standardized audit, process improvement recommendations, and certification.  For most enterprises, this is a major investment spanning considerable time.

Does Repeated Benchmarking Provide Value?

Does the organization really need a score for each ITIL process?  Will the assessment be repeated on a frequent and regular basis?  Will these scores affect performance awards?  Will the results be prescriptive or actionable and will those prescribed actions significantly benefit the business?

The sales pitch for an ITSM assessment usually includes an ITIL axiom like, “You can’t manage what you don’t measure” (a meme often incorrectly attributed to Deming or Drucker).  One must ask if scores are the best measure of a process?  To what extent do process maturity scores drive improvements?  Not much.  Each process has its own set of Critical Success Factors, Key Performance Indicators and metrics.  These are far more detailed and effective data points than an assessment score.  Ah, but what about the big picture?  Again, ITIL and COBIT provide far more effective metrics for governance and improvement on a macro level.

That said, there are some pretty impressive assessments available, some with administrative functions and audience differentiation baked into the interface.  However, one should build a business case and measure, through CSFs and KPIs, the value of such assessments to the business.

Do you need an ITSM Strategy and Framework?

Does the organization already have an intelligent strategy for its ITSM framework?  Is there a frequently refreshed roadmap for ITSM improvement?  For most enterprises, the honest answer to this is no.  Numerous Fortune 500 enterprises have implemented and “optimized” processes without strategy, roadmap, or framework.  The good news is that they keep consultants like me busy.

To build an ITSM strategy, an organization needs enough information on each process to prioritize those processes as pieces of the overall service workflow.

To gauge the priority of each process, we focus on three factors:

  • Business value of the process – the extent to which the process enables the business to generate revenue.
  • Maturity gap between current and desired state – small, medium or large gap (scores not really required).
  • Order of precedence – is the process a prerequisite for improvement of another process?

To complete the strategic roadmap, one will also need high-level information on ITSM-related tools, integration architecture, service catalog, project schedule, service desk, asset management, discovery, organizational model, business objectives, and perceived pain points.

Are You Targeting Specific Processes?

To some extent, everything up to this point is preparation and planning.  When we improve a process, we do that in the context of the lifecycle.  This task requires deep and detailed data on process flows, forms, stakeholders, taxonomy, inputs, outputs, KPIs, governance, tools, and pain points.

As this assessment will be the most prescriptive, it will require the most input from stakeholders.

Step 3:  HOW Do You Gain that Knowledge?

Finally, the organization identifies the assessment parameters based on the data required.  Similar to the previous step, we divide assessments into four types.

ISO/IEC 20000 Certification

The only standardized ITSM assessment is the audit associated with the ISO/IEC 20000 certification (created by itSMF and currently owned and operated by APM Group Ltd.).  The journey to ISO 20k is non-trivial.  As of this writing, 586 organizations have acquired this certification.  The process is basically measure, improve, measure, improve, ………. , measure, certify.  Because the purpose of improvement is certification, this is not the best approach to prescriptive process optimization.

Vendor-Supplied ITSM Assessment

The administration, content, and output of ITSM assessments vary wildly between vendors.  In most cases, the ITSM assessment generates revenue not from the cost of the assessment but from the services required to deliver the recommended improvements.

Rule #1:  “If you don’t know where you’re going, you’ll probably end up somewhere else” (Lawrence J. Peter).   Without a strategy and roadmap, assessments will lead you to a place you would rather not be.

Rule #2:  The assessment matters far less than the assessor.  When seeking guidance on ITSM optimization, one needs wisdom more than data.  A skilled assessor understands this workflow in the context of a broader lifecycle and can expand the analysis to identify bottlenecks that are not obvious from an assessment score.  An example is Release Management.  The Service Desk may complain that release packages are poorly documented and buggy.  Is that the fault of the Release Manager or is it a flaw with the upstream processes that generate the Service Design Package?

Rule #3:  Scores are only useful as benchmarks and benchmarks are only useful when contextually accurate (e.g. relative performance within a market segment).  Despite the appeal of a spider diagram, avoid scored assessments unless compelled for business reasons.  Resources are better spent analyzing and implementing.

Rule #4:  An assessment without implementation is a knick-knack.  Validate the partner’s implementation experience and capability before signing up for any assessments and be prepared to act.

Rule #5:  A free assessment is a sales pitch.

Rule #6:  A survey-based assessment using a continuous sliding scale of respondent perception is a measure of process, attitude, and mood.   So is a two year old child.

Rule #7:  In ITSM assessments, simpler is better.  Once a vendor decides that the assessment needs to produce a repeatable score, the usefulness of that tool will decline rapidly.  If you doubt this, just look under the covers of any assessment tool for the scoring methodology or examine the questions and response choices for adherence to survey best practices.

Strategy and Roadmap Workshops

Enterprise Service Management strategies save money because not having them wastes money.  Without guiding principles, clear ownership, executive sponsorship, and a modular, prioritized roadmap, the ITSM journey falters almost immediately. Service Catalogs and CMDBs make a strategy mandatory.  For those who lack an actionable Service Strategy and Roadmap, this is the first assessment to consider.

An enterprise needs an experienced ITSM facilitator for strategy workshops.  Typically, the assessment team will perform a high-level process assessment, relevant tool analysis, framework architecture integration study, and a handful of half-day workshops where the gathered information is molded into a plan for staged implementation.

Targeted Process Assessments

Organizations know where the pain points are and have a pretty good sense of the underlying factors.  The assessor finds this knowledge scattered across SMEs, Service Desk personnel, business line managers, development teams, project office, and many other areas.  The assessor’s value is in putting these puzzle pieces together to form a picture of the broader flows and critical bottlenecks.  Through the inherited authority of the project sponsor, the assessor dissolves the organizational boundaries that stymy process optimization and, with an understanding of the broader flow, assists in correctly identifying areas where investment would yield the highest return.

For these assessments, look for a consultant who has insightful experience with the targeted process.  An assessment of IT Asset Management, a process poorly covered in ITIL (a footnote in the SACM process), requires a different skill set than an assessment of Release and Deployment Management or Event Management.

The output from a Targeted Process Assessment should be specific, actionable, and detailed.  Expect more than a list of recommendations.  Each recommendation should tie to a gap and have an associated value to the business.  Essentially, IT management should be able to construct an initial business case for each recommended improvement without a lot of extra effort.

Summary

Liam McGlynn
Liam McGlynn

Organizations are investing tens of millions in ITSM assessments.  I have seen stacks of them sitting on the shelves of executives or tucked away in some dark and dusty corner of a cubicle.  Whether these assessments were incompetent or comprehensive, as dust collectors, they have zero value.

How prevalent is the lunacy of useless ITSM assessments?  From my own experience and from conversations with others in the field, vendors are selling a lot of dust collectors.  Nobody wants to be the person who sponsored or managed a high-profile boondoggle.

So the advice is this.

  • Don’t waste time on scores because there are better ways to sell ITSM to the board than a spider diagram.
  • Develop and maintain an ITSM Strategy and Roadmap.  As Yogi Berra once said, “If you don’t know where you’re going, you’ll wind up somewhere else”.
  • Assessing and implementing need to be in close proximity to each other.
  • Get an assessor with wisdom who can facilitate a room full of people.
  • Finally, follow the three steps before you let the vendors into your office.

The journey may have many waypoints but let’s just make it once.

Liam McGlynn is a Managing Consultant at Fruition Partners, a leading cloud systems integrator for service management and a Preferred Partner of ServiceNow.  

Quick Guide to Knowledge Management Tool Selection

"Tomatoes don’t go in fruit salad"
“Tomatoes don’t go in fruit salad”

In this extended article, Barclay Rae provides an independent guide to Knowledge Management and in particular Knowledge Management tool selection.

Knowledge Management can be many things – from simple useable checklists to complex context-sensitive and case-based toolsets.

Some of the most effective knowledge solutions can be very basic, like lists of contact details, account numbers or simple spreadsheets.

The key to success is in getting people to use these sources and continuing to use them (and find them useful).

Good practical design is key to building tools that provide information and knowledge quickly, intuitively and appropriately – and that are regularly and continuously used.

For IT Support in particular this means:

  1. Getting the right level of information – accurate, up to date, relevant, useable
  2. To the right person – being aware of the support model and the levels of knowledge held at different support levels
  3. In a language and format that is appropriate for them – technical or not, plus summary or detailed, as required for the relevant support level and skillset
  4. Quickly and when and where they need it – Without need for long searches or trawling through long lists of options, delivered at the point of service or action as required.
  5. Context is everything – too technical or not technical enough, out of date, inappropriate, complex, slow – tools must be able to understand and deliver on these within a clearly context, otherwise the ‘knowledge is useless or even dangerous.

So, what is Knowledge Management?

This is the process or discipline that ensures that teams have relevant information to hand, to assist in having a clear understanding of a situation. Knowledge Management is the process that manages the capability to provide that information, based on accurate and relevant data. If the information is available at the right place and time, then those people accessing it can make more informed decisions and also speed up the support and resolution process – i.e. by reducing the need to escalate.

What Does Knowledge Management mean in ITSM?

Knowledge management is not just about getting information fast when trying to solve incidents, although this is a good practical starting point for many organisations. Data gathering, solution design, process design, knowledge transfer are all key elements – across all of IT and beyond. Knowledge should be able to be applied at all parts of the service ‘supply chain’ to ensure that this is built in a robust, complete and effective way. ‘Knowledge Management’ can be Data, Information, Knowledge or Wisdom (see list below) – all differing levels of content or applied and documented understanding that provides value in terms of improvements in service quality and efficiency.

  • DATA – Ten tomatoes
  • INFORMATION – He bought ten tomatoes
  • KNOWLEDGE – A tomato is a fruit
  • WISDOM – Tomatoes don’t go in fruit salad

Tools capture, store and make that information available, and relevant. Getting the right information to the right person – at the right level when they need it – is the goal. The easiest elements to identify and apply ‘knowledge articles’ to are Incidents, Problems and Service Requests. This should also be extended to Changes, Releases, CIs, Services, offerings, processes and workflows – all aspects of service delivery, where information and knowledge is needed. Key elements for tools should be in the ability to easily create, approve, review, update store and make available knowledge articles – i.e. secure curation. In addition the integration of these knowledge functions to other areas of ITSM should be seamless. Integration and alignment with other internal and external sources of knowledge is also useful, as is any formal approach or verification around approved techniques for KM – e.g. like KCS (Knowledge Centred Support). Like many aspects of ITSM technology and practice (and software in general) the value and success of this rests as much with the approach and focus around implementation, culture and governance, as it does with functionality. Vendors need therefore to possess understanding, skills and expertise in implementing these solutions and be geared up to pass on these skills to clients for successful implementation.

Knowledge Management Functionality

Knowledge Creation – systems should have the facility to easily create ‘knowledge articles’ (KAs). These can be original records (i.e. specific work instructions or content), and/or packages of content including documents. Linking – Content can be intelligently and seamlessly linked to external sources – tech manuals, wikis etc. Knowledge Curation – there should be definable process workflows to control the lifecycle of KAs as follows:

  1. Creation of record – ad hoc or as part of a defied process (e.g. release, change)
  2. Approval of record – functional escalation to pre-defined approver or approver group
  3. Publishing/Release of record
  4. Presentation of record – use of KA as designed and required
  5. Review/update of record
  6. Removal / archiving of record
  7. Tracking and assessment of use of record

Knowledge Sharing – promotion of process and information across systems and channels as required. Presentation of KAs:

  1. To multiple staff levels by login
  2. Presentation from searches (queries/predictive) on key classifications – type, impact, product, service, symptom, error message etc.
  3. Presentation of options based on case-based search criteria and probability
  4. Presentation as integral components of ITSM processes:
    • i.     Incident Management – issue resolution, triage
    • ii.     Service Desk – work instructions, manuals, fault fixing
    • iii.     Problem Management – known error records
    • iv.     Change Management – procedures and guidance
    • v.     Configuration Management – procedure and guidance
    • vi.     Services and Service offerings – Procedure and guidance
    • vii.     Request Fulfilment – Procedure and guidance
    • viii.     Release and Deployment Management – Procedure and guidance
    • ix.     Transition – Testing & Verification – testing notes guidance
    • x.     Service Introduction – support notes and guidance
  5. Vendors should show innovation through integration and interaction with new products and areas of technology – e.g. integration with Knowledge lockers like Evernote, Onenote, etc
  6. Self-help access to users via self-service portals – providing user friendly versions of internal KAs
  7. Crowdsourcing – links to Incident and Problem Management processes for access to outstanding issues and inputs to create known error records

Knowledge Development – ability to update and improve knowledge articles and also to assess the value of usage as input to predicting new records or record types Intelligence – Systems should show innovation by learning from existing records – types, content and usage – and prompting to create new KAs.

Vendor Approach

  1. Vendors should demonstrate a clear understanding of how to approach Knowledge integration within their (and with other) products
  2. Innovation in approach and delivery are a differentiator – e.g. beyond simple functional KA creation and management
  3. Project management and tool implementation should include guidance, training, workshops etc. on strategic and technical aspects of Knowledge Management
  4. KCS accreditation and proof of capability desirable

General Knowledge Management Requirements

  1. User-configurable forms, tables, workflows
  2. Should be able to create user-defined rules for creation (e.g. mandatory fields) and lifecycle management (e.g. who, how when revised and updated.
  3. Lifecycle activity should trigger escalation processes – (e.g. automated emails/ texts to approvers, reminders etc.)
  4. Role-based security access – to allow control of access and level of information by login
  5. Ability to provide multiple levels and formats of information in KAs – i.e. bullet points for senior technical levels, scripted specific details for junior / non-technical staff.
  6. Vendors should provide expertise and guidance in the implementation of the tool and relevant processes and project requirements around Knowledge Management – e.g. with workshops and training as well as implementation consultancy.
  7. Open system for real-time integration with external ITSM.
  8. Vendors should have established proven links with other ITSM tools and modules, Incident, Problem and Change Management, CMDB and Service Catalogue.

Barclay will soon begin a competitive review of Knowledge Management technology. If you offer technology in this area and would like to participate in our next review please contact us.

Photo Credit 

The “Capita” Label – A Red Herring Swimming in the Moat of Castle ITIL

Chris Barrett, Capita
Chris Barrett, Capita

Ever since the announcement of the Cabinet Office and Capita Group Joint Venture, the great, the good, and some of the rest have speculated here and there about the future of the Best Practices Portfolio.

Chris Barrett (currently a Transformation Director at Capita Consulting) is one of the first of the newly appointed management team for the new joint venture company, and spoke to us at the Knowledge 13 event, Las Vegas.

The Issue of Communications

The first question had to look at the communications, lack of and standard of (which is ironic given our collective jet-lagged state, at the time).

The first e-bulletin had just come out, and it is clear that the press office still needs some time to settle in to converting dry releases into something that gives the waiting ITSM public some further insight, without jargon.

At several times, he was keen to emphasis that Capita is actually more of a red herring/misnomer (which explains why a number of questions were pointed directly at Capita Group).

He said: “If there was one thing Capita was good at, it was fulfilling a remit – for example stripping out costs from a business.”

“But if people are thinking this is a land grab, they would be completely wrong.”

“We are not a corporation, we are a small joint venture.”

“The idea is to grow and invest in the community – this is about a duty of care, and custodianship.”

Whilst communications have been light and/or dry as toast, there has been a lot of work going on behind the scenes.

There will be a twitter feed and a continuation of the e-bulletins, but resources to manage the media side of operations are yet to be appointed.

The Team To Be

In terms of the physical set up, the Chief Executive has been chosen, and the management team are being finalised.

TUPE discussions are continuing regarding members of the Cabinet Office and TSO, due to come across at the end of this year (UPDATED: See comment from Chris Barrett of the Capita JV below)

For many who have actively contributed to the best practices publications, the emphasis on being a non-corporate joint venture still allows them have that airtime – if they so choose.

“Can it be altruistic?” I asked Chris

“It can be, if it serves the community and if we cut them out, how stupid would that be.”

Here is where I think the balance of power shifts.

Let’s be honest – people who have actively contributed in the past do not really need the kudos of adding that involvement to a CV or resume any more.

But there are also many people coming up now, through the ranks, with strong practitioner knowledge, and with the support and encouragement of those previously involved.

There is also an opportunity for those who have, in the past, rebelled at the gates of the fortress – surely now is their time to help shape the best practices to what they believe it should be?

Or will they choose to ignore this emerging spirit of collaboration with the community, and continue to throw stones into the moat?

Linda King and Ros Satar
Linda King and Ros Satar

Pragmatism Over Theory

A number of questions came in through various social media feeds, for us to ask and interestingly a lot seemed to focus on how Capita does things now.

Capita favours the pragmatic approach – referring to principles where appropriate but not purely for the purpose of using them for use’s sake.

It therefore stands to reason that going forward, the emphasis continues to be on the pragmatic application of these established best practices, to demonstrate real-world benefit.

As with everything that took place before, a lot of consideration will need to be given to the release programs for new versions.

This, in turn, led to an interesting revelation that the Cabinet Office themselves do not see the Swirl brand as having traction outside the UK’s shores, despite the information email ID being swirlenquiries.

Spending Spree Or Visionaries?

Interestingly, the most recent acquisitions (Knowledge Pool and Blue Sky) were never part of the original plan, but the inclusion of G2G3 was part of the original bid.

Even if they had not been acquired, the plan would have been to involve them anyway, and they look to be all set now in terms of training and simulation approaches.

Community

Chris was asked whether the joint venture were looking to create their own, newer community, for example in the mould of  Back to ITSM?

The plan is to have to have a portal approach and a formal home for people to land on.

Ideas being considered are a subscription-plan for more detailed material – this was seen as no different to paying money for training courses.

What is the Joint Venture NOT going to be

Chris confidently lined up his views:

  • “Not going to stagnate
  • Not going to be purely theoretical
  • Involving real practitioners and serving community members
  • Not going to be “Castle ITIL”

I wanted to be honest with Chris – those statements are pretty bold, but as someone still active both in consultancy and analysis on the ITSM side, this is good fighting talk.

Meet Them At The Gates

Whilst I can see a sense of continued cautiousness from those who have been discussing the future, the new joint venture are very much seeking and wanting continued dialogue.

The sense of community was a recurring theme, and as a member of this community, I think we owe it to the joint venture to try and meet them at the gates of our beloved “Castle ITIL”.

(With thanks to Adam Holtby, Linda King, and a special nod to Rob England’s suitably Skeptic “Castle ITIL ™” tag which the new company liked but equally are willing to meet, head on).


Updated: Capita folks interviewed live at Knowledge13

ITSM Weekly Podcast Episode 112 – The Capita Interview


via ServiceSphere

Capita and ITIL: The Good, The Bad and the Ugly

GBU

The Cabinet Office has entered into a joint venture with the outsourcing firm Capita to develop the ‘Best Management Practice’ portfolio, which includes ITIL and Prince2.

For readers outside the UK the early announcements may benefit from some context.

The UK treasury is between a rock and a hard place financially so joint ventures that generate cash from government owned intellectual property, whilst allowing the government to hold (49%) of the coat tails of growth in the future is good publicity.

This explains why most announcements in the popular press or general IT press in the UK have focussed on the ‘cash generated for taxpayers’ angle rather than the implications for ITSM.

“The government expects to earn £500 million over ten years from the deal” Computerworld, 26th April.

Unsubstantiated rumours from SITS13 suggest that APM Group/TSO, Pearson and EXIN/Van Haren were the other companies bidding for the portfolio.

Forgetting where it all started?

I have been interested to see industry veterans and ITSM spokespeople alike bellyaching about the irrelevance of ITIL after the announcement. I find this short-sighted nonsense similar to those irate individuals who get frustrated behind learner drivers.

Is ITIL the ITSM gospel? No. But it is the starting point and development path for a huge amount of individuals in the industry who work in ITSM yet don’t necessarily associate themselves with the ITSM industry.

Is ITIL perfect? No. But everyone has to start somewhere and as a framework for unifying an industry and generally raising standards I would say, in the context of other IT disciplines over the last two decades, it is true success story.

So what does the future hold for ITIL under the stewardship of Capita?

The Good, The Bad and the Ugly

Capita – The Good

Capital Plc. is a FTSE 100 publicly listed company with 53,000 staff, which has shown good growth over the last five years despite a grim economic climate.

So it has exactly the right resources required to give the frameworks the attention they deserve. Equally, you could argue that Capita could easily write off the entire mess if it isn’t happy with it without batting an eyelid, but overall a well financed company on the up has to be better than a cash strapped government running the show.

A view echoed by Barclay Rae:

“We should view the investment opportunity as a possible means to further professionalise the approach and delivery of ITIL – moving away from the cottage industry to a proper business model. So hopefully this will mean a more professional and co-ordinated writing and editing approach for consistency, plus I hope e.g. we can see more clear business metrics and data that support the value derived from ITIL”

The UK government spun off the former defence research department (DERA) in 2001 in a similar fashion to form Qinetiq, which is now a FTSE 250 company, pocketing over £250m for the UK taxpayer on exit in 2008. So at first glance the model works if executed correctly.

Just before the announcement of the joint venture, Capita also acquired G2G3. This is a good sign according to Pink Elephant President David Ratcliffe:

“The timing of Capita’s acquisition of G2G3 – just days ahead of the announcement of the partnership with the Cabinet Office – looks to me like Capita may have their act together with a strategy for how to promote and deliver more valuable training in the ITSM field. I just hope I’ve read this correctly and am not setting myself up for a huge disappointment! (Fingers, toes and everything else crossable all crossed!)”

Mark R Sutherland of G2G3 is clearly pleased at the platform this provides his company:

“Capita’s strength, scale and global reach. As part of the Capita family, G2G3 now has access to resources that will help us strengthen and build upon our products and services and bring our latest innovations to life. We are clearly at a ‘tipping point’ with respect to our capabilities; the application of gaming dynamics and experiential learning across enterprise organizations is about to go mainstream – and we’ll be ready to make it happen.”

Mark also makes an interesting point regarding the ITSM industry as a whole:

“a chance to build a future for our industry which is based on community, collaboration and engagement.”

Stuart Rance with ‘Two speed ITIL’ and Stephen Mann with #Back2ITSM may perhaps now get some formal recognition. Is Capita listening? Let’s hope so.

Capita – The Bad.

So far so rosy?

Those outside the UK might not be familiar with the public image of Capita.

Screenshot_02_05_2013_22_11

Capita does not have the strongest reputation. The satirical magazine Private Eye regular refers to ‘Crapita’ as an example of ‘failures and setbacks in the public sector’ and cynics will argue that Capita is an expert at winning tenders rather than delivering them (to be fair I hear this of all outsource companies).

Lost convicts, the CD with everyone’s inside leg measurements or accidently dropping the cat down the well – all archetypal Capita public bungles. Although you could argue that this goes with the territory of managing high profile public services (National census, criminal records, TV licensing, Major city call centre, health and safety executive etc.).  As the saying goes: Where there’s muck there’s brass.

For an industry crying out for more collaboration and industry participation the last thing we need is a big faceless corporate. Especially, as Chris Evans points out, if they take an industry best practice framework and try to apply their own badge to it:

“When any large organisation is involved in something, they will exert a proportionate influence.  Be it an alliance of countries/airlines/software companies, it is inevitable that they will want something out of the deal.  My concern is that ITIL (specifically as it is my day job) which has always been ‘industry’ best practice, might slowly evolve into ‘CapITIL’ where the organisational thinking of the parent company controls the direction of the product.  It is true that Capita as a services provider and outsourcer has a strong perspective on their market and that input will of course be welcome in future development but there is a risk that the model will lean towards their world and not the more holistic picture.”

Capita – The Ugly

Finally, it is worth considering the nature of Capita’s core business.

Capita is a Business Process Outsourcer. So Capita’s competitors might argue that a Burglar Alarm company just bought the Police Station (I’m sure there are more appropriate metaphors). The new joint venture will have a job on its hands to persuade the Accredited Training Organizations and others in the ITIL supply chain of the true vision and motives of the, yet to be named, joint venture company.

As Forrester Analyst Stephen Mann points out:

“Will other IT service providers still want to use something that “advertises” their competitors?”

As an eternal optimist I believe it’s a great move forward for the ITIL cult and ITSM industry as a whole. Exciting times.

For those with ITIL at the core of their day-to-day work – it might be worth considering the following over the next couple of months:

“All great changes are preceded by chaos.” -Deepak Chopra.

Image Credit

How good Change Management can still sink ships

RMS Titanic departing Southampton on 10 April 1912

The sinking of the Titanic has become synonymous with epic failure, brought on by ego and arrogance.

But if you look at the immediate actions of the crew, you’ll find a fairly rapid and well orchestrated response to a (Emergency) Request for Change.

The Titanic Story (in short)

The lookouts were perched high in the crow’s nest scanning for danger. History has it they were without binoculars, doing their best to fulfil their duty as early warning. Captain Edward Smith was a well seasoned and decorated captain with the right experience and background to captain such a mighty ship. Though other ships had reported icebergs in the area, and it’s irrefutable that he was aware of the dangers, his orders were full steam ahead.

When the lookouts first spotted the infamous iceberg, they immediately sounded the bell and notified the bridge. First Officer Murdoch order “hard astarboard!”, signaled full stop, and then full reverse. All executed with speed and practiced precision.

And then they waited anxiously to see if the helm responds in time – if the changes will turn this mighty ship in time to avert disaster. Less than a minute later; impact, and the rest, of course, is history.

The parallels to IT Service Management are helpful in understanding the difference between Change Management and Change Enablement.

Change Management

Traditionally, Change Management focused on quickly and effectively implementing business-required changes without producing negative business impact. (“screw it in, not up”)

Much of the focus of Change Management is on risk analysis and management to avoid adverse impact – “protecting the business”. Change Management typically views success as implementing the requested technical feature or service (application updates, new IT services) without problems.

ITIL defines Change management:

The goal of the change management process is to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes, in order to minimize the impact of change-related incidents upon service quality, and consequently improve the day-to-day operations of the organization.

Let’s take an example we’re all familiar with. I’d hazard a guess that most IT organizations have upgraded their mail servers recently. In the process, most of us defined the desired result of the change to be successfully upgrading to Exchange xx with minimal user impact. It was most likely justified by increased security, supportability, and new features.

How many upgrade efforts were driven and measured by the enhanced capability and improved productivity of business users? Would we even know how to measure that, and if we did, would we see that as our responsibility, as a Critical Success Factor for Change Management. Or are we more likely to view that as “their concern”. Ours being the successful implementation of the technical requirements, leaving the business with some-assembly-required to produce value.

In the case of the Titanic, there was an immediate need to change course. Using established systems and processes, they quickly implemented the needed change. It was implemented with precision, and the change was, by traditional measure, successful.

But the outcome was far from successful, by any reasonable measure. And yet, IT organizations the world over defend their contribution by declaring they have successfully implemented the technical part of the change, as requested, with no negative impact. Success.

Change Enablement

But we all know the end of the Titanic story. Disaster. Failure. Even though the ship’s Change Management processes quickly and effectively implemented the desired change, the result was catastrophic. It didn’t achieve the desired outcome.

Change Enablement, by contrast, seeks to ensure the business actually realizes the desired outcomes – the results the business envisioned when changes are requested of IT. It evaluates and identifies additional success parameters, and establishes transition plans to ensure the desired outcomes are achieved.

Change Enablement includes organizational Management of Change required to achieve the desired business result.

Senior leadership (including IT) is charged with ensuring the resources under their care are aligned with the business objectives of the organization. If they are not, leadership is not fulfilling it’s obligation to the stakeholders, for which they will be held accountable. (Governance)

Implementation of needed changes is but a minor component. Change Enablement focuses on the entire organization’s capability to achieve outcomes. It includes people (the right skills, knowledge and experience), processes (working together as a system to maximize effectiveness, and directly aligned with the business), technology, relationships and organizational structures required for success. Everything from viability of the business’s long range planning strategy, the formation of effective tactical plans to achieve, and the organizational capability to deliver.

Change Enablement needs traditional Change Management, but is laser focused on the larger whole. And in the end, it’s the business results that count. Like the Titanic, the IT crew is on the same ship, and if the ship sinks, it’s bad for us all. It’s not like we’re safely on another (IT) ship. We are, quite literally, all in the same boat together.

For Titanic, Change Enablement would include investments in better early warning systems – night vision, radar, GPS, etc. Improvements in real time analysis and controls for determining appropriate speed for given conditions. Analyzing the ship’s design and engineer improvements to the ship’s ability to more quickly change course.

The road ahead for IT organizations is an even greater role in enabling the business to meet the ever increasing demands on their organization. ‘Change Enablement’ is no longer the high minded double speak of elite management consultants. IT can no longer faithfully implement changes in isolation and declare success.

If you think about it, Change management, as described, is essentially playing to not-fail. Whereas Change Enablement is playing to win. Business requires an IT who can help them win the larger battle – Change Enablers who help deliver meaningful business results.

What a great time for IT Service Management!

Image credit

Service Improvement at Cherry Valley

Problem, risk, change , CSI, service portfolio, projects: they all make changes to services.  How they inter-relate is not well defined or understood.  We will try to make the model clearer and simpler.

Problem and Risk and Improvement

The crew was not warned of the severe weather ahead

In this series of articles, we have been talking about an ethanol train derailment in the USA as a case study for our discussions of service management.  The US National Transport Safety Board wrote a huge report about the disaster, trying to identify every single factor that contributed and to recommend improvements.  The NTSB were not doing Problem Management at Cherry Valley.  The crews cleaning up the mess and rebuilding the track were doing problem management.  The local authorities repairing the water reservoir that burst were doing problem management.  The NTSB was doing risk management and driving service improvement.

Arguably, fixing procedures which were broken was also problem management.   The local dispatcher failed to tell the train crew of a severe weather warning as he was supposed to do, which would have required the crew to slow down and watch out.  So training and prompts could be considered problem management.

But somewhere there is a line where problem management ends and improvement begins, in particular what ITIL calls continual service improvement or CSI.

In the Cherry Valley incident, the police and railroad could have communicated better with each other.  Was the procedure broken?  No, it was just not as effective as it could be.  The type of tank cars approved for ethanol transportation were not required to have double bulkheads on the ends to reduce the chance of them getting punctured.  Fixing that is not problem management, it is improving the safety of the tank cars.  I don’t think improving that communications procedure or the tank car design is problem management, otherwise if you follow that thinking to its logical conclusion then every improvement is problem management.

A distinction between risks and problems

But wait: unreliable communications procedure and the single-skinned tank cars are also risks.  A number of thinkers, including Jan van Bon, argue that risk and problem management are the same thing.  I think there is a useful distinction: a problem is something that is known to be broken, that will definitely cause service interruptions if not fixed; a “clear and present danger”.  Risk management is something much broader, of which problems are a subset.  The existence of a distinct problem management practice gives that practice the focus it needs to address the immediate and certain risks.

(Risk is an essential practice that ITIL – strangely – does not even recognise as a distinct practice; the 2011 edition of ITIL’s Continual Service Improvement book attempts to plug this hole.  COBIT does include risk management, big time.  USMBOK does too, though in its own distinctive  way it lumps risk management under Customer services; I disagree: there are risks to our business too that don’t affect the customer.)

So risk management and problem management aren’t the same thing.  Risk management and improvement aren’t the same thing either.  CSI is about improving the value (quality) as well as reducing the risks.

To summarise all that: problem management is part of risk management which is part of service improvement.

Service Portfolio and Change

Now for another piece of the puzzle.  Service Portfolio practice is about deciding on new services, improvements to services, and retirement of services.  Portfolio decisions are – or should be – driven by business strategy: where we want to get to, how we want to approach getting there, what bounds we put on doing that.

Portfolio decisions should be made by balancing value and risk.  Value is benefits  minus  costs.  There is a negative benefit and a set of risks associated with the impact on existing services of building a new service:  there is the impact of the project dragging people and resources away from production, and the ongoing impact of increased complexity, the draining of shared resources etc….  So portfolio decisions need to be made holistically, in the context of both the planned and live services.  And in the context of retired services too: “tell me again why we are planning to build a new service that looks remarkably like the one we killed off last year?”.  A lot of improvement is about capturing the  learnings of the past.

Portfolio management is a powerful technique that is applied at mulltiple levels.  Project and Programme Portfolio Management is all the rage right now, but it only tells part of the story.  Managing projects in programmes and programmes in portfolios only manages the changes that we have committed to make; it doesn’t look at those changes in the context of existing live services as well.  When we allocate resources across projects in PPM we are not looking at the impact on business-as-usual (BAU); we are not doling out resources across projects and BAU froma  single pool.  That is what a service portfolio gives us:  the truly holistic picture of all the effort  in our organisation across change and BAU.

A balancing act

Service portfolio management is a superset of organisational change management.  Portfolio decisions are – or should be – decisions about what changes go ahead for new services and what changes are allowed to update existing services, often balancing them off against each other and against the demands of keeping the production services running.  “Sure the new service is strategic, but the risk of not patching this production server is more urgent and we can’t do both at once because they conflict, so this new service must wait until the next change window”.  “Yes, the upgrade to Windows 13 is overdue, but we don’t have enough people or money to do it right now because the new payments system must go live”.  “No, we simply cannot take on another programme of work right now: BAU will crumble if we try to build this new service before we finish some of these other major works”.

Or in railroad terms: “The upgrade to the aging track through Cherry Valley must wait another year because all available funds are ear-marked for a new container terminal on the West Coast to increase the China trade”.  “The NTSB will lynch us if we don’t do something about Cherry Valley quickly.  Halve the order for the new double-stack container cars”.

Change is service improvement

Everything we change is service improvement. Why else would we do it?  If we define improvement as increasing value or reducing risk, then everything we change should be to improve the services to our customers, either directly or indirectly.

Therefore our improvement programme should manage and prioritise all change.  Change management and service improvement planning are one and the same.

So organisational change management is CSI. They are looking at the beast from different angles, but it is the same animal.  In generally accepted thinking, organisational change practice tends to be concerned with the big chunky changes and CSI tends to be focused more on the incremental changes.  But try to find the demarcation between the two.   You can’t decide on major change without understanding the total workload of changes large and small.  You can’t plan a programme of improvement work for only minor improvements without considering what major projects are planned or happening.

In summary, change/CSI  is  one part of service portfolio management which also considers delivery of BAU live services.  A railroad will stop doing minor sleeper (tie) replacements and other track maintenance when they know they are going to completely re-lay or re-locate the track in the near future.  After decades of retreat, railroads in the USA are investing in infrastructure to meet a coming boom (China trade, ethanol madness, looming shortage of truckers); but they better beware not to draw too much money away from delivering on existing commitments, and not to disrupt traffic too much with major works.

Simplifying service change

ITIL as it is today seems to have a messy complicated story about change.  We have a whole bunch of different practices all changing our services, from  Service Portfolio to Change Management to Problem Management to CSI.  How they relate to each other is not entirely clear, and how they interact with risk management or project management is undefined.

There are common misconceptions about these practices.  CSI is often thought of as “twiddling the knobs”, fine-tuning services after they go live.  Portfolio management is often thought of as being limited to deciding what new services we need.  Risk management is seen as just auditing and keeping a list.  Change Management can mean anything from production change control to organisational transformation depending on who you talk to.

It is confusing to many.  If you agree with the arguments in this article then we can start to simplify and clarify the model:

Rob England: ITSM Model
I have added in Availability, Capacity, Continuity, Incident and Service Level Management practices as sources of requirements for improvement.  These are the feedback mechanisms from operations.  In addition the strategy, portfolio and request practices are sources of new improvements.   I’ve also placed the operational change and release practices in context as well.

These are merely  the thoughts of this author.  I can’t map them directly to any model I recall, but I am old and forgetful.  If readers can make the connection, please comment below.

Next time we will look at the author’s approach to CSI, known as Tipu.

Image credit: © tycoon101 – Fotolia.com

Planning for Major Incidents

Do regular processes go out of the window during a Major Incident?

Recently I’ve been working on Incident Management, and specifically on Major Incident planning.

During my time in IT Operations I saw teams handle Major Incidents in a number of different ways. I actually found that in some cases all process and procedure went out of the window during a Major Incident, which has a horrible irony about it. Logically it would seem that this is the time that applying more process to the situation would help, especially in the area of communications.

For example in an organisation I worked in previously we had a run of Storage Area Network outages. The first couple caused absolute mayhem and I could see people pushing back against the idea of breaking out the process-book because all that mattered was finding the technical fix and getting the storage back up and running.

At the end of the Incident, once we’d restored the service we found that we, maybe unsurprisingly had a lot of unhappy customers! Our retrospective on that Incident showed us that taking just a short time at the beginning of the outage to sort out our communications plan would have helped the users a lot.

ITIL talks about Major Incident planning in a brief but fairly helpful way:

A separate procedure, with shorter timescales and greater urgency, must be used for ‘major’ incidents. A definition of what constitutes a major incident must be agreed and ideally mapped on to the overall incident prioritization system – such that they will be dealt with through the major incident process.

So, the first thing to note is that we don’t need a separate ITIL process for handling Major Incidents. The aim of the Incident Management process is to restore service to the users of a service, and that outcome suits us fine for Major Incidents too.

The Incident model, its categories and states ( New > Work In Progress > Resolved > Closed ) all work fine, and we shouldn’t be looking to stray too far from what we already have in terms of tools and process.

What is different about a Major Incident is that both the urgency and impact of the Incident are higher than a normal day-to-day Incident. Typically you might also say that a Major Incident affects multiple customers.

Working with a Major Incident

When working on a Major Incident we will probably have to think about communications a lot more, as our customers will want to know what is going on and rough timings for restoration of service.

Where a normal Incident will be handled by a single person (The Incident Owner) we might find that multiple people are involved in a Major Incident – one to handle the overall co-ordination for restoring service, one to handle communications and updates and so on.

Having a named person as a point of contact for users is a helpful trick. In my experience the one thing that users hate more than losing their service is not knowing when it will be restored, or receiving confusing or conflicting information. With one person responsible for both the technical fix and user communications this is bound to happen – split those tasks.

If your ITSM suite has functionality for a news ticker, or a SocialIT feed it might be a good idea to have a central place to update customers about the Major Incident you are working on. If you run a service for the paying public you might want to jump onto Twitter to stop the Twitchfork mob discussing your latest outage without you being part of the conversation!

What is a Major Incident

It is up to each organisation to clearly define what consitutes a Major Incident. Doing so is important, otherwise the team won’t know under what circumstances to start the process. Or you might find that without clear guidance a team will treat a server outage one week as Major (with excellent communciations) and not the next week with poor communications.

Having this defined is an important step, but will vary between organisations.

Roughly speaking a generic definition of a Major Incident could be

  • An Incident affecting more than one user
  • An Incident affecting more than one business unit
  • An Incident on a device on a certain type – Core switch, access router, Storage Area Network
  • Complete loss of a service, rather than degregation

Is a P1 Incident a Major Incident?

No, although I would say that every Major Incident would be a P1. An urgent Incident affecting a single user might not be a Major Incident, especially if the Incident has a documented workaround or can be fixed straightaway.

Confusing P1 Incidents with Major Incidents would be a mistake. Priority is a calculation of Impact and Urgency, and the Major Incident plan needs to be reserved for the absolute maximum examples of both, and probably where the impact is over multiple users.

Do I need a single Incident or multiple Incidents for logging a Major Incident?

This question might depend on your ITSM toolset, but my preference is to open a separate Incident for each user affected in the Incident when they contact the Servicedesk.

The reason for this is that different users will be impacted in different ways. A user heading off to a sales pitch will have different concerns to a user just about to go on holiday for 2 weeks. We might want to apply different treatment to these users (get the sales pitch user some sort of service straight away) and this becomes confusing when you work in a single Incident record.

If you have a system of Hierarchical escalation you might find that one customer would escalate the Major Incident (to their sales rep for example) where another customer isn’t too bothered because they use the affected service less frequently.

Having an Incident opened for each user/customer allows you to judge exactly the severity of the Incident. The challenge then becomes to manage those Incidents easily, and be able to communicate consistently with your customers.

Is a Major Incident a Problem?

No, although if we didn’t have a Problem record open for this Major Incident I think we should probably do so.

Remember the intended outcome of the Incident and Problem Management processes:

  • Incident Management: The outcome is a restoration of service for the users
  • Problem Management: The outcome is the identification and possibly removal of the causes of Incidents

The procedure is started when an Incident matches our definition of a Major Incident. It’s outcome is to restore service and to handle the communication with multiple affected users. That restoration of service could come from a number of different sources – The removal of the root cause, a documented Workaround or possibly we’ll have to find a Workaround.

Whereas the Major Incident plan and Problem Management process will probably work closely together it is not true to say that a Major Incident IS a Problem.

How can I measure my Major Incident Procedure?

Simon Morris

I have some metrics for measuring the Major Incident procedure and I’d love to know your thoughts in the comments for this article.

  • Number of Incidents linked to a Major Incident: Where we are creating Incidents for each customer affected by a Major Incidents we should be able to measure the relative impact of each occurance.
  • The number of Major Incidents: We’d like to know how often we invoke the Major Incident plan
  • Mean Time Between Major Incidents: How much time elapses between Major Incidents being logged. This would be interesting in an organisation with service delivery issues, and they would hope to see Major Incidents happen less frequently

There you go. In summary handling Major Incidents isn’t a huge leap from the method that you use to handle day-to-day Incidents. It requires enhanced communciation and possibly measurement.

I hope that you found this article helpful.

Photo Credit

itSMF – The Glue That Unites the Service Management Industry

Not-A-Pink-Shirt
Ben Clacy, UK CEO, itSMF

As I begin my journey into the world of ITSM what better place to start than with The IT Service Management Forum (itSMF)?

I recently met with Ben Clacy, CEO of itSMF UK to discuss the recent changes to ITIL and the announcement of a new professional credentialing scheme for service management professionals.

ITSM Review Q. For those not familiar with itSMF –what do you do?

We are community of over 12,000 UK based service management professionals. We were born out of ITIL and are essentially an ITIL user group. There are 53 chapters of itSMF around the globe, all of which are not for profit groups run by volunteers. It’s all about giving back to our members and helping them deliver better IT services.

Q. If I’m a new recruit in a support department or have just started a service management related role – how can the itSMF help me?

As a member of itSMF there is a variety of resources you can gain access to. We have a knowledgebase so that members can learn about all aspects of service management, a quarterly journal where members can learn about all the latest hot topics and events – from our annual conference through to smaller regionals events.

The ‘forum’ part is the most important aspect of the itSMF. It’s all about learning from your peers. Professionals who specialize in particular areas lead our events, allowing others to benefit from their real life experiences.

Ask itSMF members what the biggest benefit of membership is – and they’ll tell you it’s the ability to reach out to other members and understand how they can do something better.

Q. What is prISM?

The industry already has a good qualification scheme based on ITIL, but a lot of people question it because it is only a qualification. You can read the books and take the exam but it does not take into account your experience and your others skills as a service management professional.

prISM is a credentialing scheme for the service management industry.

Credential – “a qualification, achievement, quality, or aspect of a person’s background, especially when used to indicate their suitability for something” Source

The idea behind prISM is to provide, as many industries do, a recognized level of accomplishment that takes a broader view of the individual and their qualifications.

Q. So miles on the clock and hours at the rock face are taken into account?

Yes, to a certain extent, experience is certainly part of it. prISM looks at the job they do, what that involves, the knowledge they have and other training courses that might be relevant to service management. The goal is to provide a bigger picture of that individual’s professional experience.

Q. Could you provide a high level overview of the prISM credentialing levels?

The levels are:

  1. Student in Service Management (SSM) – for students with an interest in ITSM
  2. Associate (ASM) – for entry-level professionals
  3. Professional (PSM) – for mid-level, experienced professionals
  4. Distinguished Professional (DPSM) – for senior, experienced professionals and leaders.
  5. Fellow (FSM) – recognized for making significant contributions to the profession and its body of knowledge.

Q. Could you share your opinion on ITIL 2011? I’m a from an enterprise software background so from what I understand it is a minor release in order to resolve a few bugs and not a major version – is that a suitable analogy?

ITIL are trying to move away from version numbers. The UK government owns ITIL and things take a little longer than many people would like.

Some would prefer it to be a more of an iterative update. It has been out since the late eighties and version three was released in 2007. It has only had two significant updates.

ITIL 2011 is an update not a new version. The structure has remained the same. The first book on service strategy has had a significant overhaul but the other four books have only had minor adjustments. Service strategy was a new concept for a lot of people back in 2007 and this update makes it more accessible.

Q. So going back to my new recruit who has just landed on the helpdesk and has never heard of ITIL – what would you recommend? What is the best path for learning about all of this?

The best way to begin the journey with regards to ITIL is to attend a one-day training session that some training companies offer which is effectively a game or a simulation.

This experiential form of training puts you in a real life scenario (the Apollo 13 mission, a shop, a trading floor etc.) with the group running an IT department.

It soon becomes apparent the mistakes being made, the damage being done to the business and the money being lost. Gradually the ITIL processes are put in place so that the people taking the course can witness real life improvements being made. There is commonly a light bulb moment when people realize what effect these changes can have on their own business.

 Q. How is the itSMF linked to ITIL?

ITIL is owned by OGC and we have no real formal link to the 2011 update – but 90% of our members use ITIL as a framework for their business and all of the authors of ITIL are itSMF members. ITIL is the theory and the itSMF provides the real life context, allowing members to learn from others who have implemented service management in line with ITIL principles.

Further Information