What is a Change Request?
Change request or a.k.a CR is a request initiated in a project by one of the stakeholders or team members to formally change the scope of the project. Change requests can have varying impacts depending on the change. The change could include cost, additional resources, time and software. Typically, change requests cause changes to project timelines and can be a cause disagreements and conflicts within the project. Change requests are generally approved by project control committees or governing boards.
What should a Change Request capture?
It should contain all the information required to make a decision. Basic details like project name, project manager name, date submitted and approved need to be recorded. Change description is also important to give the readers a high level overview of the change request.
Schedule – if there is any impact because of the change then that needs to be clearly stated. The decision makers need to know if the CR is going to cause one day, one month or one year slippage so you need to clearly state the delay in terms of days or years.
Scope – If there is going to be any change in terms of what will be actually delivered then that needs be stated.
This needs be high level so that it can make sense to the management. Avoid having low level technical details.
Budget – This is one of the key impacts management is interested in – it is all about the money. Again important to state the exact dollar amount.
Quality – Another key KPI. If as the result of the change the quality of the deliverable can be impacted then that needs to be stated. Again important to state the quantum of impact.
Any other impacts – This is a general catch – all type section. If the impact you are seeing does not fall into above categories then you can use this category. Examples are customer impact, server load impact etc. If there is no impact for any of the above then say “none”.
Options – the form also needs to contain options. It is a good practice to check if there are some alternate options.
Software Change Request Example
The attached example presents how a Software project submits a Change Request.
The following fields are captured in the example (in the same order as the CR form) –
- Change ID number.
- Who requested the CR.
- When it was submitted.
- Why is it necessary.
- What will change if the CR is approved and implemented.
- How will the project change if the CR is approved in terms of cost and timeline.
- Who reviewed it.
- Whether it was Approved / Rejected, and when.
ITIL Change Request Template
ITIL is a structured set of practices, which are in place to ensure the alignment between the IT and the business needs of a company (also called RFC - Request for Change).
- General: The RFC number, submitter date, by whom and by when it should be approved / declined.
- CI to be modified: An explanation of which CI needs to be changed.
- Business Justification: Why the change is required.
- Impact: How the business will change.
- Category: Minor/ Standard / Major.
- Risk: Associated with the change.
- Authorization information: Who, when, yes / no, date.
Generic Change Request Template
The template’s purpose is to allow those involved in the project to request a change to the initial design, timeline, budget or resources which were approved during the projects’ kick-off.
The following fields are captured in the template –
- Generic form information: Who submitted the request, when, which project and the request’s number.
- Description: What the change is.
- Reason: Why is it necessary.
- Effect on the Deliverables: How the deliverable will change in terms of timeline.
- Effect on the Timeline: How will the overall timeline of the project change.
- Cost: How the cost will change in terms of hours, materials, etc.
- Status: When the request was received, by whom, was it approved, and when.
Change Control Template
The change control process aims to ensure that all changes to any project or system are assessed, approved and executed in a controlled manner.
- General info: Who raised the need for the change, when, for which project and its number.
- Classification: Low / Medium / High for the change’s Importance, Impact and Complexity.
- Assessment: What the risks are (business or IT) .
- Implementation Plan: The MMS, and what the price will be in terms of materials, HR, etc.
- Closure: When the change will be marked as completed, and accepted by the customer.
- Approval: Who received the request, when, and its status.