A gem is small, all too easily to overlook, but very valuable. That pretty much describes something you find in ITIL® 2011 – the “Change Proposal”.
It is a little nugget of best practice that has generated big return on investment for those who have used it – huge payoff with incredibly little 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 – something that has been tried multiple times and seems to work. It isn’t mentioned by COBIT® nor does ISO® 20000 mandate it. But that doesn’t make it any less valuable.
There would be considerable value to the use of Change Proposals in a very mature ITSM environment – where Application Development, Infrastructure and Service Delivery were all integrated into a single Service-oriented vision and the full ITIL® architecture was enabled and governed.
Yet there is even more value to it when that isn’t the case. In fact, I would venture to say its value goes up proportionally to your ITSM immaturity!
Let’s take a look at an all-too-common scene in the ITSM play.
Change Management is primarily run by Service Operations. They are concerned with minimizing the risk and negative impact of what goes into production. Change Management is seen by Project Managers as a final bureaucratic hurdle to overcome to get their projects completed, and a point where things often come to a screeching halt even when tight deadlines are imminent because of things that are demanded at the last minute that are time consuming and difficult, but would have been easy to take care of if they had been known earlier.
Change Management sees the Project Managers as leaders of teams of rampaging hordes throwing RFC’s 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, stage left.
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, at least initially, the objective is simply advice.
ITIL® says that a Change Proposal is basically a summary of the Project or Service Charter with its associated Business Case with a projection of what types of Requests for Change (RFCs) are likely to come out of the exercise and when.
All that is required is that this be 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 and returning their advice and asking that, when the RFCs eventually get submitted, they quote the relevant Change Proposal.
No fuss, no muss.
The payoff? Wow!
For Change Management, they now get a view of what’s coming down the pike and are able to 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 that 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 even the items that aren’t easy can be worked into the overall plan and budget. By the time they submit the RFCs they will have ticked off all the Change Management concerns, with surprises and delays in getting the RFCs approved being minimized.
Worth considering ?