The (Ongoing) Evolution of the ITIL Request

April 27, 2009
By Rob England

From no standing at all to an equal peer of Incident, the humble Request has grown in importance with each new version of ITIL, writes ITSMWatch columnist Rob England (a.k.a., The IT Skeptic).

Two years ago, we looked at the evolution of the ITIL Request here on ITSMWatch. Since then, discussions on my blog have reshaped some of the ideas. Let's revisit them:

In ITIL v1, there was no recognised “process” for Incident Management, just a function called Help Desk, which was responsible for “first level incident support, advice and acts as a day-to-day contact point for users of IT services”. So, only Incidents were recognised as a processed object

In ITIL v2, Incident Management became a recognised process. (Whether or not this is a correct use of the word process is a discussion for another day). Mentioned in passing was the possibility of a call being a Service Request rather than an Incident, at which point the process branched to ... well, nothing. The Service Request branch hung into space, dangling wires and reinforcing steel into the void. Service Request process was never defined.

What came first was never defined either. When someone calls, is the call an Incident until proven to be a Service Request? Or is it a Request until it reveals itself to be an Incident? Or is it something else (a call, a contact) until it yields to classification? This was left to the implementers (or software vendors) to decide.

v3

Now ITIL v3 elevates the Service Request to equal billing with the Incident. In fact, if importance can be measured by number of pages then Service Requests get slightly more of the “Peas Book” (Service Transition) than Incidents do.

This is a great step forward but I believe it is not the final word. v3 still delineates between Incident and not-Incident as the two categories. That is, Service Requests are some kind of miscellaneous category for everything that is not actually an unexpected interruption to service. The two processes are quite separate. This does not fit well with my experience of reality. Admittedly, my reality has a few kinks, but in this case I speak on behalf of clients who feel the same way. For many service desks, Incidents are not the main part of their function.

I predict that ITIL v4 (if there is one) will finally recognise that the service desk deals with generic Requests/Tickets/Issues. These Requests have multiple categories or classes. Each class is a variant of a more general process that applies to all of them, in much the same way as there are several categories of Change, which all undergo variants of the general Change process.

I published a list in the article two years ago. Since then, I realised that the list had missed one―Fault. So, I thought I'd update the list for you. This revised list is constructed based on the concept that each class of request exists because it is a variant of the core Request Fulfilment Process, e.g., Complaints will be dealt with differently to Proposals. Different people and groups, different procedure, different reporting, different service levels. That is, I derived the different classes or categories based on the process being different. If two types of request use the same process then I decided they are synonyms.

New Taxonomy

After discussions on the blog, I also decided they needed to be re-grouped into a newly named hierarchy. I came up with three groups:

Action: I'd like to say “Service” but man is that an exhausted word!

Support: not everything will be/needs to be fixed so not Repair

Input: the user is contributing

Here is my taxonomy of these new Request classes:

Action -

Provisioning

Booking

Ordering

Change

Work

upport -

Incident

Fault

Help

Advice

Input -

Proposal

Suggestion

Feedback

Complaint

Let’s elaborate a little on what some of these mean:

Provisioning: User requires access to a service or part of a service, e.g., a security permission, a menu option, a token, a digital certificate, a client install, a desktop device, a phone, etc.

Booking: Scheduled attendance at training, seminar, meeting, reservation of a resource, annual leave.

Ordering: Books, desks, catering, stationery, travel.

Change: as defined by Change Management, typically means change to a configuration item (CI). Some organisations allow users to open RFCs directly, others have some form of prior request entity.

Work: tasks that falls outside change management. Run a report. Move a PC. Install a projector.

Incident: an unplanned interruption to an IT service or reduction in the quality of an IT service.

Fault: failure or detected imminent failure of a CI; no service impact (yet). Only users within IT would be expected to report these, or an automated tool. If confirmed, it will spawn a Problem. This class was much debated on the blog. An Incident is by definition something that has already impacted the Service, a Fault hasn’t. Both have varying priorities and urgencies and impacts. But the processes differ. If you are uncomfortable with this, ignore me and treat Incident and Fault as synonyms. Twelve is a nicer number of classes than 13 anyway.

Help: correcting data arising from user error (NOT from a Problem). Restoring a deleted file, untangling a mess.

Advice: how do I … ? Should I … ? Which is the best way to … ?

Proposal: the service desk can be a front-end to the demand component of project portfolio management. Think of it as a Request For Project.

Suggestion: idea, requirement, request. Something less formal or evolved than a proposal but might lead to one.

Feedback: praise, reported experience, remarks.

Complaint: poor experience. (Of course, Complaint had to be #13.)

Based on the principle of distinguishing classes by differing processes, the first three classes (Provisioning, Booking, Ordering) could well break into a number of subclasses. There are other types of contacts to the Service Desk that aren't requests at all. The classic is a follow-up on a request. Feedback that doesn't require action would also not be a request.

Once we come to see an Incident as just one class of a more general Request, then the service desk’s Request Management process will make more sense and map better to reality. SLAs will define responsiveness in terms of the classes of Request. (I think restoration of service should be defined as part of the Availability Service Level Objective, not the Responsiveness Service Level Objective). Management of Incidents (the restoration of service, incident matching) may still fall to a specialist Incident Manager, or it might be part of the role of the Request Manager.

Incidentally (no pun intended), I still encounter examples of SLA objectives for Restoration of Service. Outages will be prioritised based on their severity, but they will be restored as soon as they can be restored and no sooner. “Priority 1 incidents must be resolved within one hour” is like saying “Fires must be extinguished within three minutes” or “Missing climbers must be found within an hour”.

We’ll find them when we find them. It makes sense to define responsiveness by severity/priority/impact, but not restoration. That is, we define how much resource will be assigned to it, how the communications plan changes, how escalation and supervision will be heightened, and other aspects of how we respond. We can’t promise timeframes.

From a narrow focus on restoration of service, the understanding of the service desk has grown with each revision of ITIL, and with it the importance of the Request. Extrapolating the trend suggests that next time ITIL is revised the Request will truly have its day.

Along with the IT Skeptic, the IT Swami is an alter-ego of the author, who resides on the IT Skeptioc Blog and offers prognostications about IT’s future to the few who listen.

Doing More with Less: IT Framework Integration

April 17, 2009
By George Spafford

Understanding how the many IT frameworks work together is the first step towards using them appropriately, writes ITSMWatch columnist George Spafford of Pepperweed Consulting.

With the economic downturn organizations are pushing to drive down costs while improving quality. To shorten the learning curve and improve the likelihood of success, proven business and IT frameworks relating to quality and other disciplines are being reviewed for insights on how to improve effectiveness and efficiency. IT groups not familiar with the various frameworks and how they may integrate are apt to make wrong decisions or allow business management to make wrong decisions.

Given the plethora of frameworks that IT may be involved with, it only makes sense to review some of the most common ones at a very high-level and then discuss how they can work together. The following are common frameworks that IT may well encounter:

Control Objectives for Information and related Technologies (COBIT) – This identifies controls that are used in process design to mitigate risks. Once an organization understands risks and wants to identify how to mitigate those risks, then COBIT can help.

Information Technology Infrastructure Library (ITIL) – This collection of five books codifies IT Service Management (ITSM) and the associated lifecycle of IT services with supporting best practice processes. The ITIL guidance begins with Service Strategy, then Service Design, Service Transition, Service Operation and Continuous Service Improvement.

ISO/IEC 20000:2005 – This is the international standard for ITSM. It is split into two parts: 20000-1 identifies the standard itself and what an organization must do to be accredited; 20000-2 is the code of practice that identifies opportunities for improvement. At this time, it is based on ITIL v2 and whereas ITIL does not have a certification associated with it, ISO 20000 does.

ISO/IEC 27000:2005– This is the international standard for information security and at this time has two parts also and there are plans to add more in the future. 27001 outlines the requirements for the standard. The 27002 Code of Practice document gets into more details around the controls.

ISO 9000 – This generic name relates to a collection of standards that help define a quality management system. While it originated in manufacturing it can be found in many different types of organizations.

Lean Six Sigma (LSS) – This is a combined quality management approach that blends Lean’s desire to move faster and create value with Six Sigma’s approach to reduce defects and re-work. As a result, LSS addresses defects and time wasted as it seeks to increase overall speed while reducing cost.

Leveraging the Frameworks

In reviewing the above, we can make some broad groupings. ISO 9000 and LSS can be found in organizations around the world and are not IT centric. The others are specific to IT so let’s begin there:

COBIT is used to mitigate controls and recommends what to do but doesn’t give details around how to design the control. In fact, controls need solid processes to be effective and then that raises the other frameworks. ITIL provides very good guidance on IT Service Management processes. For perspectives on how to design processes that embody controls relating the change management, release, incident management and other areas relating to service, ITIL is very good.

Now, ISO 20000 and ITIL do overlap. Right now, they are also a bit disparate because of ISO 20000’s grounding in ITIL v2. Groups pursuing ISO 20000 may benefit from the additional guidance that can be found in ITIL v3 but still must make sure they follow the requirements set forth in the standard in order to be certified. For groups looking to show their clients they are focused on providing quality services, an ISO 20000 certification is one way to do that.

To be clear, ITIL is very much focused on improving the quality of services that IT provides. It’s drawback is that it does not carry a certification. For example, when a tool claims to be “ITIL Compliant”, that is just a marketing term because no such certification exists. Likewise, a practitioner company can be assessed and receive objective recommendations on how to improve but there isn’t a certification like there is for ISO 20000.

Returning to COBIT and process guidance, if controls around information security are needed, then ISO 27000 can be used for additional guidance. For organizations that want to market their attention to information certification, becoming certified in ISO 27000 and identifying such is one approach.

ISO 9000, Lean, Six Sigma or LSS are all quality management frameworks the overall organization may be pursuing. Many business managers and executives have formal training and experience with these approaches to quality. What they do not have exposure to is ITIL. If there is pressure to stop an ITIL implementation because LSS is being pursued, for example, then it needs to be explained that ITIL can provide reference practices for groups pursuing process improvement. If ITIL is not used, then process improvement will be limited. For instance, it may be identified that the handling of incidents needs to be streamlined. Without referring to ITIL, the stakeholders involved can only try to improve their approach based on what they know.

In closing, there are many frameworks in the world today; far more than the handful mentioned in this article. IT groups seeking to improve their processes would do well to understand what other groups are doing, both within the firm as well as in the industry, and the direction the overall organization is taking. IT can then plan how to best continuously improve the services that they provide to create and protect value for the organization.

George Spafford is a principal consultant with Pepperweed Consulting and a long-time IT professional. George's professional focus is on compliance, security, management and overall process improvement.

New ITIL Adoption Slowing

March 24, 2009
By ITSM Watch Staff

A new report shows that companies are less inclined to embark on ITIL; right when they could benefit from it most.

IT management has been in transition for some time, from a focus on managing the technology itself to using technology to help a business achieve its strategic objectives.

In theory, imposing disciplines on IT processes should improve productivity and make IT more responsive to the business. Many organizations are turning to the Information Technology Infrastructure Library, better known as ITIL, to accomplish this goal, said research firm Computer Economics in a February research note summarizing the report ITIL Implementation Trending Up, But Adoption May Slow.

Large IT organizations are continuing to expand ITIL initiatives at a healthy pace, but new adoption may be slowing. The obstacles to adoption are real, and benefits are sometimes difficult to quantify. Furthermore, the current economic crisis is not favorable to investment in long-term improvement programs such as ITIL. On the other hand, a downturn in business volume may be the best time to make changes to IT processes and services, as personnel may have more time for such initiatives.

The CE study does find some indication that organizations already engaged with ITIL have been accelerating their investments. CE sees this as a good sign, as they believe that, in the long run, organizations focused on continuous improvement will survive and ultimately prosper.

Why U.S. Navy is Standardizing IT Strategy Around ITIL

April 3, 2009
By Dave Perera

Facing multiple problems from multiple directions, the U.S. Navy turned to ITIL to help right the ship.

In 2006, EDS had a problem. A big problem. The company was facing rampant and voluble dissatisfaction of its $9.9 billion contract to manage the Navy and Marine Corps’s land-side IT infrastructure, better known as NMCI for Navy/Marine Corp. Intranet. The solve this migraine of a headache, EDS, now a division of HP, turned to ITIL. Initially applying it to high-visibility areas such as change and incident management, EDS expanded ITIL over the next 27 months across its areas of responsibility, which cover everything from seat management to network command and control.

“Proactive issue resolution, streamlining the process in those functional areas so that the system felt more responsive to end user – that was the target” during the ITIL roll out, said Steve Heidt, the company’s VP for Navy/Marine Corps Intranet Operations. Parts of the EDS’s support organization have adopted ITIL version 3 (v3) but when the contract runs out in September 2010, it’ll end with a mixture of the version 2 (v2) and v3 frameworks in place, Heidt added.

The Navy's unhappiness with the outsourcing effort – called NMCI for short – was obvious to anyone witnessing the mid-decade raft of “NMCI Sucks” bumper stickers or the forest of snide online comments. More recently, however, the percentage of satisfied users has reached the high 80s, according to surveys conducted by EDS. Some of the dissatisfaction may have been inevitable. EDS was tasked to hammer around 6,000 separate networks managed by 28 different commands into a single, coherent whole for about 700,000 users. Still, the degree of discontent went deep and high in the ranks.

“I believe that EDS was not prepared to handle the implementation,” said Lt. Gen. Edward Hanlon in 2004 when he was the commanding general of the Marine Corps Combat Development Command.

Post ITIL, relations between EDS and Navy have improved, Heidt said. “We interact much better with them in a more rigored structured process that helps them get visibility and control faster,” he explained.

Moving Forward

Now the Navy is looking past NMCI to its next IT contracting vehicle and vowing not to repeat old mistakes. The Navy calls its next procurement the Next-Generation Enterprise Network (NGEN) and is in the process of finalizing its acquisition strategy. Regardless of what final approach emerges after the Pentagon okay's the analysis of alternatives, the Navy is making it clear that ITIL will be its management framework of choice. In NMCI, the Navy essentially handed over to its entire infrastructure to EDS; even abdicating command and control of land-side networks to the company.

No one in the military, or even in EDS itself, reasonably expects that to happen again with NGEN , although a NMCI-like model officially remains a possibility, said Navy Capt. Tim Holland, NGEN’s program manager.

Regardless, the NGEN concept of operations document specifically calls for ITIL. That’s because the Navy wants a common language to speak with industry when it comes to integrating their support with Navy command and control, Holland said.

“Industry is familiar with it. We can have more than one industry partner and we’ll all be talking the same language,” he added. The Navy will use ITIL across the totality of NGEN. “It’s a lot more than help desks. Help desk is just one service within ITIL." The analysis of alternatives should be complete within the next few months, Holland added. Ashore IT infrastructure isn’t the only area where the service has found ITIL beneficial. Components of the Naval Network Warfare Command (NETWARCOM) started using it about two years ago in its ship-to-shore communications, said Navy Lt. Cmdr. Dave Purkiss, an ITIL advocate who works for NETWARCOM's readiness directorate. ITIL has allowed the Navy to standardize what once were different IT management procedures across NETWARCOM’s major shore communication stations covering the Pacific and Atlantic oceans, the Mediterranean and the Persian Gulf, he said.

Before, a ship or crew crossing from one region to the next would be met with different sets of prioritization schemes for incident management, Purkiss said. Very often, a single person would manage incidents from start to finish and “that lack of specialization created a lot of inefficiencies,” he added. The tracking methodology for outages was just paper messages on desks. Demand for a standardized framework to better manage incidents came from the ground up, Purkiss said.

At the same time, it proved difficult at times to get Navy personnel to embrace ITIL, which carried a reputation as a corporate strategy and which seeks to make decisions cost efficient. Military personnel think in terms of combat readiness and “it’s hard to put a cost value on a pound of command, control, communications, computers and intelligence,” Purkiss said. "The balance sheet is what’s difficult. The cost sheet is easy, but the return on that investment is the hard part. That’s what we’re struggling with, Navy-wide,” he added.

There’s only so much individual components can do to resolve that problem, Purkiss said. At some point the major commands or the CIO will need to create a strategy for service prioritization and make the hard decisions of how to match costs to combat readiness. “It has to be both a top down and a bottom up approach – one without the other is not a recipe for success."