For all its complicated (and sometimes convoluted) glory, the IT change management process really comes down to a few simple principles: communication and expectation setting. At each step of the process, it is critical that organizations provide the formalized frameworks by which stakeholders can communicate important information throughout the entire IT change management process so that everyone involved knows what to expect. This is especially true of the creation of an IT change request, an important step in the IT change management process.
What is an IT Change Request?
An IT change request, sometimes called a request for change (RFC), is the formal documentation of the details around a requested change to an organization’s IT infrastructure. Drafting an IT change request is, at its root, about expectation setting: the more thorough the requestor (person or team), the better they lay the groundwork for an IT change process (whether or not it is authorized, planned, or executed).
When drafting an IT change request, it is important to keep a few central questions in mind:
- Who is the requestor?
- Why is this request being made?
- What documented past incidents corroborate the need for this change?
- What people, processes, services, and software will this change impact?
- What risks are involved?
- What is the plan if special or unanticipated circumstances are encountered?
- Whose approval is required for this request?
Change requests can arise for a number of reasons. Emergencies or unexpected circumstances come to mind, such as the need to immediately patch a security vulnerability or respond to breach. On a more regular basis, the hardware and software that comprises an organization’s IT infrastructure will require regular upgrades, or need to be sunsetted and/or replacement. All of these precipitating events are common sources of IT change requests.
Ensuring that changes to software and infrastructure are requested through the proper channels and follow a defined process is critical for security and compliance – Myndbend Process Manager creates a repeatable process so your team can focus on velocity and not documentation.
What Goes Into an RFC? Some Areas to Consider for your IT Change Request Template
The details included in an IT change request template will vary from organization to organization. Still, there are some fundamental baselines to include, such as:
-
Requestor information including name, role, department, and contact information. This might seem fundamental, but this is especially important to include in templates, especially for larger organizations.
-
A detailed description of the change including the type of change (upgrade? New addition to the tech stack?), the reason for the change, and precipitating incidents that make this change necessary.
-
Expected timeframe and cost if possible. Often this information is part of a request for additional information from change managers or the change advisory board (CAB).
-
Assessment of risk to scrutinize what will be changing, what will stay the same, and what will go away altogether. A risk assessment helps identify which factors might create delays, disruptions, and other obstacles to the successful completion of a project.
-
Business justification including the impact to teams, cost, and perhaps the KPIs by which the success of this change might be measured down the line.
- A rollout plan and a backout plan so the CAB might assess how this change will be executed and what contingencies are in place in case things go awry or change dramatically.
Why Formalizing Your IT Change Requests is So Important
To the uninitiated, both within the organizational structure and without, the IT change request process can feel like a whole lot of red tape. This might explain, in part, why so many organizations tend only to the bare minimum (if at all).
Yet drafting and submitting a detailed, templatized IT change request for review is an important part of the overall flow, for a couple of key reasons:
-
It directly informs authorization to work because not all IT change requests are approved. Some RFCs are approved conditionally, while others are rejected outright. A formalized RFC process helps establish a framework by which these requests can be reviewed and authorized by the CAB in an efficient and effective manner.
-
It serves as a point of reference down the line for organizational leadership and the change management team tasked with assessing the progress and impact of a change request after it has been approved and is being implemented.
-
It helps regulate a high volume of requests in large organizations. There needs to be a standardized way to handle a high volume of IT change requests coming from disparate sources across the organizational structure. The way these change requests are drafted and submitted helps ensure that the right projects are being prioritized and that the right resources are being allocated.
-
It gives the approval board a chance to get more detail, which should not be overlooked. Not all change requests are rejected or accepted straight away; sometimes, CABs or change managers will request more detail around risk, cost, or other factors. The formalization of this step provides the framework by which this “conversation” can happen.
- It helps with efficient resource use/allocation by specifying what kind of resource and cost requirements will be required, an essential part of overall IT change management and control.
- It informs the broader IT change management plan, as once an RFC is approved, the document can be used as a basis for how user notifications, change calendars, change classifications, and other aspects are built out and executed.
Once a formal IT change request is drafted and submitted, it is time to move to the review stage. For a detailed look at this next step, read on here: The IT Change Request Review Process.