ITIL Change Management

ITIL Change Management

Change Management’s purpose is to control the process of implementing changes to the environment. Several organizations have change review meetings or change control. Commonly they are a stop gap measure of finally approval of introducing a change. Let’s talk a little bit on how to improve or “ITILize” the process.

First, let’s clearly distinguish the difference between change request and service requests. A change requests typically affect many individuals. (If you don’t have a change process these may be unplanned and significant changes of your environment’s configuration.) Service requests are routine procedures that affect a small number of users. This type of request is normally a minor change to a system. For example, helping a new employee gain access to the systems needed.

Change Management consists of five steps.

§  Filtering Requests for Change (RFCs) – To be frank, requests for changes need to be reviewed by the management team. Some requests simply are not practical or feasible. Some requests may be a duplication of efforts. So the first step of change management, is to review the requested changes and assure only practical realistic changes are setup to be given focus by the IT resources.

§  Assessing the impact of changes – After you have the list of requested changes, they should be assessed and rated on the benefits to the company, preferably based on the business strategy of the organization. For example, in a hospital the popular pillars model is: service, people, quality, financial, and growth. Rank the change against the strategy, and then to give a full overview also assess impact, cost, and benefits of each change. Together with the customer, prioritize all change requests.

§  Authorizing changes – Since the business customers are engaged in the process, use their expertise in evaluating the impact of the changes. This Change Advisory Board (CAB) should offer insights to the change manager before the changes are approved and scheduled. A forward schedule of changes should now come into existence.

§  Reviewing Changes – After the changes have been made and implemented, a honest and open review will point out those things done very well and not so well. These lessons can be brough into the change management process for immediate improvement.

§  Closing RFC – Finally the customer who has submitted the RFC should have the opportunity to review and accept the results of the change. After the user has accepted the change, the Request for Change (RFC) should be closed.

According to the ITIL doctrine, performing changes is not included in a list of change management steps because it isn't part of the change management process. Change management team members don't typically execute the changes they plan and review.

Change management produces certain results which enable members of other IT service management teams to execute changes. The outputs from the change management process are:

§  Forward schedule of changes (FSC) – A forward schedule of changes is a listing of upcoming changes which are be scheduled and communicated to other IT service management processes and to the rest of the company. The forward schedule of changes shows the changes that have been approved and given a date for implementation.

§  Updated Requests For Changes – Request for Changes are updated with approvals and forward to release management. ITIL release management is the process responsible for implementing the changes.

§  Change advisory board decisions - The discussions of the change advisory board provide the basis for the change manager's decisions to approve or reject proposed changes. The members of the CAB help determine if changes make sense from technical, financial, and business viewpoints.

§  Change management reports - Change management reports allow managers to evaluate the effectiveness of the process in the past and its direction in the future. These reports should be distributed to senior IT and business managers.

Obviously proposed changes have far-reaching affects within an organization, this is why a group with a strategic borderless cross sections of the community should help evaluate proposed changes. A change advisory board advises the change manager before changes are approved and scheduled.

The major activities of the change management process include:

1.     Logging and filtering - The first major activity is logging and filtering change requests. Obviously change requests will come from anywhere within a company that has an idea and a computer. Some changes result from an incident in which IT services are interrupted or configuration items fail to work properly. Other requests may simply ask for improved or additional service. Some requests maybe capital changes or departmental system modifications. However all proposed changes should be submitted to change management in a standardized request for change (RFC) document. When an RFC is received, change management logs the request and allocates a unique identification number for the document. An RFC document provides definitive information about the change that's being requested.

2.     Assessing and classifying - The process for assigning priorities to changes is similar to the process for prioritizing problems. If a problem receives a high priority, the change that corrects the problem will have a high priority. However, not all changes address problems. For example all enhancement requests, so changes need to be classified based upon priority. Commonly ratings such as emergency, high, medium or low are used.

3.     Approving - The authority to approve or reject proposed changes is what gives change management the ability to make the change process more effective. The final decision and authority to act is with the manager in charge of change management. Obviously with something this significant the change manager doesn’t act in a silo, the change manager consults with his trusted advisors the change advisory board. The CAB examines each proposed change from three perspectives: financial, technical, and business. The board evaluates changes from a financial perspective to determine whether the benefits of each change justify the costs of completing it. Evaluation from a technical perspective assures that each change is feasible and will not have a negative effect on the infrastructure. Business evaluation ensures that changes support the company's business objectives.

4.     Planning and coordination - Change management doesn't actually implement the requested changes. However, change management team members help plan the implementation and then monitor the progress of changes to be sure the plans are being carried out. In an ideal world, change management could allow only one change at a time. Because configuration items in an infrastructure affect one another, that's not possible. A hardware change may require an accompanying software change, and both of those may require changes in documentation and procedures. Change management and the change advisory board examine how changes will affect the IT infrastructure. Changes are scheduled to accommodate the dependencies among changes to different configuration items. After a change has been scheduled, change management forwards the approved RFC to the support team that will build and test the change. The team chosen to actually build and test a change depends on the type of change. The team must include people with the skills needed for specific building and testing tasks.

5.     Reviewing and closing - Completed changes may be reviewed in CAB meetings. The examination of a completed change is called a post-implementation review (PIR). The purpose of a post-implementation review is to study recently completed changes and apply the experience gained to subsequent changes. Post-implementation reviews allow change management to learn from the past and continually improve the change management process.

As with all processes, an exception or emergency guideline needs to exist. When a problem interrupts service to many users or will have an immediate and severe business impact, an emergency change is needed. Change management uses a slightly different process to handle emergency changes. The emergency change process allows more flexibility in dealing with failed attempts to implement changes. In the standard change process, failed changes are backed out, and the previous status is restored until a new change can be planned. In an emergency, however, change management may allow repeated attempts to make a successful change if the initial attempts fail. In an emergency, restoring service is the main and only priority.

The one person who is most responsible and accountable for change management is the change manager. The change manager is more of a role, depending on the size, complexity and structure of your IT organization, there may be more than one person playing the role of change manager for assisting with several activities. The change manager plays a leading role in many of the major activities of change management as follows:

§  Receives and filters requests for change (RFCs) - There must be a single point of collection for RFCs. The change manager reviews new RFCs and filters out those that are impractical or duplicates of existing requests. The change manager serves as the gatekeeper to the activities of the change management process.

§  Coordinates the activities of the change advisory board (CAB) - The change manager serves as leader and facilitator for the change advisory board and its emergency committee. The change manager convenes the CAB and makes sure a cross section of departments within the company is represented.

§  Issues and maintains the forward schedule of changes (FSC) - The change manager is the keeper of the FSC. When the change advisory board approves changes, the change manager adds the change to the FSC and distributes it within the company.

§  Closes RFCs - The authority to declare a change complete and closed should be limited to the change manager. A change should be removed from open status only when it has been verified that the change has been successfully implemented and accepted by affected users.

Having an effective change manager is one requirement for the success of change management. There are several other critical factors that need to be present for the implementation of change management to be successful.

Change management isn't an isolated process. Its success depends on how well it meshes with the rest of the IT department and the company. Three factors that are critical to the success of change management are:

§  Appropriate tools —An integrated service management tool shares information among all the IT service management (ITSM) processes. Information sharing provides the ability to seamlessly handle change requests and related incidents, problems, and errors.

§  Supporting processes —Change management will be far more effective if it's supported with the implementation of related processes. It should be implemented along with configuration management and release management.

§  Management commitment —Without support from senior managers, change management cannot succeed. Change management may introduce significant changes in a company. Management commitment gives change management authority to direct the change process.

The successful implementation of change management increases the value of a company's information resources. Change management succeeds when the change manager performs key duties and the environment for success exists.

Most companies that implement change management encounter some problems and costs in the early going.

Some of the lessons learned that can be shared from other having gone there before are:

§  One common problems encountered is a continuing reliance on the previous methods of managing changes. Whether the previous system was highly structured or very informal, many employees will cling to a familiar but less effective system. As is always the case with change, communication and seeing the vision helps to bring everyone to the same page as to the value of the new system.

§  Another common problem is the unwillingness of some members of an organization to relinquish control of changes to a centralized process. Managers who were able to enact changes independently may be reluctant to cooperate with change management at first. A common trait to resolve this problem is to show everyone the value, perhaps explain we just need to look with a broader perspective. We don’t want to release the new flag ship product on the week with the network switch OS upgrade and Microsoft Patch releases.

§  Clinging to previous systems and a reluctance to give up independent control may combine to create another common problem: attempts to bypass change management. Some members of a company may resist the structured process of change management and attempt to bypass it entirely.

Companies implementing or improving change management should also expect to incur some costs associated with change management. These costs may be shared among several IT service management processes and not allocated entirely to change management. The major categories of costs are:

§  Personnel costs - A change manager is needed to develop and direct the process. More members of the change management team may be added. Members of the change advisory board must devote time to approving and reviewing changes.

§  Software costs -An automated IT service management tool should be purchased or developed internally. This tool provides better control of requested and pending changes and facilitates communication among different IT service management process teams.

§  Hardware costs - Some additional hardware may be needed to support the software tool. Workstations may be purchased for change management team members. In some cases, more data storage capacity may be required as well. This is usually a minor cost.

ITIL Problem Management

Problem Management is structured to address the causes of incidents which pose the greatest risk. (Negative risk) Therefore it focuses on the heavy hitter recurring service affecting events; it doesn’t find the root cause or permanent fix for every incident. Success is measured in terms of what has been removed from the environment.

§  How many problems are identified and removed from our IT environment.

§  Problems which have a status of resolved and closed.

So let’s walk the process, for problem management.

First an incident occurs. An incident is any unplanned outcome from the operation of an information system. Incidents interrupt the IT service which the customer receives. Incidents are normally reported to the service desk, and an incident record is created.

Next, the incident is assessed. If the cause of the incident isn’t know, then the incident is escalated to a problem. A problem is an incident whose cause is not known.

As the problem is reviewed, the cause of the problem and a workaround maybe determined. As soon as these two aspects occur, the problem is changed to a known error.

Finally the known error is assessed to determine if the symptoms of the incident match an already existing problem record. If so, the new incident is cross-referenced to that problem

However if the known error doesn’t match any existing symptoms, a net new problem record is created.

The terminology incident, problem, and known error portray the effect and root causes of unexpected events in an information system. Identifying the cause of these events and minimizing their impact is the primary purpose of the problem management process.

The goal of problem management activities is to ascertain the root causes of incidents and to minimize their impact on the business operations of a company. This is done through the following processes:

§  Problem control - The purpose of problem control is to identify problems within an IT environment and to record information about those problems. Problem control identifies the configuration items at the root of a problem and provides the service desk with information on workarounds.

§  Error control - The purpose of error control is to keeps track of known errors and to determines the resource effort needed to resolve the known error. Error control monitors and removes known errors when it's feasible and worthwhile.

§  Proactive problem management - The purpose of proactive problem management is to find potential problems and errors in an IT infrastructure before they cause incidents. Stopping incidents before they occur provides improved service to users.

The primary measure of the success of the problem management process is how many problems are identified and removed from an IT infrastructure. Therefore, the primary output from this IT service management process renders problems that are resolved and closed.

The work of problem management produces the following outcomes:

§  Records of known errors and available workarounds - These records are kept in the configuration management database (CMDB), and they provide information to the service desk and other ITSM processes.

§  Requests for change (RFCs) - RFCs describe changes needed to remove a known error. Problem management does not approve or perform the change. RFCs are sent to another ITSM process, change management.

§  Changed records in the CMDB - Information about a known error and any affected CIs is forwarded to the configuration management process, the IT service management process that maintains the CMDB.

When the problem management process is used to identify the root causes of problems, it's far more likely that they will be diagnosed correctly and fixed properly. As a result, problems are permanently eliminated.

Problem management includes the following two types of approaches to address problems:

§  Reactive problem management - Reactive problem management seeks to cure the symptoms of problems. The reactive approach responds to reports of incidents that have already occurred. Reactive problem management can be viewed as two activities

§  Problem control activities - The major problem control activities are:

§  Identification and recording - Problem management receives information about reported incidents from the incident management process and the service desk. Members of the problem management team analyze this information, looking for similarities in the symptoms of reported incidents. They look for records of previously identified problems that can explain the symptoms. If none can be found, a record describing a new problem is created.

§  Classification - This control activity identifies the importance of new problems and designates resources for addressing them.

Problems are classified by category, such as hardware, software, or other types. Then they can be assigned to the corresponding support personnel. Problems are also classified by priority ranking. Problems with higher priority rankings are addressed before problems with lower priority rankings.

Investigation and diagnosis - Problem management teams look for the root cause of problems. If the cause is determined, problem management recommends a workaround or a temporary fix for the problem.

§  Identify cause of problem and devise a workaround - In the automated service management system, the status of the problem is changed to that of a known error.

When an IT department applies problem control activities, it prioritizes the problems that present the biggest threat to the information system or the company's ability to conduct business. When the root cause of a problem has been found and a workaround has been devised, problem control activities end. Then the second group of activities in reactive problem management begins.

§  Error control activities- Now the problem becomes a known error in the IT infrastructure, and error control activities begin. Error control activities include:

§  Error identification and recording - This means creating a record that identifies a known error and all the configuration items (CIs) that cause the error or are affected by it.

§  Error assessment - This activity prioritizes errors and places them into groups according to their importance.

§  Error resolution recording - The resolution to a known error may include changes to hardware or software, user training, or operational procedures. Error control creates a request for change (RFC) and forwards it to change management. The RFC is cross-referenced to the known error in the automated service management system.

§  Error resolution monitoring - Changes are planned and implemented by other IT service management processes. Problem management monitors the effect of problems on service provided to users and the progress of requested changes until they're complete.

§  Error closure —The final error control activity is error closure. When recommended changes to fix a known error have been completed, the known error record in the service management system can be closed. Records of incidents and problems associated with that known error may also be closed.

§  Proactive problem management - Proactive problem management seeks to inoculate IT systems against problems. The proactive approach identifies potential problems before they emerge.

§  Trend analysis - This is the process of examining problem and incident reports to discover what types of problems are happening more frequently. Trend analysis of existing problems and incidents can reveal where similar problems may occur in other places within the infrastructure. It can also show that repeated failures have not been adequately resolved and are likely to continue to happen.

§  Targeting preventative action - This process applies the same techniques used in reactive problem management to a select few potential problems with a high degree of business impact. Targeting preventative action may include creating RFCs, training users and service desk team members, or recommending procedural changes within the IT department.

The groups of problem management activities; (problem control, error control, and proactive problem management) identify and resolve problems which have the greatest potential impact on a company's business.

The success of problem management depends on having the right people performing the right actions. Responsibility for leading the problem management process is assigned to one person designated as the problem manager. The roles of the problem manager are:

1.     To maintain and develop problem control activities - It's the problem manager's job to make sure that information about incidents within the system is being received and reviewed in a systematic way.

2.     To monitor the effectiveness of error control activities and make recommendations for improvement - She must also ensure that relationships among configuration items are considered in proposed solutions to problems.

3.     To cascade information about workarounds or fixes to those who need it - Communication with the service desk and incident management is a key role performed by the problem manager.

4.     To monitor the progress of problems and known errors toward a final resolution - If solutions aren't implemented as quickly as necessary, the problem manager may follow procedures to escalate the priority of the problem.

Each of these four roles contributes to the ability of problem management to identify and resolve problems and known errors quickly. The problem manager will also perform typical supervisory roles to direct the activities of any other problem management team members.

The problem manager's duties should never be combined with the duties of the service desk supervisor. The priorities of the service desk and problem management are often incompatible.

The success of problem management also relies on critical factors before, during, and after the main activities in the problem management process. The critical factors for success are:

§  Performance targets - It's important to decide how the performance of problem management will be measured before the process is implemented. If possible, use statistics from the previous support activities to set goals for problem management.

§  Periodic audits - Perform periodic audits to determine whether problem management procedures are being followed. Problems that aren't properly reported or investigated are more likely to cause interruptions of service to users or a major impact on the business.

§  Problem reviews - Conduct major problem reviews after problems with high urgency or impact have been resolved. Look for ways to improve the way problems are identified and resolved. Problem management procedures should be continually improved.

Problem management will succeed when an effective problem manager fills the required roles, and critical factors for the success of the process are included in everyday operating procedures.

Implementing problem management brings many benefits to a company and its IT department. However, there are also some problems and costs that arise during the implementation of problem management.

Among the most common problems companies experience is a difficulty establishing adequate communication between problem management and another IT service management process, incident management. Communication between the two can be difficult because they pursue the following conflicting goals:

§  Problem management - The goal of problem management is to investigate the root cause of a problem. The speed with which a solution is found is an important, but secondary, consideration.

§  Incident management - The goal of incident management is to recover from incidents and restore service to users as quickly as possible. Determining the cause of a problem is less important.

Companies also often have difficulty establishing lines of communication between the software development process and problem management. Programmers and developers are frequently aware of known errors in the software they create, but they can be reluctant to identify them.

In many companies, employees resist new procedures. Many companies report that employees cling to previous informal problem management methods. It takes time for employees to accept the discipline of problem management.

Companies should expect to incur some costs with the implementation of problem management. However, it isn't necessary to create a vast problem management process that's capable of handling every single problem that arises. As a result, the incremental costs of problem management are negligible. The hardware and software tools needed are shared with other IT service management processes, and the additional personnel costs are small.

Problems and costs arise frequently during the introduction of problem management. However, the problems and costs are manageable and bring worthwhile improvements in the performance of the IT infrastructure.

Problem management seeks to identify the underlying causes of incidents in an IT infrastructure and to remove those causes. The problem management process addresses the causes of incidents reactively and proactively.