Developing the Business Case for Change, Configuration and/or Release Management, part 2
Last time I shamelessly teased you by stating that speed, quality and cost can all be improved at the same time. Now I’ll tell you how I’ve seen it done in real-world IT shops.
Here’s the secret: they implemented strong, mature ITIL-based Configuration, Change and Release Management.
Here’s why it works: as I said, these three processes are tightly linked at almost every step.
For example, your planned changes (RfCs or Requests for Change) are assessed for impact and risk and which Configuration Items (CIs) are involved by using the relational data about your infrastructure that?s stored in your CMDB (Configuration Management Database).
Then, the Change Management process hands off the actual implementation of many (but not all) changes to the Release Management process, which is responsible for building, testing and implementing the actual changes to the infrastructure.
And of course, the CMDB gets updated with the new information about the CIs that have changed.
Because of this tight linking, smart companies are able to build in a high degree of control and quality checkpoints. For example, if a planned rollout fails, you want to be able to trace the cause of the failure back to its origin. When you build mature processes and tight controls, then review and act on the data and metrics you capture, you have specific, clear, measured information that you can use to make improvements in your policies and processes and procedures. It?s a continuous feedback loop.
Result: your operations become more efficient. Your shop can deliver more changes, with higher quality and reliability, at lower cost. CIOs love that stuff.
Till next time, keep up the good work, and ask yourself: ‘in our shop today, when a change causes problems, do we rigorously go back and find out not only the technical cause of the issue but the process or procedure gap that allowed the tech problem to sneak in?’
Scott Braden
Download Evergreen’s free Change Management Policies and Procedures Guide
Also, Don’t forget to register for Evergreen’s change management webinar: Take Change Management from Firefighting to Fire Prevention
—–
Quick question.
The more I read and the more I think about it, it almost sounds like Change Management should be after Release Management.
Example.
Fix or Enhancement is needed so a release is created with 1 or more release packages. Once the release is Designed, Built, Tested a RFC is created to move to production where the move is executed and then verified.
I originally thought that any time we needed to change a technology item we would create a change request. It would be evaluated for importants, validity, etc and then approved. Once approved it would be put into a release where it was deisgned, built and tested. Once the release was tested it would be scheduled to move to production.
Help me get this clear in my head
Thanks
Dallas ITIL Fan
It is somewhat confusing and in practice is done both ways. Change, release, and configuration management disciplines must work together to ensure that correct and effective action is taken. Since change management controls changes to all CIs, change management really encompasses all change (other than change processes occurring inside a development activity set, where these are controlled by the SDLC). So while release management is a collection of changes to meet a specific purpose, change is both a subset and a superset of release management.
To further emphasize this, the Change Advisory Board is supposed to consider all RFCs in light of the business and technical needs, including factors such as impact and cost. So if the CAB doesn’t review and approve the big change that is a release, it could end up shooting it down after all the release packaging work is done, due to cost or impact factors—thereby potentially wasting a lot of effort.
To take it a step further—while this is rare in practice, if change has visibility at the portfolio planning stage, the true cost of major projects would be more accurate, and perhaps change the ranking and funding of planned projects.
For example, let’s say development plans a 250K enhancement to a major application that has a 500K NPV and gets a green light. Later, after much work is done, the CAB looks at the planned change and determines that the enhancement will require a 1M investment in infrastructure upgrades. Now the NPV is (simply put) minus 750K. Does the investment still make sense? It may not.
I lean to your original thought, as a key role of the CAB is to help decide what ought to be done, while the focus of release management is around how it will be done.
Don Casson
CEO
This somewhat accurate if you were only doing change control, which most companies do today. That is do all the planning and building and testing of the change and entering an RFC when the change is ready to be released to production. True Change Management, however, will have at least two approval levels and sometimes three. When a corrective change or an enhancement change is needed, an RFC is entered PRIOR to any work being performed. The first level filtering will determine the priority feasibility, impact, risk and relative timing of the change. This step is performed by the change manager. Once the RFC is accepted it is approved by the CAB to commence the work and turned over to Release Management to perform the work under the management of the Change Management process. Once all the appropriate building and testing are completed, it should final approved for release to production by the Change Manager or the CAB based on the impact and risk of the change.
I hope that helps
Tony Iannetta
Consulting Practice Director