TECHNOLOGY BRIEF: CHANGE MANAGEMENT

Change Management: A CA ServiceManagement Process Map

Copyright © 2007 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies. This document is for your informational purposes 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 or fitness for a particular purpose, or non-infringement. In no event will CA beliable 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 RegisteredTrademark and a Registered Community Trademark of the Office of Government Commerce, and is Registered in the U.S. Patent and Trademark Office.

Table of Contents

Executive Summary

SECTION 1: CHALLENGE 2Simplifying ITIL

How to Use the CA Service Management ProcessMaps

SECTION 2: OPPORTUNITY 5Change Management

Request for Change

RFC Analysis

Change Prioritization

Categorize

Build and Test Change

Change Advisory Board Review

Implementation

SECTION 3: BENEFITS 10Benefits of Change Management Best Practices

SECTION 4: CONCLUSIONS 10

ABOUT CA Back Cover

TECHNOLOGY BRIEF: CHANGE MANAGEMENT 1

Executive SummaryChallenge

The Information Technology Infrastructure Library (ITIL®) process framework embodiescritical guidance for IT organizations seeking to improve service quality and align moreclosely with business goals. But ITIL can be challenging to interpret. Many organizations arechallenged to apply ITIL effectively to achieve business goals.

CA has developed a unique approach to representing the ITIL framework and itsinterdependent IT Service Management (ITSM) best practice processes at a high level inthe form of easy-to-use Service Support and Service Delivery subway maps. These mapsare an ideal starting point for understanding ITIL and communicating these processesacross your IT organization in support of successful program planning and implementation.

Opportunity

If Incident and Problem Management represent the “heart” of Service Support, thenChange Management is the process that controls the “heart rate.” Optimized ChangeManagement results in fewer incidents and problems, and helps ensure that strategicimprovement requests are quickly processed and implemented.

In today’s fast-moving markets, the ability to easily and appropriately handle change is evenmore important. That is why IT organizations need to implement and automate bestpractices for the entire, end-to-end change management lifecycle. Only IT organizationsthat embrace this disciplined approach to change management will be able to deliver theoperational agility essential for service excellence.

Benefits

• Faster, more predictable change implementation

• Reduce risk to the business of implementing new technologies

• Improve IT agility even in the face of changing business needs and competitive pressures

• Increase visibility into the change process

• Improve service levels, including reduced downtime across the IT infrastructure

• Enhance user satisfaction

Simplifying ITILThe Information Technology Infrastructure Library (ITIL®) process framework embodies criticalguidance for IT organizations seeking to improve service quality and align more closely withbusiness goals.

But the ITIL best practice guidelines are complex and challenging to understand and interpret.Moreover, they are not designed to provide definitive advice about implementing IT ServiceManagement (ITSM) processes. Many IT organizations consequently undertake an ITILjourney without a firm idea of their goals and the path to achieve those goals.

CA has developed a unique approach to charting the ITIL journey through a visualrepresentation of the ITIL framework and its interdependent ITSM processes in the form of asubway map. This two-part map presents an easy-to-navigate, high-level view of the ITILterrain. IT executives, strategists and implementers can use these ITSM process maps—alongwith the family of CA Service Management Process Map technology briefs that expand onthem—as a common reference point for understanding and communicating about ITIL; as wellas to support successful program planning and implementation.

How to Use the CA Service Management Process MapsCA’s Service Management Process Maps apply the analogy of subway system maps toillustrate how best to navigate a journey of continuous IT service improvement. Each mapdescribes the relevant ITIL processes (tracks), the ITIL process activities (stations) that you’llneed to navigate to achieve ITIL process goals (your destination), and the integration points(junctions) that you need to consider for process optimization.

CA has developed two maps, Service Support and Service Delivery, since most ITSMdiscussions focus on these two critical ITIL disciplines.

SECTION 1: CHALLENGE

2 TECHNOLOGY BRIEF: CHANGE MANAGEMENT

CA’s ITIL Process Mapsillustrate at a high level howbest to navigate a journeyof continuous IT serviceimprovement. Each mapdescribes the relevant ITILprocesses and activities you’llneed to work with to reachyour goals.

The Service Support map (Figure A) represents a journey of improving day-to-day IT servicesupport processes that lay the operational foundation needed upon which to build business value.

THE CA SERVICE SUPPORT SUBWAY MAP

The Service Delivery journey (Figure B) is more transformational in nature and shows theprocesses that are needed to deliver quality IT services.

THE CA SERVICE DELIVERY SUBWAY MAP

TECHNOLOGY BRIEF: CHANGE MANAGEMENT 3

FIGURE A

Service Support Subway Map.

FIGURE B

Service Delivery Subway Map.

SECTION 2: OPPORTUNITY

Both maps represent the major ITIL processes as the “stations” en route to an organizationalprocess “destination” or goal. The ITIL process stations are served by “tracks,” which arepositioned relative to one another to illustrate how they support the goal of continuousimprovement. The ITIL continuous improvement cycle takes the form of a “circle” or “centralline,” with each Plan-Do-Check-Act (P-D-C-A) step as a process integration point or “junction”on the line. Junctions serve both as reference points when assessing process maturity, and as ameans to consider the impli-cations of implementing a process in isolation.

This paper is part of a series of Service Management Process Map technology briefs. Each briefexplains how to navigate a particular ITIL process journey, reviewing each process activity thatmust be addressed in order to achieve process objectives. Along each journey careful attentionis paid to how technology plays a critical role in both integrating ITIL processes and automatingITIL process activities.

Change ManagementChange is an intrinsic aspect of every business—especially healthy businesses that innovateand readily adapt to shifts in the market. For a business to remain healthy, its IT organizationmust be capable of effectively and efficiently handling change. It must be able to executechange with minimal cost and minimal risk of business disruption. IT must also be able to keepits infrastructure and services well-aligned with changing business goals and priorities.

In today’s fast-moving markets, the ability to easily and appropriately handle change is evenmore important. That is why IT organizations need to implement and automate best practicesfor the entire end-to-end Change Management lifecycle, from “Plan” through “Do” (see FigureC). Only IT organizations that embrace this disciplined approach to change management willbe able to deliver the operational agility essential for service excellence.

If Incident and Problem Management represent the “heart” of Service Support, then ChangeManagement is the process that controls the “heart rate.” Optimized Change Managementresults in fewer incidents and problems, and helps ensure that strategic improvement requestsare quickly processed and implemented. For this reason, Change Management process mustbe well documented, especially during categorization activities, since decisions made here willaffect how financial and other resources will be allocated.

4 TECHNOLOGY BRIEF: CHANGE MANAGEMENT

THE CHANGE MANAGEMENT PROCESS

Let’s review the Change Management process journey illustrated in Figure C, assessing eachcritical process activity (or station), and examining how technology can be applied to optimizeevery stage of the journey. Note that, while technology can greatly enable the automation ofthe Change Management process, it cannot do much to improve the value to the business of aprocess that is functioning poorly.

Request for ChangeThe journey of Change Management starts with a Request for Change (RFC). What is thedifference between a service request and a change? Basically, a service request may involvemaking a change to the environment, but generally that change is operational and doesn’timpact business services. A number of related service requests could generate a change if theyrequire impact analysis or touch the production environment.

A Request for Change (RFC) could be triggered by such activities as a customer request viathe Service Desk, the introduction or removal of a Configuration Item (CI), or the output of adevelopment project. It could also be triggered by Problem Management activities. To prevent asituation where there are too many entry points into the change process, you should documentwho can create RFCs, what those RFCs are intended to do, and what information is required inthem. Technology can help by ensuring that requestors have a simple way of submitting RFCs.The tool should drive them through the important steps and ensure that the correct level ofdetail is captured. It is also important to understand the business importance of the change.

TECHNOLOGY BRIEF: CHANGE MANAGEMENT 5

FIGURE C

Track illustrates the process todetermine required changes, andimplement with minimum adverseimpact.

Remember, the goal of Change Management is to facilitate all change requests by using clearprocedures, automation and simple checks and balances. ITIL suggests that any member of theorganization should be able to submit an RFC. If not managed properly, this could lead to ungateddemand and possible misuse of the Change Management system. A more appropriate approachwould be to use service requests for routine standardized demands that need not be controlledby Change Management, and to use IT or business relationship managers to submit RFCs.

RFC AnalysisThe RFC Analysis phase is intended to perform an initial evaluation of the information providedfor complete-ness and feasibility. An automated system can significantly shorten this phase byallowing the tool to apply business rules to determine what information is required. A keyrequirement for such a system is the ability to ensure that adequate change lead times are inplace, and are in line with policy.

Change PrioritizationAfter performing the initial RFC analysis, the next step is to prioritize the change. This occursby analyzing the impact of the problem and the urgency of the fix (if the change was generatedfrom a problem) or the importance to the organization of whatever the change is implementing.If this can’t be agreed upon, the Change Advisory Board (CAB) may need to intervene. Whenthe change priority is determined, it is used to determine resource requirements and changescheduling windows. In a resource-constrained environment, business units can use it tointernally prioritize demand.

Risk assessment should also be determined at this stage. Measuring risk can be defined as theactual risk associated with implementing the change versus the risk of possible failures ifchanges are not implemented. Both types of risks should be evaluated and cost-analyzed.

Another aspect of determining risk relates to the impact of the change on other components ofthe environment. Today, in a highly shared environment, an individual cannot track all of thetouch points between technology and business services. For example, if a change requires aclustered web server to be rebooted, what business services are affected and what is theimpact on Service Level Agreements (SLAs)? Integration of Change Management withConfiguration Management can help by allowing you to work through “what if” scenarios todetermine the impact of a technology change on business services.

CategorizeThe Categorize station is actually a major hub for a number of activities. Categorizationinvolves evaluating the size of the change from a resource requirements perspective, the riskassociated with the change, as well as the priority, and then deciding what process steps youwill follow. Categorization is an extremely important activity, since it is assigned according tobusiness impact, and therefore determines the level of change authorizations and financial andresource requirements. During this stage, IT must collaborate with the business to ensure thecorrect categorization of changes and to avoid problems further down the line.

6 TECHNOLOGY BRIEF: CHANGE MANAGEMENT

The bulk of Change Management work is done at this station, with many checks and balancesto ensure that change approval becomes relatively straightforward. Here, organizations canrealize the major benefits of Change Management; for example, by utilizing technologies tohelp determine change categories (based on criteria agreed upon with the business), to quicklyabsorb large volumes of changes, and to determine the costs of changes before they areincurred.

For a minor change, a small number of workflow tasks should be completed that, for the mostpart, will involve approvals and implementation scheduling. A minor change is appropriate onlywhere a small amount of effort and risk is involved. Similar categorization can be used forsignificant changes. This is another area where technology can streamline and automate theprocess itself, using business rules to insert the correct process flow into the change and thenreport conformance against the workflow while also providing an audit trail.

Build and Test ChangeThis stage includes building the schedule for provisioning hardware and software andperforming the work needed to put the change together. The change needs to be tested in apre-production environment to make sure that it has every chance of success. Back-out plansand a “go/no-go” decision point must be specified ahead of time. You do not want to leave thatdecision in the hands of the implementers, as this encourages a “hero” culture where peoplewill keep trying to implement a change and make it work. This is a poor practice and generallymeans that the change process didn’t work and that there is a higher risk of the change failingor having undesirable impacts on related IT services.

Change Advisory Board ReviewOnce this work of Categorization has been performed, a decision is made on whether toproceed. This will happen at a Change Advisory Board meeting. The CAB should consist of allthe interested parties for active changes, both from IT and the business. The CAB should meetregularly and utilize formal meeting procedures, including meeting minutes and communication.The CAB should review all proposed and implemented changes (for which this constitutes thePost Implementation Review).

For new changes, there should be agreement on the need, resource allocation and availablefunds. A considerable amount of work may be required after CAB approval, which is why it isimportant to automate as much as possible of what can be complex processes. Minor changesshould be authorized prior to the CAB meetings, which should focus on change requests thathave higher risk and associated costs. Again, this is why the business must be involved fromthe design phase of process development. Everyone needs to understand what is critical tothe business to determine changes that can be pre-approved and those that need to beanalyzed further.

The CAB should also review implemented changes to determine the quality of the process andwhether the changes were implemented correctly. Determining that the technical aspect of thechange was successfully implemented is insufficient. What is required is to determine whetherthe change achieved its purpose.

TECHNOLOGY BRIEF: CHANGE MANAGEMENT 7

More mature organizations will wait for a specified period before “closing” a change. IT shoulddemonstrate its engagement with the customer at the CAB stage by ensuring that businessusers affected by changes are fully involved in the decision making process. The CAB hasresponsibility for approving or rejecting changes. They also should perform the due diligenceand, in instances where there is not enough information, make a decision to send the changeback to the requester. Approval must be gained at three levels: technical, business andfinancial. Since these CAB meetings can require significant time and resources, technology canbe supportive; for example, by giving CAB members electronic access to RFCs for electronicapproval.

Once the CAB approves the change, the “Do” phases of scheduling, building, testing andimplementation begin. The CAB has to be financially responsible and strike a balance betweenmanaging risk and controlling costs.

Once all approvals are given, it is appropriate to schedule the change. More activities need tohappen before a change window can be selected. In cases of major releases, an organizationmay be restricted to certain maintenance windows and should put a place holder in the ForwardSchedule of Changes (FSC) calendar. These key activities are best controlled by using bestpractice project management. This is one of the key steps in increasing the value of ChangeManagement and taking advantage of the proactive potential.

The key stakeholders should work out scheduling to ensure that all the implementation stepsrequired to institute the change are achievable. Automated technology helps keep everyoneinformed of what needs to be done and when it is needed.

Providing visibility into when changes are to be imple-mented is critical. In this schedulingphase, the FSC should be updated. This should take the form of a generally available calendarview indicating when you’ve scheduled all change windows. Within each window it shouldclearly state any (business) services or technologies that will be impacted, along with the startand end time of the implementation.

The FSC is important for a number of reasons. First, it allows changes to be implementedtogether where there is an opportunity to do so (for example where there is commoninfrastructure being affected). Secondly, it provides the ability to quickly spot change conflictsor situations where the time of the planned change could have a detrimental affect on thebusiness. For example, if the business is running a sales campaign it would be inconvenient ifcertain Web services were unavailable during that time. Thirdly, the FSC makes the ServiceDesk aware of planned change and service outages so they can place an advance notice on thebulletin board and are prepared to answer the influx of calls. Otherwise, the Service Desk mightwaste time trying to diagnose the increase in incidents caused by the service outage orimplemented change.

8 TECHNOLOGY BRIEF: CHANGE MANAGEMENT

ImplementationThe implementation station is the next step. Only the changes that are approved andscheduled in the change window can be implemented. This is not an opportunity for people tointroduce unauthorized changes. The entire premise of the Change Management process is toprotect the production environment; unauthorized changes put this objective at risk. An outputat this stage will be an implementation report that will be reviewed at the next CAB meetingto ensure that the business goals were met and the risks and costs to the business wereminimized.

Including business stakeholders in the implementation process allows for continuousimprovement because you are constantly engaged to ensure the change process is aligned withbusiness goals. If they are not, you may not meet the business objectives and thus be forced torefine your process to make the necessary changes.

EMERGENCY CHANGES All the discussion above has been in the context of a well-plannedprocess where forewarning is embedded into the change process. In a dynamic operationalenvironment there will often be times when high-impact incidents and problems need to havefixes applied that will involve a change to the production environment. This is not an opportunityto bypass the change process as there should also be a process in place to handle urgent oremergency changes. Change approval is still a prerequisite in these cases, but the standardprocess will generally be condensed and some of the CAB approvals will be delegated.

Organizations that have not fully developed their Change Management processes will see ahigh volume of emergency changes, most likely because of timing. This is normally due to leadtimes not being enforced, with changes continuously and mistakenly viewed as emergencies. Agood metric to gauge whether a change is an emergency is to determine if there is a highimpact incident or problem open that this change will fix. If this is not the case, then you mustquestion whether it’s an emergency change.

The last step is to review the Change Management process as an entire unit. ChangeManagement is an iterative process that requires constant review and adjustment forcontinuous improvement. This is why the process owner should constantly be reviewingchanges to look for ways to make the process better and to consult with the business often toensure their needs are being met.

Benefits of Change Management Best PracticesThe benefits of implementing a Change Management process in line with ITIL best practicesinclude:

• Faster, more predictable change implementation

• Reduce risk to the business of implementing new technologies

• Improve IT agility even in the face of changing business needs and competitive pressures

• Increase visibility into the change process

• Improve service levels, including reduced downtime across the IT infrastructure

• Enhance user satisfaction

TECHNOLOGY BRIEF: CHANGE MANAGEMENT 9

Including businessstakeholders in the changeimplementation processsupports continuous improve-ment by ensuring thatchanges are aligned withbusiness goals.

SECTION 3: BENEFITS

In simple terms, the underlying goal of Change Management is to protect the business,because any time you touch the production environment you put the business at risk. Failedchanges are better than changes that are successfully implemented and cause failures later—but both are problematic. It is not sufficient to just have a good Change Management process.Compliance with agreed-upon procedures is also required to make sure things are done as theyshould be and a full audit trail of everything that has been done is easily accessible. To do thisprocess manually in a complex environment is very difficult and prone to human errors and/orencouraging people bypass the system.

To raise the level of maturity where business impact and risk assessment is performed requiresintegration with Configuration Management. Configuration Management will provide ChangeManagement with a baseline, priority and urgency of changes and detailed information on thehistory and relationships among CIs. This is necessary in order to effect a complete impactassessment of changes made.

Integrated technology and process automation solutions can significantly ease the overhead ofmanaging the change process, while also ensuring process compliance. Some potential ways toautomate Change Management include:

• Embed a change process in the solution based on the change category. Analysts can thenselect the appropriate workflow template to automatically assign individual tasks to theappropriate resource in the change process.

• Assist the CAB by providing information to the relevant people electronically so they do notactually need to come together to discuss changes unless there is a specific reason for doing so.

• Ensure conformance to the process by not allowing the change to progress unless theprerequisite tasks have been completed and a record is made of who completed themand when.

• Perform business impact analysis through Configuration Management to determine whatbusiness services are impacted by changes to the infrastructure. Often, without this link toConfiguration Management it is nearly impossible to determine all the impacts that a singlechange can cause since there is no relationship information associated with theinfrastructure.

• Unify change processes across both IT operations and software development.

• Allow the Change Management process to be a business enabler where the repeatableprocess is constantly used without the requestor having to try and work out what needs tobe done.

• Offer Service Levels for Change Management and use business rules to proactively monitorservice and raise visibility automatically when a violation occurs.

• Engage with the customers and make them part of the Change Management process, usingfacilities such as portfolio management to prioritize strategic change requests.

To learn more about the CA ITIL solutions, visit ca.com/itil.

SECTION 4: CONCLUSIONS

10 TECHNOLOGY BRIEF: CHANGE MANAGEMENT

CA, one of the world’s largest information technology (IT)management software companies, unifies and simplifiescomplex IT management across the enterprise for greaterbusiness results. With our Enterprise IT Management vision,solutions and expertise, we help customers effectivelygovern, manage and secure IT.

TB05CHNG01E MP316960907

Learn more about how CA can help you transform your business at ca.com