Stuck in IT Change Management?

Posted: April 20, 2017 in Information Technology
Tags: , , , ,

Continuing my series in Change and Release Management, I thought I would do an update on some topics around Enterprise Change Management.

20170330_161619I recently had the opportunity to give a lecture at the University of Economics, in Prague, Czech Republic in April 2017 on Automation Design & Test, and in discussion, we talked about DevOps, frequency of change and ITIL Change Management concepts.  We focused on Design and Automation patterns for Test and how to plan for Automation and Test in DevOps using Continuous Integration.   But with DevOps, the goal is to be able to iterate release activity and be able to deploy changes much faster than waterfall.  And how do you do that when there is time and process to work through with the Change Management process?  So one thing we noticed in the industry, is that companies that have implemented ITIL Framework are processing Request for Change (RFC) as many independent changes that can come up from Business or Operations demand.  The framework provides some governance around the change to hopefully avoid unintended consequences.  But at each RFC process implemented, no matter what tool you use, has specific approval gates, information gathering and details,  and can slow you down from achieving the goals we seek with DevOps and or IT Automation.  The problem that I see in the industry when I speak about this topic with various educators, other IT colleagues, or Industry Leaders, is the amount of RFCs that are being processed.  There is much effort to process a change workflow to the point where many in the industry call out the problem as being  “Stuck in Change Management”.  So, how we address this?

Well, ITIL did provide a solution in the Release Management Process, but where it described this I think was a bit vague.  I believe to address this problem we need to really discuss the formation of the RFC itself with regard to Change Scope that becomes the RFC.  Now, I know some vendors and tools out there would simply claim that the can RFC grouping into a Release and use that group of RFC as a Release process, but that really does not solve the problem.  First off, each and every RFC still has the overhead of the workflow, the governance, and process. So while grouping RFCs is nice to think it will handle the problem, it really is just a grouping exercise.  No, what we have to look is the change scope itself and what forms the RFC as a more complete Change Record.

Lucky for us, there are tools out there that help us do this.  Some would say Jira attempts to do this by capturing change demand, and allowing you to slot that demand into a a Release.   However, to really do this correctly, you need to have more cross-platform, cross-product visibility of all changes and releases planned to do the thorough impact assessment and planning for a Release.  Jira, I believe is good for managing the deliverables at the IT development level, and for slotting specific IT work to Developers.  But, for specifics to what makes up the release, I think we need to capture more business friendly release notes and content to describe what will be in the RFC itself.  And in Release Management, we need to see across the platform for all the Releases being planned to avoid conflicting dates or opportunities, which is something Jira does not do. It is not really focused on Release Management where our focus is on Impact assessment, Environment management, Release Build Tracking and Release Health across multiple products, projects or the portfolio.  But Jira, is an excellent tool for IT Development for the contents that may make up the Release since it gets into a lower, granular level of detail.  So, a few new tools have emerged to assist us with Release and Change.

New emerging release tools provide a view or a look holistically at the entire end to end Change and Release process.   They will capture change demand, or scope, and allows decisions to be made to slot this demand into a single Release or RFC event.  Change Scope can be enhancement or bug fixes, business demand or operations demand.  Change Scope is added to a Release Plan, and as it matures it becomes the entry point to the what will be the RFC which is the formal change record.

When you start looking at change demand specifically, you can define the impact to systems that your change is going to impact at the single change scope level.  So, for example, if I add a change and you know that scope of this change will need “System Widget,” then System Widget is already identified for impact assessment.  If that change is slotted to a Release Plan, then the Project Team and Test teams know that System Widget has to be included in Test planning and also environment preparation.  You see how important the “Change” in a Release or RFC is.  The Change or Changes dictate your scope, impact and what will be delivered.    In addition, as scope is aligned to a Release Plan, or the RFC event, the impact is fully known as you keep building scope into the Release Plan with these relationships in mind.  In addition to system impact added to a change scope record, there are other attributes such as stakeholders, RACI, and expectations for business value and timing.   All of which help the Release Manager help pre-determine the planning for the change.

At that point, the collection of scope changes are grouped and it is a more mature change. We now have the decision point to accept that complete RFC change, or reject it, or revise it using the existing Change Process. If  authorized, we move on to more Change and Release Planning, which then lines up Environment Management for Test, Stage and Production.  I write about that substantially in other articles as well as the value of the CMDB process which aids Release Management.  But, in this event as our Change Scope is now decided, we can focus our RFC effort on the contents of the Release or the Release Build.  It is the Release Build that we are executing into the Live environment.   Because, IT Automation is being used to create the Release Build in DevOps, and the development team now addresses each change scope in their requirements, the Release becomes the single RFC as the record of change.   This process also helps the various teams do more proactive change planning. Changes are captured, aligned based on priority and timing and added to a release. The release is the Sprint or Sprints  that make up the RFC that is being processed.  One thing for sure, is the focus shifts from processing independent, smaller RFC changes to a more complete Release RFC change.  More planning and thought happens up front on what items can be bundled and delivered. From that point, once that change scope is authorized,  the sprint activities commence to the conclusion of the Change event.  This approach also works for agile or waterfall methods.

William is a certified Practitioner in IT Service Management for Release and Control, with experience in Global Change, Configuration and Release Management as well as DevOps, agile and waterfall.  He is also an experienced Project Lead in delivery, IT Automation, Application Release Automation, systems implementation, build, deployment and release practices.

This article is in a series of articles around IT Change, Configuration and Release Management using ITIL’s Foundation Framework.  Please see my other articles.    See my full profile on LinkedIn:

Copyright. William Mantz 2017. All Rights Reserved.
Classroom Image Copyright William Mantz.  Other Images used with permission from GNU, attributed to Creative Commons License,


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s