Branimir Valentic Request for Change (RfC) counts as one of the most popular expressions in ITIL or ISO 20000. For both of them, an RfC is “a formal proposal for a change to be made.” Usually, it’s a document (or form – if you use a tool) that describes a change in detail. For established services, and changes that are not categorized as Major Change – that’s fine, the RfC covers all aspects of such change. But, there is a difference when there is a new service or a (major) change on an existing service.
Position in the service lifecycle
Sometimes changes have high impact on existing services and business processes and/or require significant investment. Let’s assume there is a request from a business, e.g., that a new module for logistics should be added to the existing ERP. Basically, we are talking here about a major change. It requires a service (i.e., its utility and warranty) to be defined, analyzed, and approved – which are all activities performed in the scope of Service Portfolio Management (see Figure 1). Just filling in the RfC is premature.
Activities in the scope of Service Portfolio Management affect many other processes throughout the service lifecycle; therefore, it’s important to have them well managed. A Change Proposal originates in Service Portfolio Management (you can find more about Service Portfolio Management in the article ITIL Service Portfolio Management Process Overview), and it’s your tool to communicate and get approval from related processes, i.e., Change Management.
Let’s clarify the difference between the two. A Change Proposal is not a “basket” like (conditionally speaking) an RfC, where you throw in as much information as possible (this may be an exaggeration, but the RfC should be as detailed as possible). Quite the contrary – a Change Proposal is a high-level description of a new service or a change in an existing one and should remain simple, concise, and straightforward, i.e., without equivocation – direct and to the point.
The purpose
To explain the purpose of the Change Proposal, let me take one step back. Smaller changes (which is a relative term) are usually managed directly by Change Management (e.g., adding new reports in our ERP). But, if we are talking about new services or complex changes, then the definition and assessment of the service or change will be performed in the scope of Service Portfolio Management. Of course, that won’t be a description of the technology architecture (this will be done in the Service Design stage of the service lifecycle), but rather a definition of the purpose of the service, customers and users of the service, major inputs and outputs, (high-level) performance requirements, compliance with regulatory requirements, etc.
Based on high-level information, a Change Proposal is created and sent to Change Management for approval, i.e., authorization. Change Management (read the article Elements of Change Management in ITIL to learn more about Change Management) will confirm whether the service (or change to an existing service) is feasible, and then create a high-level blueprint for the new or changed service.
Analysis and definitions (which provide inputs for the Change Proposal) are very important activities, because they should eliminate services or changes that are clearly unfeasible. In such a way, we’ll save a lot of effort later in the design and transition phase of the service lifecycle.
The content
A Change Proposal is a short description of what must be done (for changed or newly implemented services). Content of the Change Proposal is typically:
- a high-level description of the new or changed service – i.e., simple
- the business case – this is your most important knock-out criteria. Further work on the Change Proposal will be stopped if the business case is negative (or if it doesn’t exist)
- the expected implementation schedule
In our case (remember, the logistics module from the beginning), the Change Proposal will provide a rough description of the module, how it fits into the existing ERP, what needs to be integrated together so that all processes are functional and the data are flawless, financial justification (i.e., the already-mentioned business case – what is the gain or savings expressed in financial terms when the new module is implemented), time-plan requirements, etc.
Figure 1: Service Portfolio activities that highly influence content of the Change Proposal (established in the “Approve” phase of the Service Portfolio activities)
Dilemma
If you are confused, that’s fine. You may be asking yourself – Which one should I use? As I experienced, most of the people in ITSM are using an RfC. But, the Change Proposal is a kind of well-kept secret. That’s your communication channel; i.e., the Change Proposal is the way that people involved in service definition (or definition of change) communicate with other teams throughout phases of the service lifecycle – like Change Management in Service Transition. And, a Change Proposal will help you define the direction and freedom that you have when setting up a new or changed service.
Once Change Management approves your Change Proposal – what’s next? It’s the so-called Service Charter – a document or activity that gives the “go ahead” for the new service or the change to an existing one. Depending on the quality of the previous steps (definition and assessment of the service) and the Change Proposal, the Service Charter will raise (or lower) the quality. And that also influences the decision-making process – “To invest or not to invest.”
Use this free ITIL Gap Analysis Tool to evaluate the completeness of your Service Portfolio Management and Change Management processes.
