White Paper

Change Management:A CA IT Service ManagementProcess MapPeter Doherty — Senior Consultant, Technical Service, CA, Inc.Peter Waterhouse — Director, Business Service Optimization, CA Inc.June 2006

Table of ContentsIntroduction ..........................................................................................................................................................................................................3Change Management ...................................................................................................................................................................................... 4

Request for Change (RFC) ........................................................................................................................................................................5RFC Analysis ................................................................................................................................................................................................5Change Prioritization ..................................................................................................................................................................................5Categorize ....................................................................................................................................................................................................5Change Advisory Board ............................................................................................................................................................................6Change Schedule ........................................................................................................................................................................................6Build & Test Change....................................................................................................................................................................................7Implementation............................................................................................................................................................................................7

Ensuring a Successful Change Management Journey ................................................................................................................................7About the Authors ..............................................................................................................................................................................................8

2

3

IntroductionCA’s IT Service Management (ITSM) Process Maps providea clear representation of the ITIL best practice framework.We use the analogy of subway or underground systemtransport maps to illustrate how best to navigate a journeyof continuous IT service improvement. Each map detailseach ITIL process (track), the ITIL process activities (stations)that must be navigated to achieve ITIL process goals (yourdestination), and the integration points (junctions) thatmust be considered for process optimization.

CA has developed two maps (Service Support — Figure A;and Service Delivery — Figure B), since most ITSMdiscussions are focused around these two critical areas.The Service Support journey represents a journey ofimproving day-to-day IT service support processes thatlay the operational foundation needed upon which to buildbusiness value. The Service Delivery journey is moretransformational in nature and shows the processes thatare needed to deliver quality IT services.

Close examination of the maps shows how a continuousimprovement cycle has become a ‘circle’ or ‘central’ line,with each Plan-Do-Check-Act (P-D-C-A) improvementstep becoming a process integration point or ‘junction’.These junctions serve as reference points when assessingprocess maturity, and as a means to consider the impli-cations of implementing a process in isolation. Each of theITIL processes are shown as ‘tracks’, and are located in aposition most appropriate to how they support the goalof continuous improvement. Notice too, how major ITILprocess activities become the ‘stations’ en-route towardsa process destination or goal.

This paper is part of a series of 10 ITSM Process Mapwhite papers. Each paper discusses how to navigate aparticular ITIL process journey, reviewing each processactivity that must be addressed in order to achieve processobjectives. Along each journey careful attention is given tohow technology plays a critical role in both integrating ITILprocesses and automating ITIL process activities.

Figure A. Service Support.

Figure B. Service Delivery.

Change ManagementChange is an intrinsic aspect of every business —especially healthy businesses that innovate and readilyadapt to shifts in the market. So, for a business to remainhealthy, its IT organization must be capable of effectivelyand efficiently handling change. It must be able toexecute change with minimal cost and minimal risk ofbusiness disruption. IT must also be able to keep itselfwell-aligned with changing business goals and priorities.

In today’s fast-moving markets, this ability to easily andappropriately handle change is even more important.That’s why IT organizations need to implement andautomate best practices for the entire end-to-end changemanagement lifecycle, from “planning” through “doing”(see Figure 1). Only IT organizations that embrace thiskind of disciplined approach to change management willbe able to deliver the operational agility essential forbusiness success.

If Incident and Problem Management represent the“heart” of Service Support, then Change Management isthe process to control the “heart rate”. Optimized ChangeManagement results in fewer incidents and problems, andhelps ensure that strategic improvement requests arequickly processed and implemented. That is why theprocess must be well documented, especially duringcategorization activities, since decisions made here willaffect how resources and costs will be allocated.

Let’s review the Change Management process journey(see Figure 1), assessing each critical process activity (orstation), and examine how technology can be applied tooptimize every stage of the journey. While technology willgreatly enable the automation of the change process, itcannot improve a process that is fundamentally poor.

4

Figure 1. Change Management Process Line.

The journey of Change Management starts with a Requestfor Change (RFC). What is the difference between aservice request and a change? At a basic level, a servicerequest may involve making a change to the environmentbut generally that change is operational and doesn’timpact business services. A number of related servicerequests could generate a change if they require impactanalysis or touch the production environment.

A Request for Change (RFC) could be triggered by suchactivities as a customer request via the Service Desk, theintroduction or removal of a Configuration Item, or theoutput of a development project. It could also be triggeredby Problem Management. To prevent too many entrypoints, the process should document who can createRFC’s, what they are intended to do and what informationis required. Technology can help, ensuring that, requestorsdon’t need to know the entire process and have a simpleway of submitting RFC’s. The tool should drive themthrough the important steps and ensure that the correctlevel of detail is captured. It is also important tounderstand the business importance of the change.

Remember, the goal of Change Management is to facilitateall change requests by using clear procedures, automationand easy checks and balances. ITIL suggests that anymember of the organization should be able to submit anRFC. If not managed properly, this could lead to ungateddemand and possible misuse of the Change Managementsystem. A more appropriate approach would be to useservice requests for routine standardized demands thatneed not be controlled by Change Management, and touse IT or business relationship managers to submit RFCs.

This activity of RFC Analysis is designed to perform aninitial evaluation of the information provided for complete-ness and feasibility. An automated system can significantlyshorten this phase by allowing the tool to apply businessrules to determine what information is required. A keyrequirement is ensuring adequate change lead times arein place, and in-line with policy.

After performing the initial analysis, the next station isprioritizing the change. This occurs by analyzing theimpact of the problem and the urgency of the fix (if thechange was generated from a problem) or the importanceto the organization of what the change is implementing. Ifthis can’t be agreed upon, the Change Advisory Board(CAB) may need to intervene. When the change priority isdetermined it is used to determine resource requirementsand change scheduling windows. In a resource-constrainedenvironment, business units can use it to internallyprioritise demand.

Risk assessment should also be determined at thisstage. Measuring risk can be defined as the actual riskassociated with implementing the change versus the riskof possible failures if changes are not implemented. Bothtypes of risks should be evaluated and costed. Anotherportion of determining risk is based on the impact of thechange on other components of the environment. Today,in a highly shared environment, an individual cannot trackall of the touch points between technology and businessservices. For example, if a change requires a clustered webserver to be rebooted, what business services are affectedand what is the impact on Service Level Agreements?Integration with Configuration Management can help byallowing you to work through “what if” scenarios to determinethe impact of a technology change on business services.

The next station is actually a major hub for a number ofactivities. Categorization involves evaluating the size ofthe change from a resource requirements perspective, therisk associated with the change, as well as the priority,and then deciding on the process steps to be followed.Categorization is an extremely important activity, since itis assigned according to business impact, and thereforedetermines the level of change authorizations andfinancial and resource requirements. During this stage, ITmust collaborate with the business to ensure the correctcategorization of changes and avoid problems furtherdown the line.

The bulk of Change Management work is done at thisstation, with many checks and balances to ensure thatchange approval becomes relatively straightforward. Here,organizations can realize the major benefits of ChangeManagement, for example, by utilizing technologies tohelp determine change categories (based on criteria

5

REQUEST FORCHANGE (RFC)

RFC ANALYSIS

CHANGEPRIORITIZATION

CATEGORIZE

example, by giving CAB members electronic access toRFCs for electronic approval.

Once the CAB approves the change, the “doing” phases ofscheduling, building, testing and implementation begin.The CAB has to be financially responsible and strike abalance between managing risk and controlling costs.

Once all approvals are given, it is now appropriate toschedule the change. More activities need to happenbefore a change window can be selected. In cases of majorreleases, an organization may be restricted to certainmaintenance windows and needs to have a place holderin the Forward Schedule of Changes (FSC) calendar. Thesekey activities are best controlled by using best practiceproject management. This is one of the key steps in increas-ing the value and taking advantage of the proactive natureof Change Management.

Scheduling should be worked out with the key stake-holders to ensure that all the implementation stepsrequired to institute the change are achievable. Automatedtechnology helps keep everyone informed of what needsto be done and when it is needed.

Providing visibility into when changes are to be imple-mented is critical. In this scheduling phase, a ForwardSchedule of Change (FSC) should be updated. This shouldbe a generally available calendar view of when all changewindows are scheduled. It should be clearly stated withineach window any (business) services or technologiesthat will be impacted, along with the start and end timeof the implementation. This is important for a number ofreasons. First, it allows changes to be implementedtogether where there is an opportunity to do so (forexample where there is common infrastructure beingaffected). Secondly, it provides the ability to quickly spotchange conflicts or situations where the time of theplanned change could have a detrimental affect on thebusiness (for example, if the business is running a salescampaign it would be inconvenient if certain Web serviceswere unavailable during that time). And third, it makesthe Service Desk aware of planned change and serviceoutages so they can place an advance notice on thebulletin board and are prepared to answer the influx ofcalls. Otherwise, the Service Desk will waste time tryingto diagnose the increase in incidents caused by theservice outage or implemented change.

agreed with the business), quickly absorb large volumesof changes, and cost changes before they are incurred. Fora minor change, a small number of workflow tasks shouldbe completed and, for the most part, these will involveapprovals and implementation scheduling. A minorchange is appropriate only where a small effort and riskinvolved. Similar categorization can be used for significantchanges. This is another area where technology canstreamline and automate the process itself, using businessrules to insert the correct process flow into the changeand then report conformance against the workflow whilealso providing an audit trail.

Once this work has been performed, a decision is madeon whether to proceed. This will happen at the ChangeAdvisory Board (CAB) meeting. The CAB should consistof all the interested parties for active changes, both fromIT and the business. The CAB should meet regularly andinvolve a formal meeting including meeting minutes andcommunication. The CAB should review all proposed andimplemented changes (this is the Post ImplementationReview). For new changes, there should be agreement onthe need, resource allocation and available funds. A lotof work is required after CAB approval, which is why it isimportant to automate what can be complex processes.Minor changes should be authorized prior to the CABmeetings, which should focus on change requests thathave higher risk and associated costs. Again, this is whythe business must be involved from the design phase ofprocess development. Everyone needs to understand whatis critical to the business to determine changes that canbe pre-approved and those that need to be analyzedfurther. The CAB should also review implemented changesto determine the quality of the process and whether thechanges were implemented correctly. Determining thatthe technical aspect of the change was successfullyimplemented is insufficient. What’s required isdetermining whether change achieved its purpose.

More mature organizations will wait for a specified periodbefore closing off the change. IT should demonstrate itsengagement with the customer at the CAB stage byensuring that business customers affected by changes arefully involved in the decision making process. The CAB hasresponsibility for approving or rejecting changes. Theyalso should perform the due diligence and, in instanceswhere there is not enough information, make a decision tosend the change back to the requester. Approval must begained at three levels: technical, business and financial.Since these CAB meetings can require significant time andresources, technology can be effectively utilized, for

6

CHANGE ADVISORYBOARD

CHANGESCHEDULE

This stage includes provisioning hardware and software andperforming the work needed to put the change together.The change needs to be tested in a pre-productionenvironment to make sure that it is given every chance ofsuccess. Back out plans and a “go/no-go” decision pointmust be specified ahead of time. You do not want to leavethat decision in the hands of the implementers as thisencourages a “hero” culture where people will keep tryingto implement a change and make it work. This is a poorpractice as it generally means that the change processdidn’t work and there is a higher risk of the change failingor having undesirable impacts on its related IT services.

The implementation station is the next step. Only thechanges that are approved and scheduled in the changewindow can be implemented. This is not an opportunityfor people to introduce unauthorized changes. The entirepremise of the Change Management process is to protectthe production environment; unauthorised changes putthis objective at risk. An output at this stage will be animplementation report that will be reviewed at the nextCAB meeting to ensure that the business goals were metand the risks and costs to the business were minimized.

Including the business in this process allows for continuousimprovement because you are constantly engaged toensure the change process is aligned with the businessgoals. If they are not, you may not meet the businessobjectives and be forced to refine your process to makethe necessary changes. All the discussion above has been inthe context of a well planned process where forewarning isimbedded into the change process. In a dynamic operationalenvironment there will often be times when high-impactincidents and problems need to have fixes applied that willinvolve a change to the production environment. This isnot an opportunity to bypass the change process as thereshould also be a process in place to handle urgent oremergency changes. Change approval is still a prerequisitein these cases, but the standard process will generally becondensed and some of the CAB approvals will bedelegated.

Organizations that have not fully developed theirChange Management processes will see a high volume ofemergency changes, most likely because of timing. This isnormally due to lead times not being enforced, with changescontinuously and mistakenly viewed as emergencies. A

good metric to gauge whether a change is an emergency isto determine if there is a high impact incident or problemopen that this change will fix. If this is not the case, thenyou must question whether it’s an emergency change.

The last step is to review the Change Managementprocess as an entire unit. Change Management is aniterative process that requires constant review andadjustment for continuous improvement. This is why theprocess owner should constantly be reviewing changes tolook for ways to make the process better and to consultwith the business often to ensure their needs are being met.

Ensuring a Successful ChangeManagement JourneyIn simple terms, the underlying goal of ChangeManagement is to protect the business, because any timewe touch the production environment we put the businessat risk. Failed changes are better than changes that aresuccessfully implemented and cause failures later. Butboth are bad! It is not good enough to just have a goodChange Management process. Compliance is also requiredto make sure things are done as they should be and a fullaudit trail of everything that was done is easily accessible.To do this process manually in a complex environment isvery difficult and prone to human errors or having peoplebypass the system.

To raise the level of maturity where business impact andrisk assessment is performed requires integration withConfiguration Management. Configuration Managementwill provide Change Management with a baseline, priorityand urgency of changes and detailed information on thehistory and relationships of Configuration Items (CI).This is necessary in order to effect a complete impactassessment of changes made.

Integrated technology and process automation solutionscan significantly ease the overhead of managing theprocess through automation and ensuring processcompliance. Some ways include:

• Embed a change process in the solution based onthe change category. Analysts can then select theappropriate workflow template to automatically assignindividual tasks to the appropriate resource in thechange process.

• Assist the CAB by providing information to the relevantpeople electronically so they do not actually need tocome together to discuss changes unless there is aspecific reason.

7

BUILD & TESTCHANGE

IMPLEMENTATION

• Ensure conformance to the process by not allowing thechange to progress unless the prerequisite tasks havebeen completed and a record is made of who completedthem and when.

• Perform business impact analysis through ConfigurationManagement to determine what business services areimpacted by changes to the infrastructure. Often, withoutthis link to Configuration Management it is nearlyimpossible to determine all the impact points that asingle change can cause since there is no relationshipinformation in the infrastructure.

• Unify change processes across both IT operations andsoftware development,

• Allow the Change Management process to be a businessenabler where the repeatable process is constantly usedwithout the requestor having to try and work out whatneeds to be done.

• Service Levels can be offered for Change Managementand business rules can be used to proactively monitorthese and raise visibility automatically when a violationoccurs.

• Engage with the customers and make them part of theChange Management process, using facilities such asportfolio management to prioritize strategic changerequests.

About the AuthorsPeter Doherty is a Senior Consultant with CA. He is a15 year Service Management practitioner and holds aManager’s Certificate in IT Service Management. A highlysought speaker for IT Service Management seminars andconferences, he won the President’s Award for bestcontent and presented paper at the 2004 AustralianitSMF National conference. Peter has published on thesubject of IT Asset Management as an extension of ITILand is a regular contributor to industry publications.

Peter Waterhouse is Director of Product Marketing in CA’sBusiness Service Optimization business unit. Peter has 15years experience in Enterprise Systems Management, withspecialization in IT Service Management, IT Governanceand best practices.

Copyright © 2006 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies. This document is for your informationalpurposes only. To the extent permitted by applicable law, CA provides this document “As Is” without warranty of any kind, including, without limitation, any implied warranties of merchantability orfitness for a particular purpose, or non-infringement. In no event will CA be liable for any loss or damage, direct or indirect, from the use of this document including, without limitation, lost profits,business interruption, goodwill or lost data, even if CA is expressly advised of such damages. ITIL® is a registered trademark and a registered community trademark of the UK Office of Governmentand Commerce (OGC) and is registered in the U.S. Patent and Trademark Office. MP302640606