ITIL Checklist: Free Request for Change (RFC) Template

Request for Change Definition: What is an RFC?

In IT Service Management (ITSM), and according to ITIL® practices, a Request for Change (RFC) is a formal, budgeted request to implement changes.

In most cases, an RFC is outside of any standard, minor-level changes. RFCs are part of the Information Technology Infrastructure Library (ITIL) Change Management processes, as defined in previous iterations of the ITIL framework and the current one, ITIL v4.

Change management within ITIL helps to align IT processes with business goals and objectives. In many ways, change management is integral to digital transformation and transformational processes.

As an IT leader or IT professional in DevOps, if you've ever tried to get changes approved, especially if a new budget is required, you know how challenging this can be. IT leaders often want to implement changes quickly, whereas business leaders can take more time to understand and approve changes that ITSM teams and vendors know need to be made.

For more information, here's Giva's Complete Guide to Maximizing IT Change Management for Continuous Improvement.

In this article, we explore what it takes to make this process easier, including using a Request for Change order form and everything you need to include in one.

What Are the Benefits of Using an RFC Form? 

We need to remember that when Axelos, the owner of ITIL, updated their best practices, the concept name changed from 'Change Management' to 'Change Enablement'.

Axelos wanted to make the concept easier to implement and manage and more consistent with modern, agile DevOps processes. Despite the name change, the concept remains fairly similar; it still focuses on the ongoing identification and improvement of:

• IT services (hardware, software, platforms, etc.)
• Service components
• ITSM practices and processes
• Any element or practice that can improve the efficient and effective management of IT services

An RFC form is the best way to implement change enablement within any organization. Especially if your IT team has appointed a Continuous Improvement manager and uses a Continuous Improvement Register (CIR) to record every idea for changes, new technology rollouts, and service improvements.

One of the main reasons RFC forms are so important is that: "Nothing can change in the live IT infrastructure without approval from Change Management."

An Example of an RFC Form in Action

There are three different types of Request For Change Forms:

• Standard
• Emergency
• Normal 

With Standard RFCs, these are usually low-risk, easy to document, authorized within the ITSM team, and simple to implement.

Emergency RFCs need to be reviewed and approved speedily. Stakeholders outside the IT team must know how urgent these changes are, as in most cases, these involve systems failures that cannot be fixed using normal processes. A more significant change is required, and if this needs a budget, then an RFC should be put in.

Whereas, Normal RFCs aren't an emergency but require approval from the Change Advisory Board (CAB) or business and operational leaders. In most cases, as these changes aren't an emergency or a simple (internal, ITSM) change, it involves a more coordinated and strategic approach. A budget is often requested, so operational leaders need to understand the business case to approve this change.

Giva Free ITIL Request for Change (RFC) Template

Here are a template of elements that should be included in a Request for Change form:

• Project Name

  Every change management project requires a name; an easy way for it to be identified by stakeholders and IT professionals.

  Make the project name simple, and easy to remember, and log that name in your Configuration Management System (CMS).

• Unique ID 

  Every RFC form needs a unique ID, and this ID needs to correspond with the change request logged in back-end IT systems, such as a Configuration Management System (CMS). A unique ID can also be known as a Configuration Item (CI) logged into a CMS.

• Change Owner/Manager

  Who's responsible for this project?

  Ensure the project owner or Change Manager is easily identifiable and contactable within the RFC, and the corresponding Configuration Item (CI) is logged into a CMS.

  If this request comes from an external party, such as a software vendor's client, ensure the person requesting the change is tagged as external. Depending on the services you provide, this might move the request into the workflow of an account or project manager, as these requests either need to be funded by the client or assigned an internal budget.

• RFC Initiator (if this isn't the Change Owner or Manager) 

  In some cases, the change manager and change owner aren't the same person. An IT leader might have delegated this project to a mid-level manager, making that person responsible for the project, even though the initiator is higher up in the organization.

• Proposed Change Priority Indicator 

  How high a priority is this change?

  Change managers need to make this clear. Not everything is a high priority unless it's an emergency change request, and this should be highlighted in the CMS and Project Change Log.

  In most cases, the priority rating will either be numerical (1 to 5) or outlined from "Emergency-High" to "Low."

  Make sure internal IT stakeholders and managers agree on how important this change is before submitting an RFC, as senior business leaders may push back on the priority rating if they feel the business case has not been made effectively or the budget is too high.

• Description of Change Requested 

  Here is where more meaningful information needs to be added. You need to include details such as:

  • Department or team that will be affected by this change
  • What needs to be changed
  • Outline the IT services, software, or hardware that will be changed, updated, overhauled, or replaced

• Reason for the Proposed Change 

  Why is this change needed? Is it a low-level error that needs fixing but requires admin-level changes to the system, and therefore, an RFC is required?

  Or are we talking about a more extensive series of changes, such as a complete digital transformation project that will take months to implement and impact an entire department?

  Putting in the details as to why this change is needed is essential to making the business case. Ensure you're clear on this, not from a technical perspective, but from the viewpoint of saying why the organization will benefit from these changes.

• Impact of the Change 

  What are the expected impacts of the change being requested? 

  From an organizational perspective, this is crucial to show business leaders the return on investment (ROI) they can expect from approving this RFC. Pull together any evidence you can. Especially if there's a cost/budget involved: ensure you can demonstrate the upside and ROI to the organization.

• Risks of Implementing this Change 

  Outline the risk assessments that have been done before considering this change, e.g., potential downtime, and the steps that have been taken to mitigate any risks. For example, implementing any system-wide changes overnight so it won't impact operational working hours. Or ensuring backups are already active before implementing any changes.

• Risks of Not Implementing this Change 

  What's the worst-case scenario if you don't implement this change? 

  Make the business case for any downsides and risks, such as:

  • Weakened cyber and data security
  • Regulatory or compliance failures
  • Technology or systems failures (including hardware and access to cloud-based systems)
  • Impact on productivity, IT uptime, revenue, and operational costs

• Timescale for Implementation 

  How long will this change take to implement? 

  Give IT and business leaders a clear and realistic timescale, especially if third-party vendors are involved too, so that you know the role they will play and the time it will take to implement the work.

  If the change requested is an emergency, then make it clear the turnaround time will be fast. If this is a larger-scale digital transformation project, then outline each stage's steps and time.

• Budget Requested 

  How much will this change cost? 

  At the same time, it makes sense to outline the ROI an organization can expect and compare this to the cost of failing to implement this change.

• Supporting Documents 

  Include in the RFC any relevant supporting documents, and ensure these are also attached and easy to find in the CMS and Project Change Log.

  Provide budget holders and business leaders with anything they might need to make an effective decision. Especially if this change has been prompted by IT failures or recommendations from third-party vendors or software providers.

• Approval or Rejection (and ongoing Status) 

  This is the final section and usually includes a simple dropdown within the CMS and Project Change Log:

  • In Review
  • Approved 
  • Rejected 

  Within this, the change owner/manager should know who is reviewing this change proposal, their role in the organization, and there should be space in the CMS to provide a reason for an RFC's approval or rejection.

And there we go, that's everything you should need to include in a Request for Change (RFC) form. We hope this is helpful!

Here's what an ITIL Change Management and Request for Change (RFC) form workflow look like.