Change Request: The Crucial 7 R’s for Success

Change management is a process that forms part of the ITIL Service Transition Stage of the ITIL Service Lifecycle. ITIL Change management process is also an important feature in ITIL certification exam. Online ITIL training courses specify that there are seven important questions starting with R regarding a change request in the IT change management process. We will be going over each of these 7R questions in this article. Answering these 7R questions will go a long way to ensuring successful implementation of a change management process.

7R of the Change Request#1: RAISED

Who raised or suggested the change request?  Business often works in a “siloed” manner where different departments operate independently. This can make it difficult to keep track of who requested what. There might be a new business opportunity so the business might be requesting the change or there can be a security leakage in the system so the IT service provider itself can initiate a change request in this case as well. So, the question regarding who suggested the change is important in change management and an important 7R. The person who raised or suggested the change may have some insights or evidence to present to the board that supports the decision to initiate a change request. A system that is centrally located that records all changes will ensure that everyone knows which department was responsible for raising the change request. This single system of records will also be helpful during audits.

7R #2: REASON

Why is this change requested? Capacity increase or availability increase can be the reason for a change request or minimizing a security risk can be the reason as well. Evidence or a persuasive argument regarding the reason for the proposed change request must be presented to help the board to decide whether to approve the request. This way, introducing a risk in the form of a request without offering any benefit to the business will be avoided. Changes must be aligned with the business and IT strategic objectives. Assessing whether the change is aligned with the company strategy will avoid the spending of resources on a non-strategic change.

7R #3 RETURN

What will be the outcome when the change request is implemented? For instance, after the implementation of a change, capacity will increase by 10%, or the availability will increase up to 99%, or the security leakage will be fixed. These are examples of returns on a change request and can be used as compelling reasons to approve a change request. If the return is low, a change request may be refused. Therefore, it is critical that any request must include the hard and soft benefits that the business can expect to see when the change has been implemented.

7R #4: RISK

What risks does the change request involve? All changes involve risk. For instance, an operating system upgrade on a server can include the risk of losing the server completely if there would be a problem during the upgrade. The question is: how much risk? Some risks can be avoided with an ITIL Remediation plan and some have to be accepted. The potential severity of the risk also needs to be kept in mind. The risks associated with the upgrade must be documented alongside risk mitigation plan and an estimate of how likely the risk is bound to occur.

7R #5: RESOURCES

How many are required? Both people and IT assets are needed in an IT service provider and no change can occur without enough people or enough IT assets. If the request is requiring capacity or availability increase, for instance, one needs to know how many new servers or administrators will be needed to support services. If a new feature is requested, how long will it take for the development team to develop the requested feature? These are important questions to ask while planning the schedule of the change implementation. If there are not enough resources available and new resources cannot be procured, the change request may be rejected. The impact of the change request’s requirement of resources on other projects must also be considered. Would people or assets need to be re-allocated to address this change? It may have an impact on other projects that are important for the company’s strategy, which in turn may have a cost implication.

7R of the Change Request #6: RESPONSIBLE

Who is responsible for preparing, testing, and implementation? For instance, the development of a change request can be done by the software development team, testing can be done by the test team. After a successful development and test of the developed change request, implementation can be done by the release and deployment team. Clear responsibilities in terms of who will do what are important in change management. A RACI matrix is a useful tool to determine who should be responsible and accountable for which tasks.

With so many changes occurring concurrently in complex IT environments, this can be difficult to answer. Change relationships need to be determined from within and across functional boundaries. Failing to do so will result in longer periods of planned downtime due, for example, to incorrect or sub-optimal change sequencing. Shared scheduling of planned changes can help here, as can change impact analysis and relationship mapping from an integrated configuration management database

7R of the Change Request #7: RELATIONSHIP

What are the relationships to other changes?  There can be several changes conducted by an IT Service provider. These changes must be coordinated properly. If a change request is a prerequisite of another change request, this should be planned accordingly. For instance, if there are two change requests for the customer recognition system of a bank’s ATM: fingerprint recognition software and fingerprint detection device. First, the fingerprint detection system must be implemented to the ATMs before the fingerprint recognition software to detect and process the fingerprint images of the customers can be implemented. These kinds of predecessor and successor relationships in a change request must be defined. If not, it can have disastrous results once the changes to the service are executed. Change relationships need to be determined within and across functional boundaries. Failing to do so may result in longer downtime periods.

Benefits of the 7 R’s of a Change Request

Answering these seven questions relating to a change request provides several benefits. It allows for the set up of metrics with which organization can measure change risk. This helps a lot to make services more reliable and available to customers. It also helps to assess how a company’s change management process complies with current requirements and to identify gaps that can be bridged. To ensure consistent conformance, a change management audit will be required by asking and answering these seven questions.