- Coordinate IT change and project management to successfully push changes to production.
- Manage representation of project management within the scope of the change lifecycle to gather requirements, properly approve and implement changes, and resolve incidents that arise from failed implementations.
- Communicate effectively between change management, project management, and the business.
Our Advice
Critical Insight
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.
Impact and Result
- Establish pre-set 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).
Align Projects With the IT Change Lifecycle Research & Tools
Besides the small introduction, subscribers and consulting clients within this management domain have access to:
1. Align Projects With the IT Change Lifecycle Deck – A guide to walk through integrating project touchpoints in the IT change management lifecycle.
Use this storyboard as a guide to align projects with your IT change management lifecycle.
- Align Projects With the IT Change Lifecycle Storyboard
2. The Change Management SOP – This template will ensure that organizations have a comprehensive document in place that can act as a point of reference for the program.
Use this SOP as a template to document and maintain your change management practice.
- Change Management Standard Operating Procedure
Further reading
Align Projects With the IT Change Lifecycle
Increase the success of your changes by integrating project touchpoints in the change lifecycle.
Analyst Perspective
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 |
Executive Summary
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). |
Info-Tech Insight
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.
Info-Tech’s approach
Use the change lifecycle to identify touchpoints.
The Info-Tech difference:
- Start with your change lifecycle to define how change control can align with project management.
- Make improvements to project-change alignment to benefit the relationship between the two practices and the practices individually.
- Scope the alignment to your organization. Take on the improvements to the left one by one instead of overhauling your current process.
Use this research to improve your current process
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. |
Successful change management will provide benefits to both the business and IT
Respond to business requests faster while reducing the number of change-related disruptions.
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.
Change management improves core benefits to the business: the four Cs
Most organizations have at least some form of change control in place, but formalizing change management leads to the four Cs of business benefits:
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. |
1. Alignment at intake
Define what is a change and what is a project.
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 |
|---|---|
|
|
Info-Tech Insight
While effort and cost are good indicators of changes and projects, consider evaluating risk and complexity too.
1 Define what constitutes a change
- As a group, brainstorm examples of changes and projects. If you wish, you may choose to also separate out additional request types such as service requests (user), operational tasks (backend), and releases.
- Have each participant write the examples on sticky notes and populate the following chart on the whiteboard/flip chart.
- Use the examples to draw lines and determine what defines each category.
- What makes a change distinct from a project?
- What makes a change distinct from a service request?
- What makes a change distinct from an operational task?
- When do the category workflows cross over with other categories? (For example, when does a project interact with change management?
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 |
|
|
2. Alignment at build and test
Keep communications open by pre-defining and communicating project milestones.
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.
Leverage the RFC to record and communicate project details
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. |
Provide clear definitions of what goes on the change calendar and who’s responsible
Inputs
- Freeze periods for individual business departments/applications (e.g. finance month-end periods, HR payroll cycle, etc. – all to be investigated)
- Maintenance windows and planned outage periods
- Project schedules, and upcoming major/medium changes
- Holidays
- Business hours (some departments work 9-5, others work different hours or in different time zones, and user acceptance testing may require business users to be available)
Guidelines
- Business-defined freeze periods are the top priority.
- No major or medium normal changes should occur during the week between Christmas and New Year’s Day.
- Vendor SLA support hours are the preferred time for implementing changes.
- The vacation calendar for IT will be considered for major changes.
- Change priority: High > Medium > Low.
- Minor changes and preapproved changes have the same priority and will be decided on a case-by-case basis.
Roles
- The Change Manager will be responsible for creating and maintaining a change calendar.
- Only the Change Manager can physically alter the calendar by adding a new change after the CAB has agreed upon a deployment date.
- All other CAB members, IT support staff, and other impacted stakeholders should have access to the calendar on a read-only basis to prevent people from making unauthorized changes to deployment dates.
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.
3. Alignment at approval
How can project management effectively contribute to CAB?
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.
4. Alignment at implementation
At this stage, the project or project phase is treated as any other change.
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
5. Alignment at post-implementation
Tackle the most neglected portion of change management to avoid making the same mistake twice.
- Define RFC statuses that need a PIR
- Conduct a PIR for every failed change
- Avoid making the same mistake twice
- Report to CAB
- Circle back on previous PIRs
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
2 Implement your alignments stepwise
- As a group, decide on which implementations you need to make to align change management and project management.
- For each improvement, list a timeline for implementation.
- Update section 3.5 in the Change Management Standard Operating Procedure (SOP). to outline the responsibilities of project management within IT Change Management.
Download the Change Management Standard Operating Procedure (SOP).
| Input | Output |
|---|---|
|
|
| Materials | Participants |
|
|
Related Info-Tech Research
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). |