The Essential 7 R’s for Success: Change Request

Part of the ITIL Service Transition Stage of the ITIL Service Lifecycle  includes the change management process. Furthermore, the ITIL certification exam features the ITIL Change management process heavily within the exam itself. Most online ITIL training courses highlight seven important questions beginning with words starting with the letter R in the IT change management process, making the process easier for exam takers to remember.

The Seven Rs of Change Request

Let’s review all the 7R questions and elaborate on the answers. Understanding the 7R ensures successful implementation of any change management process.

7Rs: Change Workflows

#1 of 7Rs: RAISED

First and foremost, who raised the request itself; who suggested the change request? Most businesses work in a compartmentalized or “siloed” manner, because each department specializes in performing their task competently. Although this feature allows businesses to perform specific tasks well, it can make it difficult to communicate or track requests.  For example, a new opportunity or need in a department might initiate the need for a change or a security leak might spur an IT service provider to initiate a change request.

So the person or department who raised the request and suggested the change is an important factor. The person raising the suggestion for change may have essential information that would direct the change or make the change possible. This person or department may also have the evidence necessary to support information to submit to the board. All changes, after all,  must be recorded and audited, and knowing who raised the suggestion for change — and the circumstances surrounding it — makes the next R easier to find.

#2 of 7Rs: REASON

What is the reason that this change is being requested? Once who raised the suggested change is identified, the reason can be explored. Some reasons for suggested changes may be to minimize security risk or a need for capacity increase. A compelling argument for the suggested change must be submitted to the board, therefore the reason for the change must be explained clearly. When the board decides to approve or deny a request, the reason for the change request is a major factor to their decision. The board must weigh the risks to the projects versus the benefits that any change would bring, therefore the reason plays a major role for any decision  for change. The reason for the change must benefit the project and be in line with the business and IT strategic objectives of the company strategy. By knowing and understanding the reason, you will avoid depleting resources for unnecessary changes.

#3 of 7Rs: RETURN

What is the projected return on the suggested change? What is the expected outcome if the change is approved and implemented? For example, once the change is implemented, what are the expected outcomes and will there be a return after the resources are used to implement the change? Will capacity increase by20%?  Or will the availability rise to 99%? Will the security leak be sufficiently addressed and fixed? These are examples of returns that could be expected from approved change requests. For example, if the return on a change request is low, the board may not approve. Therefore, it is essential that any change request include both the hard and soft benefits that could occur for the business.

#4 of 7Rs: RISK

What kind of risks would occur if the change request is approved? There’s no avoiding it, every change involves risks. For example, an operating system upgrade may cause a loss of the server completely. The question, however, is what are the risks and is the outcome worth any risks incurred? How much risk is tolerable? Although some risks can be avoided using an ITIL Remediation plan, some risks must be acted. What are the acceptable risks resulting from the requested change?  and some have to be accepted. The severity of the risk must be weighed, and mitigation plans should be in place to prevent and address them.

#5 of 7Rs: RESOURCES

What and how many resources are required? No changes can occur in an IT service provider without using resources, both people and IT assets. Identifying what resources are required and the amount of resources necessary to implement the change should be determined.  For instance, if a new feature is suggested, how long will the development team need to work on the change and what will it cost? If there are currently insufficient resources to support the change, how will enough resources be obtained?

The impact of the change request on existing resources should be a major consideration, therefore knowing what resources are necessary to implement the change is crucial. Would people need to be reallocated? Will the change exhaust existing resources dramatically? These are necessary questions to answer.

#6 of 7Rs: RESPONSIBLE

Who is the responsible party for planning, testing, and implanting the change?  Determining who is the responsible party for implementing the change helps evaluate resources and start planning. For example, if the change request stems from the software development team, then responsibility for testing can fall on them. After planning, development, and testing of the change request, then execution and implementation can be done by the release and deployment team. Clear delineated responsibilities are needed in terms of who is responsible  in change management. A useful tool is a RACI matrix  to help determine responsibility and accountability when it comes to tasks.

Because the IT environment is complex and fast paced, the question of responsibility can be particularly difficult to answer. However, boundaries, accountability, and responsibility needs to be determined when implementing a change request. Failing to do so results in longer downtime and confusion, perhaps incorrect or sequencing that’s not up to par. The following can help amend these problems, like shared scheduling,  change impact analysis, and relationship mapping to compile an integrated configuration management.

#7 of 7Rs: RELATIONSHIP

What are the relationships between other changes ?  Changes conducted by an IT service provider must be implemented carefully, and coordinated properly. One change request can create the need for another change request, so this should be planned if possible. For example, there are two change requests for a customer’s facial recognition system. One would be for the facial recognition software and the other would be for the facial detection device. The detection device would come before the recognition software, because for the recognition software to work, the detection device would need to be up and running. Changes like these would need to be defined and would be apparent upon the first change request, due to their predecessor and successor relationships.  Not recognizing the relationships between change requests can have disastrous effects.

The 7 R’s of a Change Request: What are their benefits?

Determining answers to these change request 7Rs can benefit a business in several ways. These questions allow a set of metrics for an organization to assess their risks. The 7Rs also enable more reliability and availability in its services to customers. Furthermore, the 7Rs helps evaluate how a business’s change management process adheres to current requirements and to identify areas of gaps. Reliable and consistent conformance depends on the 7Rs of a change request, which requires a change management audit using these essential seven questions.