A gem is small, all too easy to overlook, but valuable. That pretty much describes the ITIL Change Proposal.
ITIL Change Proposal is a little nugget of best practice that has generated a significant return on investment for those who have used it – a massive payoff with minimal up-front cost.
There is no tool configuration needed, only an agreement by a few parties to do something based only on a "what's in it for me" justification by each.
The Change Proposal is pure best practice – validated multiple times with proven benefits.
COBIT® nor ISO® 20000 reference it, but that doesn't make it any less valuable.
There would be considerable value to using Change Proposals in a very mature ITSM environment – where Application Development, Infrastructure, and Service Delivery were all integrated into a single Service-oriented vision. Yet there is even more value to it when that isn't the case. I would venture to say its value goes up proportionally to your ITSM immaturity!
A Typical Scenerio
Service Operations primarily runs the change management process. They are concerned with minimizing the risk and negative impact of what goes into production.
Project Managers see change management as a final bureaucratic hurdle to overcome to complete their projects.
Things often come to a screeching halt when project management meets change management. Changes get raised at the last minute, then get stopped dead in their tracks by the process requiring testing, validation, and approval.
Wouldn't it have been nice if the change manager was aware of the proposed change eaerlier?
Change Management sees the Project Managers as leaders of teams of rampaging hordes throwing RFCs at them without any advance notice and pushing to get those things done with no regard or appreciation of the risks involved or the impact on the production world
Change Management and the Project Managers see each other as adversaries. It doesn't have to be that way. Enter the Change Proposal.
The ITIL Change Proposal
While ITIL® describes the ultimate Change Proposal mechanism as having the projects and service design exercises getting authorization to proceed with their work via the Change Proposal, I suggest that, initially, the objective is simply advice.
ITIL® says a Change Proposal summarizes the Project or Service Charter with its associated Business Case. The proposal includes a projection of Requests for Change (RFCs) that will come out of the exercise and when.
All that is required is that this is communicated to Change Management by Service Portfolio Management or Project Portfolio Management as part of the chartering mechanism.
Change Management (usually in the form of its Change Advisory Board (CAB) reviews these as part of their regularly scheduled meeting agendas, returning their advice and asking that, when the RFCs eventually get submitted, they quote the relevant Change Proposal.
The Payoff
For Change Management, they now see what's coming down the pike. They can contribute to the success of projects and new services simply by warning the projects about trip wires and concerns about possible impacts on the operational environment.
When the RFCs are eventually submitted, the context is known, most of the things they would be concerned about have been taken care of, and they can concentrate on steering the RFC into production after approval.
For the Projects, most of the advice they get up front is relatively easy to deal with before they are too far into their work, and they can now plan for the more complicated items in advance.
By the time the Project Manager submits the RFCs, they will have ticked off all the Change Management concerns, minimizing surprises and delays in getting them approved. The ITIL Change Proposal is, in essence, a heads-up to the Change Manager by the project team to deal with potential bottlenecks before they become a problem.
Originally published Jun 24 , 2014 14:53 PM, updated Jul 15, 2022
