Implementing Basic IT Change Management is a great place to start, but eventually you’ll need a more business-value focused process. In this article I’ll tell you how to take the next step in maturing your Change Management program.
The Basic IT Change Management Process I described earlier helps get control of what’s happening in your IT environment. Kind of a stop-the-bleeding. But the value of the basic Change process is limited to reducing negative impact from changes.
Evaluating changes as simply a last-ditch effort to make sure things don’t get screwed up has limited strategic business value.
On the other hand, some approaches to IT Change Management have changes coming to CAB five distinct times. For most organizations, starting there is too much too soon.
What’s needed is a more mature “middle ground” process. I think of it as moving upstream to improve what’s flowing down stream.
Movin’ on up (stream)…
The time to review and validate a proposed course of action is before work begins. It just makes sense.
Once the business has made a request, and initial requirements have been gathered, it’s time to draft a proposed solution to meet the requirements. The plan should be documented in enough detail that it can be understood and reviewed by technical staff and IT decision makers.
The step we’re adding is bringing a documented plan to the CAB for a formal review before work begins.
The goal is to think through the proposed solution and identify any potential problems or likely unintended consequences. Making adjustments before work starts minimizes unnecessary rework and downstream problems.
The review needs to be done by well qualified staff, who are together looking at the big picture. Consider:
- Are the desired business outcomes well understood and documented (and has the business approved)?
- Is it understood how the change will impact existing business and IT processes?
- How will the proposed change impact existing services?
- Is the data involved used by other services, and will the proposed change effect that?
- Will the infrastructure support the change (network bandwidth, firewall rules, server capacity, etc)?
- Does it follow established technical and architectural standards?
- Does it introduce new technologies, and if so, are we prepared to support them?
- Does it add unnecessary complexity (is there a simpler solution)?
- Does the organization have the knowledge, experience, and capacity to deliver the proposed solutions (does the proposal describe how these will be accomplished – training, partnerships, consulting, etc?)
- Is the business likely to realize the desired outcomes?
Adding Control to Basic IT Change Management
Change Management is intended to be a control process, with the responsibility (and authority) to ensure what moves forward is business aligned, and does not pose undue risk to the business.
We are adding a formal step that provides a clear separation between change planning and change build, and change implementation.
Once CAB has completed it’s review, the Change Manager will either approve the change to move into execution (build) or reject it for further planning.
Once the Change has been built and tested, it comes back to CAB for a final review before authorization to release into production is given.
This second review can now focus on:
- Does the Change meet the stated business outcomes (Does the testing verify it?)
- Has the build and test process identified any additional risks, and have they been addressed?
- Is the business ready for the change at the proposed time (has there been effective communication)?
- Is the Implementation Plan complete, and are IT staff trained and prepared for a successful implementation?
Adding Business Value
I’ve seen Changes allowed to go into production with known issues simply because “so much time has been invested“, and “the business needs it now“. Had these Changes been reviewed before building, the issues could have been avoided altogether.
I’ve also seen unplanned infrastructure changes made literally at the last minute, because a change wasn’t compatible with another component (i.e. the new application won’t run on the production OS version, so we have to upgrade).
I call these “Extortion Changes”, and they pose significant risk because they typically bypass all normal planning and testing. They can also cause collateral damage to other services, causing a cascade of unplanned changes in production.
Benefits
- More changes fulfill the desired business outcome → Increased customer satisfaction
- Faster time-to-value of changes → More on-time delivery of projects
- Less rework of changes → More labor available for value-add work
- Fewer post-implementation Incidents → Higher Service Availability
- Increased Services and infrastructure stability → More IT staff time for value-add work
- Increased IT team collaboration across silos → More focus on business value (See IT Value is Created Horizontally)
Moving Change Management upstream to a proactive business-value focused position helps IT better align with the business. Less IT labor is spent on non value-add work, and changes are implemented more quickly, with less Incidents.
If you are just starting formal Change Management, take a look at How to Implement Basic IT Change Management, and when you’re ready, add the steps described here. You may also be interested in How to Measure a Basic IT Change Management Process.
A flowchart for the more Advanced Basic IT Change Management process can be downloaded from the Free Downloads page.
While I appreciate and encourage scheduling planned changes far in advance, example is a system upgrade in 6 months, I do not believe an RFC should be brought to CAB during the “ideation” phase. That’s a business customer, technology, Portfolio, Enterprise Architecture, Procurement, and Finance decision.