Changes and RFCs are not the same thing

They are often confused and considered as equivalent, but they are far from it, the changes and the requests for change (RFCs) are not the same thing. Without giving you lengthy treatises or detailed studies of ITIL, we will attempt below to shed a little light on this topic...

Although I do not consider myself an ITIL process consultant nor do I act as such, it is certain that my professional life focuses on this framework for IT service management, and, in collaboration with Proactivanet, my task is to orient and advise clients and potential clients on how to approach the implementation of some processes using our tool. One of the processes that gives rise to the most uncertainty and about which I receive the most questions is change management, and when going into more depth on this topic, I often discover that we really mean requests, and not changes.

The request management process is a process that is run largely by the Service Center, typically in close coordination with incident management (although they are completely different processes), which receives the new requests made by the end users in accordance with a service catalogue that we would have to have defined and published. The requests can be of many types: purchase orders, requests for new services, requests to adapt reports, technical queries, response to questions, consulting,.... In no case has the service been compromised (everything should be working properly).

One of these types of request can be precisely an express request for change (e.g., in a report), but on other occasions a request could result in a change without the user really being aware of this. The request from the user is the mechanism by which they ask us for things, publicly, and it can trigger (or not) a RFC in the change management, which might not yet be visible for the end user, since this is an internal IT process. Moreover, in many organizations the requests that result in a change even exceed the remit of the Service Desk, escalating to external project management teams managed by PMOs (I am not saying that this is what is most desirable -far from it- but in many cases this is what really happens...)

The following rule will help us define what we mean:

• If what you need is to manage the flow of requests for change made by your users (to set up a mechanism for them to request things of you), then we are speaking of request management, not change management (although the former might result in a need the latter); many requests will be resolved without the need to make any change.
• If what you need is to manage the change itself (not the request itself and communication with the user, but rather the “project”), whether this change has its origin in a user request or is of any other origin, then we are speaking of change management; a significant volume of changes will have very different origins, and will not necessarily originate from any user request.

As is almost always the case in ITIL, everything can be called into question and depends on the individual case, but I hope that these simple remarks are able to clarify things for at least a few people who might be confused 😉

Jandro Castro.