Improvement can be incremental. You do not have to adopt every recommended improvement right away. Ensure every process change you make will create value and slowly add improvements to ease buy-in.
Besides the small introduction, subscribers and consulting clients within this management domain have access to:
Use this storyboard as a guide to align projects with your IT change management lifecycle.
Use this SOP as a template to document and maintain your change management practice.
Focus on frequent and transparent communications between the project team and change management. |
Misalignment between IT change management and project management leads to headaches for both practices. Project managers should aim to be represented in the change advisory board (CAB) to ensure their projects are prioritized and scheduled appropriately. Advanced notice on project progress allows for fewer last-minute accommodations at implementation. Widespread access of the change calendar can also lead project management to effectively schedule projects to give change management advanced notice. Moreover, alignment between the two practices at intake allows for requests to be properly sorted, whether they enter change management directly or are governed as a project. Lastly, standardizing implementation and post-implementation across everyone involved ensures more successful changes and socialized/documented lessons learned for when implementations do not go well. Benedict Chang |
Your Challenge |
Common Obstacles |
Info-Tech’s Approach |
---|---|---|
To align projects with the change lifecycle, IT leaders must:
|
Loose definitions may work for clear-cut examples of changes and projects at intake, but grey-area requests end up falling through the cracks. Changes to project scope, when not communicated, often leads to scheduling conflicts at go-live. Too few checkpoints between change and project management can lead to conflicts. Too many checkpoints can lead to delays. |
Set up touchpoints between IT change management and project management at strategic points in the change and project lifecycles. Include appropriate project representation at the change advisory board (CAB). Leverage standard change resources such as the change calendar and request for change form (RFC). |
Improvement can be incremental. You do not have to adopt every recommended improvement right away. Ensure every process change you make will create value, and slowly add improvements to ease buy-in.
This deck is intended to align established processes. If you are just starting to build IT change processes, see the related research below.
Align Projects With the IT Change Lifecycle |
01 Optimize IT Change Management | |
---|---|---|
Increase the success of your changes by integrating project touchpoints in your change lifecycle. (You are here) |
Decide which IT projects to approve and when to start them. |
Right-size IT change management to protect the live environment. |
IT Benefits |
Business Benefits |
---|---|
|
|
IT satisfaction with change management will drive business satisfaction with IT. Once the process is working efficiently, staff will be more motivated to adhere to the process, reducing the number of unauthorized changes. As fewer changes bypass proper evaluation and testing, service disruptions will decrease and business satisfaction will increase.
Control |
Collaboration |
Consistency |
Confidence |
---|---|---|---|
Change management brings daily control over the IT environment, allowing you to review every relatively new change, eliminate changes that would have likely failed, and review all changes to improve the IT environment. |
Change management planning brings increased communication and collaboration across groups by coordinating changes with business activities. The CAB brings a more formalized and centralized communication method for IT. |
Request-for-change templates and a structured process result in implementation, test, and backout plans being more consistent. Implementing processes for pre-approved changes also ensures these frequent changes are executed consistently and efficiently. |
Change management processes will give your organization more confidence through more accurate planning, improved execution of changes, less failure, and more control over the IT environment. This also leads to greater protection against audits. |
Both changes and projects will end up in change control in the end. Here, we define the intake.
Changes and projects will both go to change control when ready to go live. However, defining the governance needed at intake is critical.
A change should be governed by change control from beginning to end. It would typically be less than a week’s worth of work for a SME to build and come in at a nominal cost (e.g. <$20k over operating costs).
Projects on the other hand, will be governed by project management in terms of scope, scheduling, resourcing, etc. Projects typically take over a week and/or cost more. However, the project, when ready to go live, should still be scheduled through change control to avoid any conflicts at implementation. At triage and intake, a project can be further scoped based on projected scale.
This initial touchpoint between change control and project management is crucial to ensure tasks and request are executed with the proper governance. To distinguish between changes and projects at intake, list examples of each and determine what resourcing separates changes from projects.
Need help scoping projects? Download the Project Intake Classification Matrix
Change |
Project |
---|---|
|
|
While effort and cost are good indicators of changes and projects, consider evaluating risk and complexity too.
Change | Project | Service Request (Optional) | Operational Task (Optional) | Release (Optional) |
---|---|---|---|---|
Changing Configuration | New ERP | Add new user | Delete temp files | Software release |
Download the Change Management Standard Operating Procedure (SOP).
Input | Output |
---|---|
|
|
Materials | Participants |
|
|
CAB touchpoints
Consistently communicate the plan and timeline for hitting these milestones so CAB can prioritize and plan changes around it. This will give change control advanced notice of altered timelines.
RFCs
Projects may have multiple associated RFCs. Keeping CAB appraised of the project RFC or RFCs gives them the ability to further plan changes.
Change Calendar
Query and fill the change calendar with project timelines and milestones to compliment the CAB touchpoints.
The request for change (RFC) form does not have to be a burden to fill out. If designed with value in mind, it can be leveraged to set standards on all changes (from projects and otherwise).
When looking at the RFC during the Build and Test phase of a project, prioritize the following fields to ensure the implementation will be successful from a technical and user-adoption point of view.
Filling these fields of the RFC and communicating them to the CAB at go-live approval gives the approvers confidence that the project will be implemented successfully and measures are known for when that implementation is not successful.
Download the Request for Change Form Template
Communication Plan The project may be successful from a technical point of view, but if users do not know about go-live or how to interact with the project, it will ultimately fail. |
Training Plan If necessary, think of how to train different stakeholders on the project go-live. This includes training for end users interacting with the project and technicians supporting the project. |
Implementation Plan Write the implementation plan at a high enough level that gives the CAB confidence that the implementation team knows the steps well. |
Rollback Plan Having a well-formulated rollback plan gives the CAB the confidence that the impact of the project is well known and the impact to the business is limited even if the implementation does not go well. |
Inputs
Guidelines
Roles
Info-Tech Insight
Make the calendar visible to as many parties as necessary. However, limit the number of personnel who can make active changes to the calendar to limit calendar conflicts.
As optional CAB members
Project SMEs may attend when projects are ready to go live and when invited by the change manager. Optional members provide details on change cross-dependencies, high-level testing, rollback, communication plans, etc. to inform prioritization and scheduling decisions.
As project management representatives
Project management should also attend CAB meetings to report in on changes to ongoing projects, implementation timelines, and project milestones. Projects are typically high-priority changes when going live due to their impact. Advanced notice of timeline and milestone changes allow the rest of the CAB to properly manage other changes going into production.
As core CAB members
The core responsibilities of CAB must still be fulfilled:
1. Protect the live environment from poorly assessed, tested, and implemented changes.
2. Prioritize changes in a way that fairly reflects change impact, urgency, and likelihood.
3. Schedule deployments in a way the minimizes conflict and disruption.
If you need to define the authority and responsibilities of the CAB, see Activity 2.1.3 of the Optimize IT Change Management blueprint.
Verification |
Once the change has been implemented, verify that all requirements are fulfilled. |
---|---|
Review |
Ensure all affected systems and applications are operating as predicted. |
Update change ticket and change log |
Update RFC status and CMDB as well (if necessary). |
Transition |
Once the change implementation is complete, it’s imperative that the team involved inform and train the operational and support groups. |
If you need to define transitioning changes to production, download Transition Projects to the Service Desk
Conduct PIRs for failed changes. Successful changes can simply be noted and transitioned to operations.
It’s best to perform a PIR once a change-related incident is resolved.
Include a root-cause analysis, mitigation actions/timeline, and lessons learned in the documentation.
Socialize the findings of the PIR at the subsequent CAB meeting.
If a similar change is conducted, append the related PIR to avoid the same mistakes.
Info-Tech Insight
Include your PIR documentation right in the RFC for easy reference.
Download the RFC template for more details on post-implementation reviews
Download the Change Management Standard Operating Procedure (SOP).
Input | Output |
---|---|
|
|
Materials | Participants |
|
|
Right-size IT change management to protect the live environment. |
Optimize IT Project Intake, Approval, and Prioritization Decide which IT projects to approve and when to start them. |
Maintain an Organized Portfolio Align portfolio management practices with COBIT (APO05: Manage Portfolio). |