Branimir Valentic It’s no big secret that changes are one of the most common sources of incidents, and one of the trickiest parts of everyday life inside an IT organization. We could argue about many possible reasons why that is so, but there is one source of difficulty with changes that is often neglected, and belongs right at the start of the change lifecycle – it’s how the change is triggered.
The most common trigger for changes is usually informal communication. Someone needs a change and contacts, e.g., the Service Manager or Product Manager, and the story begins. I remember a situation where the HR department directly contacted the developers and dictated what needed to be done because there was a new legal requirement. Well, I like the idea that HR knew exactly what they needed and that there was a clear legal requirement, but I don’t like the idea that the request for new functionality was done in an informal way. There are many reasons for not being happy with this approach.
Request for Change
Both ITIL and ISO 20000 define a Request for Change (RfC) as a medium to start the change procedure. An RfC is a formal proposal for change that is requested. Formal means that it’s in written form and recorded. Of course, in order to use an RfC there must be a Change Management process in place and defined responsibilities throughout the process (e.g., who is collecting raised RfCs, who approves them, etc.).
By having a written document that follows a change throughout its lifecycle, you will gain control and ensure that none of the information needed to implement the change gets forgotten. One prerequisite is that you have ensured that the change procedure is strictly followed, i.e., that there are no changes implemented that didn’t go through the official procedure. Of course, the logical question is: “How do we ensure that?” Well, that’s certainly not the easiest part. But, I think that management of the organization, a change process defined in detail, and an audit are your tools to achieve that.
When do we use it?
I would say – always. Uncontrolled changes (usually those which are not recorded or fulfilled by following the process) are the most expensive changes. If you don’t believe that – ask your customers. An RfC will not make your Change Management process perfect – but it will certainly give you control in hand. Further on, every change has to be authorized and prepared for implementation. By having control over RfCs you will be able to, e.g., group similar changes, prioritize them (or, as ISO 20000 requires – classify them), and schedule their implementation.
What is the content?
It seems that the RfC is pretty important. To gain maximum benefit from it, the RfC should have content that is uniquely defined and agreed upon. Practically, that means that it shouldn’t be possible for everyone to makes changes on the RfC (e.g., by adding or deleting fields) and that the content of the RfC contains enough information for future activities in order to successfully implement the change. If you have a Change Policy in place (if you don’t – I suggest that you implement one), that’s a perfect place to define the RfC (also from a content point of view).
And, there is one more thing. Don’t confuse an RfC with a Change Record. An RfC is used to submit a request. But, as the change progresses until fulfillment, there will be other information related to that change. Of course, don’t lose that information – record it. That’s the purpose of a Change Record – it contains all relevant data for a particular change. And, yes, data from the RfC are also written in the Change Record.
Figure: An RfC can be in the form of a template
What could be the content of an RfC? Well, neither ITIL nor ISO 20000 sets fixed requirements regarding the content of an RfC. Look at it this way – what would you need to have all relevant information to assess the change, decide about its acceptance, and implement it? That’s the content of an RfC. Usually, you will need a description (as detailed as possible), desired/required deadline for implementation, Configuration Items (CIs) within the scope, and, very importantly, the reason for raising the change. It’s also advisable to include information about what will happen if the change is not implemented (or you can leave that for the change assessment phase). Once the RfC is submitted, usually the Change Manager takes care of if throughout the process. And, that’s where other details will be entered into the RfC (e.g., priority, authorization details, implementation details, etc.).
How does it work in real life?
It depends on whether you use a tool or not. If you use a tool for IT Service Management – great for you, because it will be much more convenient to gather the necessary data (e.g., by defining mandatory fields on the form, you will ensure that no RfCs are raised but remain incomplete).
If there is no tool in place, make an RfC template with all information that you require. And, don’t accept an RfC that is not properly filled in. That will improve the efficiency of the Change Management process and, in the end, make your users happier.
Although the Change Management process can be complex, there are ways to manage it. An RfC is one of them. But, it depends on how consistently you are using it. Like everything in the IT service lifecycle, Change Management, including the RfC, is subject to improvement. Yes, that means use an RfC to make changes to – the RfC.
To gain a better overview of the Change Management process, see this upcoming webinar: An overview of the ITIL Change Management Process.
