Implementing ITIL

27
Implementing Service Level Management with ITIL an IT Management eBook

Transcript of Implementing ITIL

Page 1: Implementing ITIL

ImplementingService LevelManagement with ITIL

an IT Management eBook

Page 2: Implementing ITIL

1

contentsThis content was adapted from Internet.com'sITSMWatch.com Web site. Contributors:Drew Robb, George Spafford, Mike Tainter,Atwell Williams, Hank Marquis, Karsten Smet,Andrew Sarnoff, Thomas Wimmer andDarreck Lisle.

© 2009, Jupitermedia Corp.

2 Getting Started with ITILBy Mike Tainter

5 ITIL: The Prelude to FlexiblePerformanceBy Andrew Sarnoff &Thomas Wimmer

8 Ensuring a Successful ITILImplementationBy Drew Robb

13 The Key to Quality ServiceLevel ManagementBy Karsten Smet

15 The Right Way to Set SLAsGeorge Spafford

17 Service Level Managementis the HingeBy Darreck Lisle

20 Incidents, Problems, KnownErrors and ChangesBy George Spafford

22 Six Steps to ServiceOutage AnalysisBy Hank Marquis

24 Automation IT CapacityManagementBy Drew Robb

Implementing Service Level Management with ITIL[ ]

5

2

8

13 15

17 20

22 24

Page 3: Implementing ITIL

Anincreasing number of IT organizations are begin-ning to adopt ITIL-based IT service management ini-tiatives, and turnout at national, regional, and local

events on the subject keeps growing. Yet, one of themainquestions on people's minds is, "Where do we start?"

In order to get going, the businessand the IT organization must bealigned in pursuit of commongoals. An Information TechnologyInfrastructure Library (ITIL) initiativeis a long-term methodology forproviding quality services thatenable the business to gain acompetitive advantage. Executiveleadership within IT must embracethe benefits and sell the idea tothe business.

Educating theOrganizationThe first step is to ensure that sen-ior IT leaders develop a solid understanding of theactivities that comprise ITIL and of what ITIL adoptionaccomplishes. Candidates for training should be select-ed carefully; each person who attends training should

be a respected leader with the ability to make thingshappen.

When people use multiple methods to understand anew concept, they tend to retain the content longer,

with a more detailed under-standing. Too often, organiza-tions decide to attend training inplace of reading the books. Itusually works best to start byreading the books that make upITIL.

Attending training after readingthe books allows people to askchallenging questions of theinstructors so they can apply ITILin their specific organization.Better understanding also tendsto create greater enthusiasm forand dedication to overcomingthe challenges ITIL adoptionpresents.

Next, this core group can begin imparting their ITILknowledge to others in the organization so they all startto "speak the same language." Workshops and educa-

2 Implementing Service Level Management with ITIL, An Internet.com IT Management eBook. © 2009, Jupitermedia Corp.

Implementing Service Level Management with ITIL[ ]

Getting Started with ITILBy Mike Tainter

The first step is to ensure that senior IT leaders develop a solidunderstanding of the activities that comprise ITIL and of what ITIL

adoption accomplishes.

Page 4: Implementing ITIL

tion sessions are effective ways to promote excitement(and thus reduce resistance to the changes ITIL adop-tion requires).

You know you are successful when you start to hearhallway chatter about the benefits of ITIL.

Establishing a Steering CommitteeA steering committee is necessary to lead the organiza-tion through the ITIL adoption. At the core of ITIL areService Support and Delivery processes that will funda-mentally change the way IT delivers its services to theircustomers.

Assign leaders to take on the role of process ownersand challenge each with gaining adetailed understanding of his or herprocess and its integration with all theother processes. As with any initiativeof this scale, sound leadership andguidance is critical to its success.Experience demonstrates that suchleadership must be "top-down" ver-sus "bottom-up."

Assessing ProcessMaturityThe next step is to assess your orga-nization's maturity using the ITIL best practices as yourguide. The Service Support and Service Delivery bookscontain a list of the activities for each process. Processowners should create a list of these activities to use asa guide to determine how the IT organization is execut-ing against them.

Maturity level is measured through the use of a maturi-ty model; such as 0 = No process in place, 1 = Initial oridentified process, 2 = Repeatable, but not document-ed, 3 = Defined and documented, 4 = Measurable,and 5 = Optimized, you can identify and document anygaps that exist in an assessment report.

This report will be your guide in determining your tar-get maturity and the steps you need to take to getthere. When you conduct the assessment you will findthat you may have more maturity in some activities foreach process than in others. For example, most organi-zations perform well in areas such as Incident or

Change Management even before they begin an ITILinitiative.

The results of the assessment must be shared with themembers of the steering committee and executiveleadership to gain consensus on the current state of theorganization's processes. Once consensus is reachedand a commitment is made to address the gaps in thereport, you can start to build your action plan.

If you obtained services from a vendor for your assess-ment, ensure this same vendor helps you with yourroadmap. The roadmap should contain a list of projectsthat you can undertake to increase your process maturi-ty.

The first project in your roadmapshould be a strategy and planningeffort to create the project plan thatprovides for the following:

• Creation of a baseline service cata-log that defines the services your ITdepartment delivers

• Process workshops to gain a moredetailed understanding of the activi-ties for each process

• Assignment of roles and responsibil-ities for the people that will execute the processes,including a trainingand communication plan

• Tools and technology that can be used to automatethe processes

• Measurement and reporting to evaluate compliance

Too often, organizations begin ITIL adoption by focus-ing on activities for service delivery such as capacity oravailability management, because that's where they areexperiencing pain. However, the power of ITIL is in itsintegration.

Organizations adopting ITIL have discovered that matu-rity of their service support processes creates thegroundwork for optimizing their configurations to pro-vide better service. For example, if you consistentlydetect, log, classify, assign, resolve, and close incidents,

3 Implementing Service Level Management with ITIL, An Internet.com IT Management eBook. © 2009, Jupitermedia Corp.

Implementing Service Level Management with ITIL[ ]

A steeringcommittee is nec-essary to lead the

organizationthrough the ITIL

adoption.

Page 5: Implementing ITIL

it can lead to more effective problem management,which helps you identify and control known errors.

Problem Management can then be your entry point tocreating your availability and capacity plan to enactchanges in your environment to address those knownerrors.

Starting the JourneyYour ITIL journey should start with education and lead-ership, assessment, and an actionable roadmap for suc-cess. Hearing how other organizations have tackledtheir ITIL journey can be invaluable to your success

because you can learn from their experience. You cando this by joining a local user group, such as the ITService Management Forum USA (itSMF USA) localinterest group in your area.

But keep in mind, ITIL is not a project, it is a method tochange the way your organization delivers its servicesto the business. A project has a beginning and an end,whereas ITIL does not have an end, it is a continualjourney toward process maturity that enables IT todeliver quality services to the business so that it cancontinue to thrive and be profitable. �

4 Implementing Service Level Management with ITIL, An Internet.com IT Management eBook. © 2009, Jupitermedia Corp.

Implementing Service Level Management with ITIL[ ]

Page 6: Implementing ITIL

Whenyou listen to jazz improvisation, youmightthink themusic is completely freeform andunstructured. While musical improvisation certainly

creates an enjoyably unique experience, in actuality there is afinely tunedmethod to themadness.

A central theme runs through each improvised set, andeach musician in the groupunderstands the theme andknows how to build upon it.When it's their turn to impro-vise, each musician's sponta-neous creation conforms tothe musical structure (e.g., thekey, time signature, etc.) ofthe set and respects the othermusicians' performance. Theresult is freedom of expres-sion (flexibility) for the per-formers and enjoyment forthe audience. Everybody ishappy.

Now compare process management in your organiza-tion to musical improvisation. You want an enjoyableexperience for both your performers (IT) and audience(the business users), but you realize that each hasunique needs for interpretation, expression, and agood experience.

This is where the IT Infrastructure Library (ITIL) best-practice processes can be music to your ears. ITILprocesses can help align your infrastructure's technolo-gy with business objectives, and define the theme towhich your enterprise plays.

ITIL processes help the business achieve quality IT serv-ices while helping to reducecosts in technology opera-tions, using best-practiceprocedures for change man-agement, incident manage-ment, problem management,and capacity management,among others.

Because ITIL processes areguidelines, not standards,they can be creatively andflexibly applied, helping yourespond to problem areaseffectively and on many lev-els. This is particularly impor-

tant during times of crisis when, in the absence of stan-dardized processes for your infrastructure, you wouldneed to determine how to resolve a situation each timeit occurred.

ITIL processes can define how to quickly respond to sit-

5 Implementing Service Level Management with ITIL, An Internet.com IT Management eBook. © 2009, Jupitermedia Corp.

Implementing Service Level Management with ITIL[ ]

ITIL: The Prelude to Flexible Performance

By Andrew Sarnoff & Thomas Wimmer

Because ITIL processes are guidelines, not standards, they can becreatively and flexibly applied, helping you respond to problem

areas effectively and on many levels.

Page 7: Implementing ITIL

uations related to service support and service delivery,and help IT organizations to understand how othergroups work, so everyone supports the same musicaltheme. That's structure.

And a flexible IT organization is one that can quicklyadapt and respond to continually changing needs ofthe business. That's improvisation. An organization thatadopts ITIL as a framework provides a structure forpeople to more flexibly and "improvisationally" supportthe enterprise.

Flexible Change ManagementIf you're a CIO, your responsibility is to deliver consis-tently appropriate levels of service at optimal cost. Tomaintain those service levels, changes (e.g., patches,enhancements, etc.) must inevitably be introduced. Ifyou introduce change without a process in place, it canjeopardize your service levels.

On the other hand, if you have an overly rigid, struc-tured process through which everything must flow, itmight be more than some situations require.

You need to be able to flexibly respond to situationsrequiring change through a universally applicableprocess. ITIL change management explains how to han-dle all changes in your environment—from minor tosignificant, as well as emergency changes. ITIL changemanagement procedures provide a framework toimplement any change that comes your way and togive you flexibility in how you respond to any given sit-uation.

Consider, for example, that Microsoft releases a patchthat identifies a new vulnerability. The patch mustquickly be deployed, but an impromptu approachcould jeopardize service levels. Without a predefinedchange deployment process in place, a group will likelyneed to be assembled to decide how the patch will bedeployed.

Meanwhile, the vulnerability remains and the enterpriseis subject to attack. The drain on resources as thegroup determines how to proceed can further jeopard-ize your service levels. And, if you plow ahead andissue the patch across the enterprise without appropri-ate testing, you could create more problems than youprevent.

A change management process based on ITIL guide-lines helps alleviate this situation by providing a frame-work for dealing with ad-hoc, emergency changes.With a structured ITIL approach in place, one that playsto the theme of your enterprise, you could respond tothis and other change scenarios quickly and effectively.

You're much more likely to achieve consistent levels ofservice (and at appropriate cost) if you have the properstructure in place for change management. While somemight argue that there is more flexibility without struc-ture, think back to the jazz group. If you’re not playingin the same key, it's just noise.

Flexible Incident ManagementFlexibility when resolving incidents is a vital considera-tion for IT organizations. You must be able to respondto incidents based on the ever-changing needs of thebusiness. The ITIL incident management process pro-vides guidelines for assuring that flexibility through astructured prioritization activity.

If an incident occurs, and there is no process for priori-tizing this incident in relation to the other incidents thatare currently being worked on, service can be disrupt-ed.

Human nature is to respond first to the incident thatwas reported first, and the priority for incident resolu-tion thus becomes "first-in/first-out." Or, prioritizingincident resolution might rely on the service desk tech-nician's instinct to gauge one incident as being higherpriority than another. But, would the business agreewith the technician's decision?

In the absence of a process that enables IT to catego-rize and prioritize incidents based on the businessimpact of the event, it's a free-for-all at the servicedesk. Without the right incident management structureand process in place, incident resolution most likely willnot be in concert with the needs of the business.

Consider, for example, that an incident at a bankinginstitution causes ATMs to fail, and at the same time, ina separate incident, the systems fail at the bank'sbranches. Both incidents are recorded in the operationscenter, virtually simultaneously.

6 Implementing Service Level Management with ITIL, An Internet.com IT Management eBook. © 2009, Jupitermedia Corp.

Implementing Service Level Management with ITIL[ ]

Page 8: Implementing ITIL

In the absence of guidelines for prioritizing incidents,the service desk cannot reliably determine which inci-dent should be resolved first. Should the ATMs berestored first, or is it more important to get the branch-es back online?

The answer depends on the priority of the incident asviewed by the business. IT needs the flexibility to shiftits incident resolution efforts and focus based on whichincident is considered higher priority by the business:the failed ATMs or the bank branch system failure.

ITIL defines priority as the combination of impact andurgency. While the bank branches being offline may beof greater impact, that problem is only half of the equa-tion.

What if these incidents occurred on a federal holiday,when the banks are closed? Although the impact of theincident is still the same (i.e., the branches are stilldown), the urgency is low, since no one is trying to usethe systems in the branches.

Conversely, the failed ATMs, while perhaps having alower impact, have a much higher urgency since that'sthe only means for people to withdraw cash.

As a result of assessing both impact and urgency,resolving the incident that resulted in the ATMs beingdown would be given a higher priority over the inci-dent that impacted the branches. This is how the flexi-bility created by the structured ITIL process results in

the lyrical sound of cash once again being dispensed.

Flexible Capacity ManagementThe structure of ITIL can also improve your IT organiza-tion's flexibility in responding to the continually chang-ing demands for scarce computing resources.

Imagine that your business customer plans to launch amarketing campaign that will increase revenue but willalso increase the traffic to your Web storefront. In theabsence of a structured approach to assessing and pro-viding for capacity needs, companies frequently areeither caught off guard or over-provision their infra-structure.

Applying the ITIL capacity management principles ofbusiness, service, and resource capacity management,as well as demand management, provides IT organiza-tions with the ability to flexibly respond to the needs ofthe business while doing so in the most cost-effectivemanner.

In jazz, "riffs" are the repeating, harmonic figures thatform a structural framework for the improvisationalpiece being performed. Riffs keep the musicians ontrack within the theme. Think of ITIL process manage-ment techniques as the riffs that form the framework ofyour enterprise, giving both IT and business the flexibil-ity and expression they need. Together, you and ITILcan make beautiful music. �

7 Implementing Service Level Management with ITIL, An Internet.com IT Management eBook. © 2009, Jupitermedia Corp.

Implementing Service Level Management with ITIL[ ]

Page 9: Implementing ITIL

Companies of all sizes and across all industries areembracing ITIL in record numbers. By developingprocess-driven IT organizations, these companies are

achieving significant efficiency improvements and cost sav-ings.

"Before we began ITIL, we had a 700 trouble ticketbacklog and now we neverhave more than 40 to handleat any one time," said FranFindley, a project manage-ment analyst for informationservices at MultiCare HealthSystem in Tacoma, Wash."Now it takes hours ratherthan weeks to handle anescalated user issue."

Ed Holub, a research directorfor IT operations manage-ment at Gartner states thateven though ITIL is a set ofintegrated best practices itdoesn't mean it is a cookie-cutter program that lays outexactly how things should be done."ITIL is high-level and focuses on 'what' should bedone, but doesn't describe at a detailed level 'how' to

do it,” he said. "It is important, therefore, that IT andbusiness executives work together to understand whatspecific business problems they are trying to resolve,and how ITIL can be an enabler to solving them."

Ron Potter, manager of best practices at TeamQuestCorp. of Clear Lake, Iowa, agrees. He feels that it is

vital to gain early consensuson the reasons for imple-mentation.

"Everyone needs to agreeon the business benefits fordoing ITIL," said Potter."Some do it purely toimprove service, some toreduce costs, some toimprove communicationsbetween IT and business,the rest some combinationof the three."

Buy-in, of course, starts atthe top. At MultiCare, theCIO and a line-of-business

vice president championed ITIL and provided a budgetto upgrade the help desk tracking system and associat-ed processes.

8 Implementing Service Level Management with ITIL, An Internet.com IT Management eBook. © 2009, Jupitermedia Corp.

Implementing Service Level Management with ITIL[ ]

Ensuring a Successful ITIL Implementation

By Drew Robb

Jupiterimages

"Before we began ITIL, we had a 700 trouble ticket backlog and now wenever have more than 40 to handle at any one time," said Fran Findley, aproject management analyst for information services at MultiCare Health

System in Tacoma, Wash.

Page 10: Implementing ITIL

Understanding the BusinessTypically, senior executives publish goals for the comingyear. The individual business units then determine whatactions they need to take to support them.

But how can IT learn what these goals are? Ask, saidFred Broussard, research manager for EnterpriseSystem Management Software at IDC.

A smart IT team can canvass the various business unitsto understand their short-term and long-term goals,and determine how IT fits in. Once the basic intelli-gence is mapped, IT management should have a goodfeel for where the business is at today, where it is goingand to determine the best implementation of ITILaround the aggregated goals.

It is common sense to start such an initiative at the topin order to ascertain C-level goals and align projects toongoing programs to increase revenue and better serv-ice. The lower down the chart you go, the more detailis required until all stakeholders have been addressed.

With that basic research completed, though, there isstill plenty of work to do. Asking is one thing, but it hasto be backed up by solid commitment from thoseaffected.

"A CIO needs to be really careful that they get thecommitment to participate on boards, to provide fund-ing, and add manpower," said Broussard. "You cangauge your level of real commitment by how easilyexecutives blow off ITIL-related meetings."

Understanding ITWhile IT has to be all over the business side to estab-lish goals and align to existing endeavors, the oppositedoesn't necessarily hold true. It just isn't necessary forbusiness executives to get involved in all the details ofhow the various ITIL processes are executed, much lesshow the underlying technology infrastructure functions.

"A core concept in ITIL is to define IT services in termsthat the business understands," said Holub. "Businessexecutives should keep it simple by working with IT todefine what those services are, and be able to negoti-ate formal service level agreements (SLAs) that correctlysync up expectations of what the business needs withwhat IT is capable of delivering."

9 Implementing Service Level Management with ITIL, An Internet.com IT Management eBook. © 2009, Jupitermedia Corp.

Implementing Service Level Management with ITIL[ ]ITIL’s Top 10Quick WinsBy Graham Price

Major change and continuous improvement efforts,such as the implementation of ITIL's best practices,take time. However, most people, including seniormanagement, won't go on the long march unless theysee compelling evidence within a short time that thejourney is worth the effort and cost, and is producingexpected results.

Here are some of the most common quick wins tokeep in mind as you build your own plans:

10. Consolidation to One Incident DatabaseEven if your organization is spread out with multiplephysical service desks, common reference to a singleincident database will enable more consistency ofprocess, consolidated data for reporting, and morerelevant analysis of incident and problem trends. Youwill end up with faster and more accurate decisionsfor changes and improvements.

9. Establish a Single Point of ContactA SPOC is not to be confused with a single servicedesk (or an alien life form). You can have multipleservice desks for different geographies, languages,business units, etc. Just make sure each customeronly needs to know the one place to contact for every-thing.

8. Establish Incident Management PoliciesGive your service desk staff some hard guidance onhow to consistently handle specific, expected situa-tions. The danger of training people in generic cus-tomer service skills and then not giving them specif-ic procedures for how to handle typical situations isthat they will do well the first time, and maybe thesecond and third times -- but each time they are possi-bly reinventing how to handle the situation.

7. Start Thinking ProblemManagementTo be able to effectively engage in ProblemManagement, you need to get out of the front lineand start analyzing incident data. Write this taskinto job descriptions and allocate the time to do itproactively.

6. Start Documenting Requests for Change (RFCs)Create a log of changes, when they happened, whatwas changed, who was responsible for the change,and whether the change was successful, i.e., were any

continued

Page 11: Implementing ITIL

One good way to bring both camps closer together,suggests Brian Johnson, ITIL practice manager at CAand author of 15 books on ITIL, is to address criticalbusiness continuity (BC) issues. His company hasaligned software tools for help desk, asset manage-ment, change management, and BC to ITIL.

"By formulating a proper plan for disaster recovery, IThelps catalyze business involvement and drive a betterunderstanding between the two camps," he said.

Role-playing games, too, such as CA's Apollo 13 ITILsimulations, may help organizations drive ITIL aware-ness by providing real-world scenarios. These enableteams to learn about managing processes more effec-tively. The end result can be an educational experiencethat demonstrates the benefits ITIL can offer to bothsides of the business.

Like CA, TeamQuest is also aligning its software to theITIL framework in order to bring IT and business unitscloser together. TeamQuest View, for example, addsvalue to ITIL service delivery, capacity management,service support, and infrastructure management andITIL application management.

"Business leaders need to be an integral part of an ITILimplementation and participate from the beginning,"said TeamQuest's Potter. "They should participate inbasic ITIL training in concert with their IT counterparts.For best results, this basic training should be cus-tomized to the organization so all can understand howITIL will fit in day-to-day operations and the benefits itwill provide."

Work EthicHolub emphasizes that organizations shouldn't under-estimate the level of effort required to transform theminto being more process- and service-centric.

"Fundamentally, ITIL is less about technology and ismore about changing the culture of an organization toembrace the value inherent in standardization versusone-off solutions," he said. "Always remember that ITILshould be viewed as a means to an end. Don't get fix-ated on achieving a certain level of process maturityand lose sight of the underlying goals that motivatedthe journey to begin in the first place."

10 Implementing Service Level Management with ITIL, An Internet.com IT Management eBook. © 2009, Jupitermedia Corp.

Implementing Service Level Management with ITIL[ ]incidents triggered? It is a worthwhile first step thatwill help with analyzing trends and defining yourproblem's scope with "out-of-control" changes.

5. Get Buy-In from Application DevelopmentITSM is all about operations, and within ITIL therearen't many opportunities for application develop-ment staff to get involved (Change Managementbeing the obvious one). Get them engaged and atleast raise their awareness sooner.

4. Talk "Service” Instead of "System"There are still too many people in IT who think theirjob is "to make the systems run" instead of "to helpsell insurance policies" (or whatever it is you do).Here is the reality check: If systems are fine but serv-ices are out, customers are unhappy. If some systemsare out or under stress but services are fine, cus-tomers are happy.

3. Think "Bottom-Up" Not "Top Down"No one disagrees that executive buy-in is crucial for asuccessful process initiative just as in any organiza-tional change program. But real change is embeddedinto the rank and file organization one event at atime: one change, one incident, one problem, onerelease.

2. Start Open ReportingIt is essential that we measure in order to improvebut, it is just as important to communicate theseresults to everyone involved in order to maintain themomentum once things start to move in the rightdirection.

1. Get The Boss Excited & InvolvedA key challenge for CIOs, IT directors, project man-agers, process owners, and change agents is to identi-fy early successes as part of the overall planningprocess.

CA's Johnson agrees and offers a way to create culturalchange: Identify ITIL champions in all areas of the busi-ness and train them to become evangelists within thebusiness.

"It's also important to ensure that the ITIL plan is notperceived solely as an 'IT' project," he said."Awareness training early in the project lifecycle helpsovercome resistance. People need to understandwhat's driving the initiative, why change is needed, andhow they and the organization will benefit."

Page 12: Implementing ITIL

Participation. Agreement.Metrics. Checks and Balances.IDC's Broussard stresses the importance of communica-tion in getting everyone to participate. He related acouple of anecdotes to highlight this point. One con-cerned a federal agency involved in a major softwareupdate that required testing and development on a livesystem. Instead of keeping it a secret, users were toldabout the testing and to let IT know of any problems.

"They really appreciated it, and they trusted us more asa result," said Broussard. "The alternative -- building adevelopment site on a separate IBM mainframe --would have been very expensive."

On the negative side of the ledger, Broussard tells of amidsized organization's CRM rollout. IT decided tofocus on satisfying the needs of sales staff and thenlater expand the system to include customer supportstaff.

IT, however, failed to appreciate that a major portion ofcustomer contact came via e-mail and the CRM systemdidn't function well with e-mail. Yet all that was neededwas a simple one-button click to have an e-mail storedas a record in the CRM system.

"IT didn't really talk to the customer support peopleand ended up with a decent tool for sales that cus-tomer support doesn't have much use for," saidBroussard.

The takeaway? Everyone involved has to be consultedand also attend meetings so they know what is plannedand what others are thinking. This, said Broussard, isthe best way to establish commitment.

Deadlines & CommitmentsWhile communication is the starting point and the carri-er wave of project success, it has to be augmented bya multitude of other factors.

"Fully implementing the 10 core service delivery andservice support processes that ITIL describes is a jour-ney that will take several years in most cases," saidGartner's Holub. "Therefore, it is important to prioritizewhat will add the most value and also address currentpain points."

The majority of clients, he said, pick a few processes tostart working on, with Change, Incident, and Problemmanagement being the most common. Companies thatlimit their ITIL rollouts in this way and treat it as a for-mal project or even a program consisting of multipleprojects tend to be more successful in adhering totimelines, budgets, etc.

Those who fail often bite off too much change at once,bogging down their efforts. The error is then com-pounded due to the resulting loss of executive supportand a greater level of skepticism from the front-line ITtechnical staff.

Getting In & Getting OutMany companies take what they think is the easy routeby assigning a part-time staff to their ITIL projects.While this makes it simpler to get started, it makes itharder to adhere to deadlines and it can be a longwhile before observable benefits are apparent. Full-time resources, ideally, are the way to go.

"Selecting people from various infrastructure and oper-ations teams to work full time on ITIL efforts is the lesscommon approach, but generally delivers higher quali-ty results in a shorter timeframe," said Holub.

Personnel selection, though, can be a major point ofcontention. Resources you thought were available sud-denly are sent elsewhere.

"To avoid potential conflicts during implementation,resources should be identified as part of the businessplan and agreed upon by all," said TeamQuest's Potter."Any changes need to be driven through the changeprocess by the project manager and agreed upon by allparties concerned."

He cautioned, however, that day-to-day businessprocesses need to be maintained. Thus, flexibility mustbe built into the plan to account for a reasonable num-ber of unforeseen events.

CA's Johnson said even the best laid plans can besidetracked especially if resources are cut or rede-ployed, or priorities change. Thus an exit strategy mustbe built in during the planning stages.

"Planning should include some identifiable targets to

11 Implementing Service Level Management with ITIL, An Internet.com IT Management eBook. © 2009, Jupitermedia Corp.

Implementing Service Level Management with ITIL[ ]

Page 13: Implementing ITIL

scrub the project if things go wrong," said Johnson."The best defense is a well constructed project planwith regular updates and an exit strategy (with the pro-jected impact on the business) should resources sud-denly dry up."

Checks & BalancesHolub said it is vital to select a balanced set of metricsto gauge the health of processes from both an efficien-cy and effectiveness perspective.

"If either efficiency (cost) or effectiveness (quality) isoveremphasized, you may inadvertently drive thewrong behavior," he said.

Potter, on the other hand, highlighted the value ofdashboards. While more in-depth status reports shouldbe provided bi-monthly or monthly, dashboards offer aquick indicator of project component progress. Simplered, yellow, and green are usually sufficient.

"There should be two measures: one is current statusand other is the trend," he said. "This helps manage-ment better determine where attention is most need-ed."

In addition, he called for post-implementation perform-ance reviews. Such reviews answer the questions: "Didwe accomplish what we set out to do?", "Was it asmooth and quality implementation and if not, whatparts of the implementation process need changing?",and "Is this new process providing the expected bene-fit and if not, what changes need to be made?"

Remember TCOWhile ongoing metrics are important, it may be evenmore key to long-term ITIL success to put in placemechanisms to measure Total Cost of Ownership(TCO). Gartner's measurements, after all, show thatmoving from no adoption of ITIL to full adoption canreduce an organization's TCO by as much as 48 per-cent. �

12 Implementing Service Level Management with ITIL, An Internet.com IT Management eBook. © 2009, Jupitermedia Corp.

Implementing Service Level Management with ITIL[ ]

Page 14: Implementing ITIL

ITIL has a clear definition of Service Level Management andgoes into considerable detail on the process, implemen-tation, and content of the key deliverable, the Service

Level Agreement (SLA).

But is the SLA really the key deliverable?

ITIL does not go into suchdetail on Service LevelRequirements (SLRs),Operational LevelAgreements (OLAs),Underpinning Contracts(UCs), or the ServiceCatalogue. Let's discuss theseimportant parts of an SLA andprovide guidance on theiruses. The outcome will be anunderstanding of why ITILplaces so much importanceon the production of SLAs.

Service Level AgreementsA Service Level Agreement is a documented agree-ment between IT and its customer (internal to anorganization) on the levels of a service being provided.The most important aspect of an SLA is that it is anagreement and bears no contractual weight to meet

these targets. It is a commitment.

The SLA should not favor one side. It is a fair reflectionof the business requests and requirements that IT canprovide. It should not be a smoking gun pointed at IT,nor does it relieve IT from providing adequate service

to the business. It does,however, set expectations.

The obvious risk of missingService Levels is damage tothe business. Yet another,and just as important, is theeffect on customer percep-tion that can ultimatelyresult in the loss of faith inIT.

Another common flaw is theinability for organizations tocreate agreements that aresimple and concise. An SLA

should be no more than three or four pages, not 20.

ITIL identifies how to make this work across largeorganizations with multiple services. Customer-basedSLAs (one SLA per customer across multiple services),service-based SLAs (one SLA per service), and multi-

13 Implementing Service Level Management with ITIL, An Internet.com IT Management eBook. © 2009, Jupitermedia Corp.

Implementing Service Level Management with ITIL[ ]

The Key to Quality Service Level Management

By Karsten Smet

A Service Level Agreement is a documented agreement between IT and itscustomer (internal to an organization) on the levels of a service being provided.

Page 15: Implementing ITIL

tiered SLAs (corporate-based SLAs, customer-basedSLAs, and service-based SLAs in three-tier format) alloffer the ability to enable simple, easy-to-manageSLAs.

Use simple, achievable rules when creating metrics thatapply to SLAs, OLAs, and UCs. Too many organizationsspend far too long coming up with encompassing SLAsthat in truth are not measurable and will never providean understanding of how the service is performing. Thetime spent creating these large documents is a waste.

Service Level RequirementsDo we put too much emphasis on SLAs? To answerthat question, we need to understand where this agree-ment originates. It is equally important to understandthe business requirements for any services IT providesand that they are concise and well documented.

In a mature ITIL environment, the Service Desk (whereappropriate) will support gathering the requirements.They are speaking to customers every day, and fre-quently liaise with the Availability Manager to discussthe customers' perception of the service. Even with aService Desk in place, the ability to gather and docu-ment a true set of Service Level Requirements and thenconstruct into a SLA is far from simple.

IT and business speak a different language. Customersshould communicate in their own words what theyneed from a service. Avoid the SLA headings such as"Availability, Throughput, etc." as these will mean littleto an everyday user or customer. In an ideal world

where time is not an obstacle, it is useful to sit with cus-tomers who use or will use a service for the first timeand understand their requirements. Don't just takewhat they say and translate it to "what we think theywant."

Once it is clear what the customers want from a serviceand you understand what their requirements mean, it ispossible to begin to transform the information into anSLA. The basic template should be derived from, andmaintained within, Service Level Management. It's pos-sible that certain headings of the SLA template are notapplicable and if this is the case, there is no reason tocreate additional requirements.

To better understand the translation of the customerrequirements to an SLA, and to gather a picture ofwhat each section of the SLA means, completely focusthe draft on the customer and review with the business.From this, negotiations can then begin.

Once IT is confident they understand the requirements,they are in a good position to evaluate whether theycan achieve these goals or offer options. The best wayfor IT to ensure the customer appreciation of why arequirement can or cannot be met is to translate theservice into financial terms (e.g., the extra cost of 24x7availability).

The negotiation period will often result in multiple draftSLAs, but the focus must always remain on the mostyou can provide the customer without overextendingIT. �

14 Implementing Service Level Management with ITIL, An Internet.com IT Management eBook. © 2009, Jupitermedia Corp.

Implementing Service Level Management with ITIL[ ]

Page 16: Implementing ITIL

Every IT ServiceManagement consultant will tell you thesame thing: Everyone wants to jump into Service LevelManagement and set their Service Level SLAs right

away.

While the SLAs get a lot ofpress, they are part of theService Level Management(SLM) process and we needto step back and discuss howwe should arrive at SLAs.

The goal of SLM is to under-stand the requirements of thecustomer and organization,factor in the capabilities ofthe supplier(s), and thendeliver quality services thatmeet those requirements andare subject to constantimprovement. The intent ofthis is to build a better rela-tionship between IT and its customers.

It is important to have a solid SLM process, as it willaffect the overall ITSM initiative. In fact, if your opera-

tions environment is not stable, you should start withChange and Configuration Management first, as settingSLAs can cause everyone to lose confidence in theITSM effort.

To start the journey, IT mustdesignate a Service LevelManager who is empoweredto negotiate with the cus-tomers and make commit-ments that are binding onthe IT organization. This per-son must be very knowl-edgeable about IT and thebusiness and be an excel-lent communicator withhoned negotiation skills.

The Service Level Managermeets with each customerand understands require-ments. The manager then

crafts a Service Level Requirements (SLR) document thatidentifies in business terms what the customer needs.

Next, the SLM manager meets with the suppliers who

15 Implementing Service Level Management with ITIL, An Internet.com IT Management eBook. © 2009, Jupitermedia Corp.

Implementing Service Level Management with ITIL[ ]

The Right Way to Set SLAs

George Spafford

The Service Level Manager meets with each customer and understandsrequirements. The manager then crafts a Service Level Requirements (SLR)

document that identifies in business terms what the customer needs.

Page 17: Implementing ITIL

provision the services that the customer is interested in.These suppliers could be internal, external, or a mixturethereof. These suppliers need to review each service andcraft Service Specification Sheets for each. If the SLR is acustomer-facing document, then the spec sheets can beviewed as the technical underpinning documents outlin-ing how the business requirements will be met.

Metrics Must MeanSomething to CustomersNow, derived from the customer's requirements setforth in the SLR and the supplier inputs in the specsheets, the manager crafts a Service Quality Plan (SQP)that puts forth key performance indicator metrics andany critical success factors for monitoring the perform-ance of the service. It is important that the metrics havevalue to the customer and IT, not just IT.

When communicating with the customer and ensuringrequirements are met, it is very important to be meas-uring what matters. For example, what value doesavailability as a percent really serve if the business losta painful $2 million during an outage that occurred dur-ing the 0.001 percent of unplanned downtime?

At this point, the manager needs to negotiate theagreements relating to provisioning. The ServiceCatalog documenting what IT can provision must bedeveloped or refined if it already exists. The SLAs stat-ing what IT and the customer will each provide andhow the relationship will be managed must be crafted.The OLAs stating how IT will meet the service levelsthat are needed and the UCs committing vendors mustbe set as well.

To be clear, the OLAs are used with internal groups toensure they can provide service levels that enable IT tomeet the customer's defined Service Levels. UCs areused with vendors/third parties to ensure they canmeet defined Service Levels.

The creation of these agreements will require repeatedsessions of negotiation, creation of drafts, amendments,and reaching a final conclusion for each that commitsthe involved parties. This level of negotiation is why theService Level Manager must be skilled in both commu-nications and negotiations plus have a solid understand-ing of the IT organization and the business.

When creating the aforementioned agreements, alwaysthink about how objectives and service levels can becrafted such that they are "SMART" meaning they mustbe Specific, Measurable, Attainable, Realistic, andTimely. One reason for these attributes is that once theagreements are set performance must be measuredusing the critical success factors and key performanceindicators set forth in the SQP.

It's About the RelationshipAn SLA is not a contract. It is a formal expression of arelationship. If an SLA is so complicated that nobodycan understand it and therefore gets confused as towhat to do when and how, then the results can actuallybe counterproductive and harm both service levels andthe relationship with the customer. IT exists for the cus-tomer -- not the other way around -- and some carefulgive-and-take may be needed.

On an ongoing basis, monthly or quarterly for example,the Service Level Manager should sit down with thevarious customers to review the performance of IT rela-tive to the services provisioned for each customer.

In areas where corrective action is needed, a ServiceImprovement Plan (SIP) should be launched and one ofthe outcomes may be to revise the previously definedservice levels. These Service Review meetings are agreat opportunity to not only discuss performance, butalso the direction of the customer and IT. Wheneverthere is a customer contact point, that opportunityshould be used to understand what is going on withthe customer and to update the customer about whatis going on in IT.

The idea is to build the relationship constantly. If therelationship is lost, then all of the service level docu-mentation is pretty much pointless.

The most important things coming from SLM are notvoluminous agreements that sit on a shelf. In otherwords, the goal is not to simply create documenta-tion. Instead, the true benefits lie in understandingthe needs of the customer, measuring IT's perform-ance against those requirements, and then continu-ously seeking methods to improve the provisionedservice levels. In this manner, IT can deliver qualityservices to the organization that enables organization-al goals to be met. �

16 Implementing Service Level Management with ITIL, An Internet.com IT Management eBook. © 2009, Jupitermedia Corp.

Implementing Service Level Management with ITIL[ ]

Page 18: Implementing ITIL

Themost overlooked process, the Cinderella of allprocesses, is the Service Level Management (SLM).Service Level Management is the process of planning,

coordinating, drafting, agreeing, monitoring, and reportingon SLAs, and the ongoing review of actual service achieve-ment to ensure that the required and cost-justifiable qualityof service is maintained and improved.

The SLM process is the hingefor the service support andservice delivery processes. Itcannot function in isolation,as it relies on the existenceand effectiveness of otherprocesses. SLM is focused onintegration -- how well theservice support and servicedelivery processes functiontogether.

SLM is responsible for ensur-ing SLAs and OLAs or UCsare met. Ensuring that anyadverse impact on servicequality is kept to a minimum also falls with in the realmof SLM. SLAs provide the basis for managing the rela-tionship between the customer and the provider. AnSLA without measurable and defined expectations for

each of the support processes is useless, as there is nobasis for validation of the level of service expected.

Most consideration to SLM is given during the Requestfor Proposal (RFP) phase. At that time, repeatedly, onlyone part of SLM becomes important: the SLA. But,soon after the bid has been awarded, the guidelines ofthe SLAs are no longer written in stone and up for

interpretation. This comes tothe detriment of the cus-tomer and the serviceprovider.

Today there is a disturbingtrend propagating itselfthrough ITSM implementa-tion efforts both in the gov-ernment and civilian sectors.ITSM implementers areviewing Service LevelManagement as a necessaryevil and not as the asset thatit truly is.

Let's look at some examples from an ongoing contractthat's been supported for more than four years. This isa Service Delivery contract for a customer that out-sourced its IT services to a prime contractor. This cus-

17 Implementing Service Level Management with ITIL, An Internet.com IT Management eBook. © 2009, Jupitermedia Corp.

Implementing Service Level Management with ITIL[ ]

Service Level Management is the Hinge

By Darreck Lisle

An SLA without measurable and defined expectations for each ofthe support processes is useless, as there is no basis for validation

of the level of service expected.

Page 19: Implementing ITIL

tomer historically had all of its internal IT requirementsand delivery left to individual business units (silos). Thatmeans that every silo had its own budget, require-ments, and tools to conduct their business independ-ently. This practice equated to having several hundreddisparate networks with their own unique flavor of howthey should conduct business, and not as service offer-ings.

During the SLM portion of the RFP, the SLAs were writ-ten in such a way that they did not establish accounta-bility, capture expectations, or provide escalation ofcompliance issues. They were written from a gover-nance/oversight role without specifying what data is tobe made available to the customer and definingIntellectual Property that should be rightly protected bythe service provider.

As soon as the contract was signed, both parties beganto interrogate the SLAs for what they could use to pro-tect themselves. The service provider, instead of figur-ing out how the SLAs can help the customer benefitfrom the best solution, classified everything as intellec-tual property, and the customer began to ask fordetailed reports and data sources that deemed to beoutside the scope of a customer purchasing IT services.

The contract specified numerous SLAs and three levelsof service for each one. These levels of service had acost associated with them based on the delivery time.At the same time, the SLAs were written so poorly thatthere were no consequences outlined for failure tocomply with the thresholds.

Let's drill down into one of the SLAs and provide you asnapshot of the complexity introduced from the poorlywritten SLAs:

• SLA XX: "The Contractor shall provide and maintaina CMDB for tracking assets."

• Metrics: "The time to update the CMDB will notexceed a four hour window."

This is how the configuration management SLA looked,minus some sensitive verbiage. In a nutshell, this wasthe extent that the customer could hold the serviceprovider accountable for all configuration managementefforts provided as an offering.

The first thing the service provider did was to place aprice tag to every CI as an attribute, thus limiting thecustomer from viewing the CMDB information.Consequently, there was no value add for any of theother processes accessing the CMDB. In reality, theCMDB was merely an asset library that moonlighted asa DSL for release management.

How well did the CMDB perform based on the manda-tory SLA Report? The configuration manager nevermissed an SLA because it only took milliseconds topress the save button on his/her database.

This particular customer didn't back down from thechallenge and began to introduce tactics to combat thepractice of hiding behind the SLAs. The frustrated cus-tomer started asking questions like: "What am I payingfor?" "How many assets do I have in the environ-ment?" and "I want you to prove it to me before Ipay."

To quote one senior manager, "Fundamental, standard-ized, repeatable processes, or rather the lack thereof,have been a sea anchor on our project for some timenow. The perspective is that we (customer and serviceprovider) just don't have time to do it right, but alwayshave time to do it over. For both of us to succeed, thismust stop."

It should be clearly understood that either extremelytight SLAs are written and executed, or cus-tomer/contractor interdependencies are establishedthroughout the support and delivery processes. Whilethe IT service providers may passionately desire thatthe customer is completely uninvolved, this rarelyoccurs unless the customer is ignorant, unconcerned,or both.

Today, there is a realization that both parties have towork together to make sure that this contract is suc-cessful. Large amounts of negotiations, sacrifices, andretooling have gone on over the years, and finallymeasurable SLAs are on the drawing board.

Lessons Learned• SLM cannot be pigeonholed into a small piece of theRFP with little or no thought about how the entire serv-ice delivery contract will be affected.

18 Implementing Service Level Management with ITIL, An Internet.com IT Management eBook. © 2009, Jupitermedia Corp.

Implementing Service Level Management with ITIL[ ]

Page 20: Implementing ITIL

• SLAs need to have input from both the serviceprovider and the customer to ensure that the goal ofthe project is achieved.

• SLA data must include metrics, expectations, dataaccessibility requirements, ownership, and escalationprocedures written into the contract from the begin-ning.

• The upfront cost of writing solid SLAs is far lessthen trying to short cut the accountability of provid-ing quality service.

The improvements in service quality and the reductionin service disruption that can be achieved througheffective SLM can ultimately lead to significant financialsavings.

Below is an example of how to quantify the costs andbenefits of implementing Service Level Management. Itis not intended to be comprehensive. It can be popu-lated with specific assumptions, purposes, costs, andbenefits to get an example that is more suitable to thespecific circumstances.

In this example, the following assumptions are made:• 100 employees cost $25 an hour each• The organization comprises 50,000 users• The total number of incidents is 50,000 per year

Thanks to a clear set of agreements, the Service Desk isless troubled with calls that are not part of the servicesoffered. This way, the 100 Service Desk employeeswork 5 percent more efficiently, resulting in a gain of100 x 5% x $25 x 24 x 365 = $1,095,000 a year.

Most organizations that use IT are dependent on it, andif processes are not implemented, managed, and sup-ported in the appropriate way, the business will proba-bly suffer unacceptable degradation in terms of loss ofproductive hours, higher production costs, and lostopportunity translating into loss of revenue.

The objective is to continually improve the quality ofservice, aligned to the business requirements, cost-effectively. But unless people, processes, and technolo-gy are considered and implemented appropriatelywithin a structured framework, the objectives of servicemanagement will not be realized.

The implementation of Service Management is not aone-time project, but rather a continuous process ofenabling overall service improvement. �

19 Implementing Service Level Management with ITIL, An Internet.com IT Management eBook. © 2009, Jupitermedia Corp.

Implementing Service Level Management with ITIL[ ]

Page 21: Implementing ITIL

Nowthat we've examined how to begin an ITILimplementation and looked at SLAs, let's reviewsome of the ITIL processes that IT departments will

have to put into practice.

ITIL uses specific wording inthe Incident and ProblemManagement process areasto describe the lifecycle ofsystem errors through tostructural resolution. The rela-tionship of the terminologyused is an interesting topic ofdiscussion, as we can explorethe handling of a service errorthrough the IncidentManagement process andopportunities for improve-ment.

An incident is any event thatis not part of the normaloperation of a service and impacts, or threatens toimpact, the quality of the service delivered. Inresponse, IT opens an incident record to try to quicklyrestore the service to operating within the parameters

of the SLA.

The perspective is grounded in the SLA because itshould outline performance expectations from the cus-tomer -- not just from IT's perspective. This reflects the

need to support the busi-ness, not just push technolo-gy.

If the cause is readily appar-ent and can be corrected,then a work-around is devel-oped or a request forchange (RFC) created. Somecorrections can be donewithout change -- such asresetting a device -- necessi-tating only a work-around.

On the other hand, if achange is required, it needsto be handled through the

proper Change Management processes. Even thoughIncident Management's goal is the speedy restorationof service, it must not bypass Change Management orthis will cause production build configurations to drift

20 Implementing Service Level Management with ITIL, An Internet.com IT Management eBook. © 2009, Jupitermedia Corp.

Implementing Service Level Management with ITIL[ ]

Incidents, Problems, KnownErrors and Changes

By George Spafford

An incident is any event that is not part of the normal operation of a serviceand impacts, or threatens to impact, the quality of the service delivered.

Page 22: Implementing ITIL

from their established baselines.

If the cause of the error is not readily apparent, or it isfelt that an investigation is required, then a problemrecord should be opened. This new problem record isthen independent of the incident because the incidentmanagement function is tasked with restoring serviceas quickly as possible.

In contrast, the Problem Management function istasked with identifying the underlying causal factor,which may relate to multiple incidents. It may take sev-eral incidents to transpire before Problem Managementhas enough data to understand the root cause. OnceProblem Management identifies the causal factor anddevelops a work-around, then the problem becomes a"known error."

The fact that sometimes Problem Management cannotimmediately identify the root cause and establish a cor-rective action puts the two groups at odds, as incidentmanagement wants a quick fix, or work-around. If theIncident Management team develops a work-around,then the Problem Management record should beupdated with the information so the ProblemManagement team can leverage the additional data.

In reviewing the Incident Management team's work-around, Problem Management may elect to accept thework as the resolution because it addresses the rootcause. If it does not, then Problem Management willdig deeper. If Problem Management develops a work-around that addresses the incident without solving theroot cause, then the incident becomes a "known error."

As mentioned above, if a change is needed, then anRFC must be filed and handled through ChangeManagement. If Problem Management establishes theroot cause and a resolution, they need to alert IncidentManagement so the "known error" tickets can benefitfrom the resolution and have their status shifted to"closed" once the corrective work is completed.

Opportunities for ImprovementThe above outlines the relationships between Incidents,Problems, Known Errors, RFCs and, finally, Resolutions.Building on the topics discussed above, there are sev-eral opportunities for process improvement:

• Be able to quickly identify changes. Most availabili-ty issues stem from changes. The sooner changes canbe identified or excluded, the better. Consider usingan automated integrity management control todetect and report on changes found in the produc-tion environment.

• Use a proper taxonomy in order to match existingincident and problems. Speeding up the search forsimilar, or related, incidents and problems necessi-tates a classification system that supports the needsof the organization.

• Record meaningful notes in the ticket. Personnelinvolved with incidents and problems need to enternotes that are useful to other people in the ticket.Terse or cryptic comments will not aid others whomay need to read and understand the ticket.

• Have a resolution editor. Task someone who canwrite clearly with reviewing resolutions to ensure theyare complete, clearly written and follow any organiza-tional documentation standards. This may also bewarranted for known errors, depending on the orga-nization's needs.

Incident and Problem Management are valuableprocess domains in ITIL. As the pervasiveness of ITincreases in mission-critical aspects of the business, thistrend will continue. As organizations look to ITIL toimprove their processes, they will need to understandthe relationship between Incidents, Problems, KnownErrors, Request for Change, and Resolutions. �

21 Implementing Service Level Management with ITIL, An Internet.com IT Management eBook. © 2009, Jupitermedia Corp.

Implementing Service Level Management with ITIL[ ]

Page 23: Implementing ITIL

ITIL refers to service or systems outage analysis (SOA) as amethod to improve availability. Presented as an availabilitymanagement process tool or technique, SOA is a powerful

management tool to improve quality.

As is quite common since the ITIL is descriptive and notprescriptive, ITIL does not explain how to carry out aSOA. In this section we'llexplain what an SOA is, its ben-efits, and give you an easy tofollow six-step guide to per-forming SOA.

The reason to use SOA is toidentify the causes of outagesand thus reduce the frequencyand duration of outages. SOAaims to improve mean-time-to-repair (MTTR).

The result of an SOA is clearunderstanding of what hap-pened to cause an outage, and exposes the risk offuture outages due to the same cause or causes.Finally, an SOA can produce recommendations forimprovement to avoid the issue in the future.With these types of benefits, you might think that per-

forming an SOA is complicated but, in reality, just theopposite is true: You can perform an SOA without anymajor investment in software, tools, or training.

Performing an SOA is straightforward. Working withProblem Management and customers, you examinepast outages to identify configuration items (CI), such

as the products, people, orprocess, related to an outage.In effect, you simply reviewthe impact to the organizationand infrastructure as reflectedby how the organizationresponded to an outage.

This is different from proactiveproblem management sinceavailability management has ascope that includes theorganization (people, process,training, staffing, etc.).

Getting StartedTo get going, collect outage data in the form of inci-dents, any related closed problems, or known errors.Gather together a team of people familiar with the out-

22 Implementing Service Level Management with ITIL, An Internet.com IT Management eBook. © 2009, Jupitermedia Corp.

Implementing Service Level Management with ITIL[ ]

Six Steps to Service Outage Analysis

By Hank Marquis

The result of an SOA is clear understanding of what happenedto cause an outage, and exposes the risk of future outages due to

the same cause or causes.

Page 24: Implementing ITIL

ages, the infrastructure, processes, procedures, people,and so on. Be sure to include a customer representa-tive and perhaps some users on the team as well (theirinput will be critical in guiding the team through theSOA process).

Once you have the team empowered, lead themthrough the six following steps:

Group related outages together by vendor, product,family, application, customer, etc. Then, using cus-tomer and user input as appropriate, categorize eachoutage as "significant" or "less significant." Focus onlyon those labeled "significant," and monitor the "lesssignificant" for future outages.

For each outage tagged as "significant" review theroot cause of the unavailability (this requires closed inci-dents and problems), for example, faulty hardware orsoftware. This is probably already known since the out-age is resolved.

Perform a simple Pareto analysis to break the signifi-cant issues into a smaller group. Using the Pareto80/20 rule you can rank the related outages and theircauses.

You will find that the majority (80 percent) of the out-ages result from a select few causes (20 percent of theorganization or infrastructure). Of course, you want tofocus on the 80 percent of the outages caused by the20 percent of the causes.

For each grouping of similar outages, examine thereasons for the duration of the unavailability. Forexample, the outage may have occurred because offaulty hardware or software, but the duration of theunavailability might have been extended by lack oftools, little or no training, unavailable spares, etc.

Remember to consider the "3 Ps" -- people, product,and process. Then review:

• All existing procedures and policies used duringthe outage• The actions and inactions of staff members, cus-tomers, and anyone else involved in the outage or itsrestoration• The management directives given to all involvedduring the before and during the outage

You must determine if anything might have lessenedthe duration of the outage, or better yet, avoided italtogether. Your examination of the "3 Ps" shouldlocate a trend, a related cause, or at something in com-mon with similar outages. This is the smoking gun.

For example, a common cause that might extend anoutage may be a hierarchical escalation requirementthat does not allow staff to proceed without manage-ment approval or a special tool is required and couldnot be found.

The next step is to quantify the avoidable outagetime. That is, if one hour of downtime resulted fromtrying to locate the proper tool, then the avoidable out-age time is one hour times the number of outages soaffected.

Identifying the most preventable downtime is yourgoal. This is then the most significant generator of pre-ventable downtime.

End the SOA by creating a report summarizing thenumber of outages analyzed, timeframe, avoidable out-age time, and the suggestions for improving or avoid-ing the outage. Prepare a request for change (RFC) andpass the entire kit on to change management. �

23 Implementing Service Level Management with ITIL, An Internet.com IT Management eBook. © 2009, Jupitermedia Corp.

Implementing Service Level Management with ITIL[ ]

Page 25: Implementing ITIL

Facing hundreds of servers supporting vital businessfunctions, capacity management automation hasbecome amust.

"The sheer volume of infor-mation required to do capaci-ty management in today'shighly complex IT infrastruc-tures makes automation anecessity," said Gartner's EdHolub. "Even with automa-tion in place, however, therestill is a lot of effort requiredby senior IT professionals toeffectively manage capacity."

In capacity planning, datacollection tools are first putin place. This enables organi-zations to gather perform-ance and capacity data,which can be analyzed to build a baseline view ofwhere the current infrastructure stands. With this inhand, the organization can better understand existingbusiness plans and their potential impact on the exist-

ing IT infrastructure.

This highlights any shortfalls based upon the predictionof future resource needs. With these results reported to

management, the cycle con-tinues: Capacity and per-formance data is gatheredon the upgraded infrastruc-ture, which can then be ana-lyzed and new baselinesestablished. Thus capacityplanning is a continuousprocess.

As workloads change, hard-ware is added or networksare reinforced, new base-lines must be isolated, andfuture needs forecasted withaccuracy.

"The first element of capacity management is visibilityof the infrastructure in your environment and knowl-edge of how the elements are connected together todeliver business services and the associated service lev-

24 Implementing Service Level Management with ITIL, An Internet.com IT Management eBook. © 2009, Jupitermedia Corp.

Implementing Service Level Management with ITIL[ ]

Automation IT Capacity Management

By Drew Robb

As workloads change, hardware is added or networks are reinforced, newbaselines must be isolated, and future needs forecasted with accuracy.

Page 26: Implementing ITIL

els," said Rob Stroud, an IT Service Management evan-gelist at CA. "The second element is to understand thedemand on your environment."

Any organization beginning capacity planning activitiesfor the first time faces a daunting prospect-the entireenterprise lies before them. Every process, everyresource, every system, and every building is a poten-tial target.

Getting StartedThe best approach is to prioritize capacity planningefforts based on mission-critical needs. That meansfocusing on infrastructure components supportingthose applications necessary to business survival first.Typically, this centers around order processing, orderfulfillment, manufacturing, and customer service,depending on the business.

Once priorities have been established, the capacityplanner should begin with a resource view to gatherdata, look for outliers, and find out more about them.With that data in hand, the next step is to build profilesfor each component or groups of components such asclusters, banks, and mirrors.

The capacity planner should also dig in to locate repet-itive cycles. For example, there might be a spike onserver usage every Friday afternoon caused by every-one logging on to check messages and complete tasksbefore the weekend. Monthly, quarterly, and annualprocesses can also be tracked. Capacity planningefforts can be thwarted by a failure to take these repeti-tive cycles into account.

Further, the capacity planner must determine represen-tative timeframes. This is meant to discern usage levelsthat fit various time frames: How many workstations willbe in use at any one time? How will usage patternsshift over time? Similarly with servers, representativetimeframes must be established to take into accountusage and other metrics.

Obviously, such tasks require automation. But rollingout performance data capture software across severalthousand servers can be a daunting task. Even if agentsare used, they still need to be configured in order tocustomize the data collected and the way it is aggre-gated for reporting purposes.

Further, associating business events to usage can beproblematic. Performance data, after all, is of little useif you can't determine the business events associatedwith the usage. Large organizations with several hun-dred applications, for example, make this task complexand extensive.

Such challenges can be overcome by using installationscripts that can be easily integrated into existing soft-ware distribution tools to help automate installation.Centrally based administration can also facilitate config-uration by propagating commonly used configurationsacross large number of servers. For example, operatingsystem component usage may be accounted for in an"overhead" category and a database management sys-tem accounted for in a "DBMS" category.

"As the delivery of services gains complexity, automa-tion is key to delivering capacity solutions," saidStroud. "Automation leveraging technology is criticalincluding the configuration management database forthe storage of the relationships and performance man-agement technology to record performance in real timeand delivers usage information and alerts where capaci-ty thresholds are exceeded."

The Role of AnalyticsAnalytics and business intelligence (BI) tools play a partin capacity management. Advanced analytics permityou to better monitor infrastructure behavior. For exam-ple, you may have a server that operates at 40 percentcapacity. One day the utilization jumps to 60 percentand stays there. Since your capacity threshold for alert-ing occurs at 75 percent, it may be some time beforeyou realize that there might be a problem.

"In addition, advanced analytics could perform continu-ous trending functions so when application usagestrays from what is expected, the appropriate peopleare alerted to determine cause and permit correctiveactivities or drive changes to the capacity plans," saidTeamQuest's Ronald Potter. "Where business metricsare not available, business intelligence tools can helpyou understand business processes and how theyimpact infrastructure capacity."

By using BI, it is possible to determine counts of busi-ness events and associate them to the data containedin the capacity database. Doing so facilitates the ability

25 Implementing Service Level Management with ITIL, An Internet.com IT Management eBook. © 2009, Jupitermedia Corp.

Implementing Service Level Management with ITIL[ ]

Page 27: Implementing ITIL

to communicate infrastructure capacity in businessterms.

But tools are only part of the solution. As with all ITILimplementations, the capacity management processrelies on the right combination of people, process, andtechnology. Thus, effective capacity managementnecessitates working relationships with business units.Changes in business processes, even using the sameapplications, can dramatically affect system perform-ance. Signing a large new customer can have a similarimpact.

"Without good working relationships with your busi-ness customer, you may not discover business changesuntil after they have happened and your systems areoverloaded," said Potter. "A good working relationshippermits you to run your infrastructure closer to theedge since you have confidence that in most cases youwill have enough advance notice to react to businesschanges."

Process, too, is vital. Processes play an essential role inthe success of capacity planning. The roadmap to suc-cess is processes that are repeatable and consistent.The results from process efficiency can be significant.

"In research I've conducted on behalf of the IT ProcessInstitute, we discovered that high performing IT organi-zations (which constituted about 13 percent of our sur-veyed population) sustain five-times higher server/sys-admin ratios, manage eight-times more projects andsix-times as many applications, and implement 14-times as many changes compared to the typical organi-zation,” said Gene Kim, CTO of Tripwire.

Once you understand the processes and their interac-tions with other processes, automation is key.Automation enables the implementation of the knowl-edge developed in the organization and allows forenhanced customer support.

Some vendors offer solutions and tools that automateITIL, as well as supporting materials such as a series ofgraphical representations or subway maps that helpthem no matter where they are in their implementa-tions.

Capacity Management Not Enough

IT has to have information from the business regardingforecasted growth so it can translate increases in busi-ness volumes into hardware/software resource con-sumption. It is vital to have well-defined SLAs betweenIT and the business, so that just enough capacity canbe cost effectively provisioned to meet those agree-ments.

That's where capacity management comes in. Byautomating many of the processes and harnessing vari-ous tools to add efficiency, capacity-planning effortscan be streamlined and simplified.

But Holub points out that capacity management cannotoperate in isolation within an ITIL framework. Norshould it be done prior to certain other facets of ITIL

"Capacity management is one of the higher-order ITILprocesses," said Holub. "Organizations should ensurethey have achieved relatively high process maturity inthe core service support processes such as changemanagement and configuration management, beforeattempting to tackle capacity management." �

This content was adapted from Internet.com'sITSMWatch.com Web site. Contributors: Drew Robb,George Spafford, Mike Tainter, Atwell Williams, HankMarquis, Karsten Smet, Andrew Sarnoff, ThomasWimmer and Darreck Lisle.

26 Implementing Service Level Management with ITIL, An Internet.com IT Management eBook. © 2009, Jupitermedia Corp.

Implementing Service Level Management with ITIL[ ]