When should we log an RFC - Is it when IT gets the call
By ITIL® from Experience©
Practitioners often make Change Management more complex by having a Request For Change (RFC) logged as soon as a User makes a request for something that requires a change, like upgrading a PC. This example is provided in the ITIL® v2 definition1 and persists in the v3 definition2 as well. The difficulty is that it creates a high volume of low value RFCs in the process. Low value is in relation to the overall health of the IT infrastructure should one of those changes go wrong.
In fairness, this approach works well when the organisation has standard changes (see How to implement Standard Changes). However, most organizations struggle to define their standard changes and many cannot agree on what constitutes a Standard Change.
As a result, logging RFCs for User requests increases the complexity of the Change Management process. Lets take a request for an application enhancement as an example. The enhancement is reviewed, scoped, analyzed for feasibility, its effort estimated, assigned for development and eventually scheduled for a release perhaps 6+ months from now. Therefore, the RFC stays open in a status such as "Waiting Development" all this time. This affects the perceived performance of the Change Management Process and would cause the Change Manager to periodically review these RFCs even though they are owned by the Application Manager or Product Manager. The result is a blurred line of responsibility between Service Design, Release Management and Change Management. Thus, the Change Manager would interfere in these processes to ensure performance of "his/her" change process.
A better approach is to log a service request until an RFC is required to request authorization to deploy the release. This enables the Application Manager to bundle several service requests enhancements, incidents, problems and other changes as a release linked to one RFC.
This approach respects the definition of a change3
that it is, a “change to the infrastructure.” It also aligns to v3 whereby an RFC and Change Management is part of the Service Transition phase of the lifecycle. Moreover, it is supported by the updated ITIL® v3 definition that states that a standard change can be “logged and tracked using a different mechanism, such as a service request.”
Therefore, a simpler approach is to log a service request for application enhancements followed by an RFC for deployment.
In summary, IT should not log an RFC as soon as it gets a call from the user. A service request or incident should be logged. An RFC should only be logged once it is determined that a change is required which can be linked/related to the original service request or incident. This enables the organization to benefit from all the ITIL® processes while reducing complexity.
It is the equivalent of taking your car to the garage. A service request is logged to investigate a strange noise or an incident is recorded to address a loss in engine power. The need for a change only arises after the mechanic determines that something needs to be changed. At this point and RFC is raised.
"Implementing Change Management is like driving from New Hampshire where you "Live Free or Die" to Missouri, "The Show Me State."
Related:
- How does it work when an incident requires a change
- Do projects need to log RFCs
- Should the incident be closed as soon as the RFC is logged
- Does an emergency change need an incident
- Is a server reboot a change
Category:
ITIL Process > Change Management
Copyright 2012-2015 - ITIL® from Experience - D.Matte