At the start of a project, we make our best educated guesses and assumptions, some of which we know will be incorrect. Our customers will also know certain things that are not valid. Through the process of doing the work, we learn more about the subject of our work and the processes we employ for our project objectives. This learning may require adapting, and change orders are the mechanism to manage those changes. In this article, we will define change orders and provide steps for how to integrate change orders in Microsoft Project.

What is a Change Order

In project management, a change order refers to a documented request that modifies a project’s original scope, schedule, or budget. It is a formal way to introduce changes to the project’s baseline plans and agreements. Change orders are typically used when there is a need to add, remove, or revise project requirements, deliverables, or constraints. Several events or circumstances can lead to the need for a change order in a project. Here are some common examples.

Scope Change

If there is a change in project requirements, objectives, or deliverables, a change order may be required to incorporate the new scope. This can occur when stakeholders’ needs or market conditions evolve, necessitating the project’s original scope adjustments.

Schedule Modification

Changes in project timelines or milestones may trigger the need for a change order. This can happen if delays, accelerated timelines, or dependencies impact the project schedule. The project plan and resources may be adjusted to accommodate the schedule change.

Resource Allocation

If there are changes in the availability, capacity, or allocation of project resources, a change order may be required. This can include modifications to the workforce, equipment, materials, or subcontractors involved in the project.

Budget Adjustment

When there are project costs or funding changes, a change order may be needed to reflect the revised budget. This can occur if cost overruns, budget cuts, additional funding sources, or changes in financial constraints impact the project’s financial plan.

Regulatory or Legal Requirements

If changes in regulatory or legal requirements affect the project, a change order may be necessary to ensure compliance. This can include changes in safety standards, environmental regulations, building codes, or other legal obligations.

Stakeholder Requests

Requests from project stakeholders for modifications or additions can trigger the need for a change order. This can include requests for new features, functionalities, or design changes that were not initially planned or accounted for.

Risk Mitigation

If unforeseen risks or issues arise during the project, a change order may be required to address them. This can involve adjustments to project plans, resources, or activities to mitigate risks and ensure project success.

Quality Assurance

Changes may be needed to improve the quality or performance of project deliverables. This can include modifications to design, materials, processes, or testing requirements to meet desired quality standards. Project managers must have a change management process to assess and evaluate potential changes. By proactively identifying and managing change requests through formal change orders, project teams can effectively respond to evolving project needs while maintaining control over scope, schedule, and budget.

Fundamentals of Change Requests and Change Management

Implementing change requests in a project requires finding the right balance between flexibility and control. The best system requires determining what matters as it pertains to the organization and the project. However, there are some fundamentals from which we can start. Below are the things that should be considered when it comes to change management: 

1. Establish a Change Control Process: Define a clear and structured change control process that outlines how change requests will be managed. Specify the criteria for evaluating and approving changes and the roles and responsibilities of team members involved in the process. This step includes designing a standard form. 
2. Document Change Requests: Encourage stakeholders to submit change requests in writing, providing detailed information about the requested changes via the Change Request form, possible impacts on project objectives, and the rationale behind the requested changes. This documented form ensures a thorough understanding of the requested changes. The project manager should review these documents with the project sponsor once Change Requests are received. The project sponsor’s guidance and support will be invaluable in the stakeholder conversation when rejecting a request. 
3. Assess the Impact: Evaluate the impact of each change request on the project’s scope, schedule, resources, and budget. Identify potential risks and benefits associated with the requested changes. Engage relevant team members, subject matter experts, and stakeholders to gather insights and make informed decisions. 
4. Prioritize Change Requests: Prioritize change requests based on their urgency, impact on project objectives, and alignment with overall Project Goals. Consider factors such as strategic alignment, stakeholder value, and feasibility when determining the priority of each change request. 
5. Evaluate Feasibility: Assess the feasibility of implementing each change request within the project’s constraints. Consider the impact on resources, budget, timeline, and potential dependencies with other project activities. It is critical to determine if the change is achievable without jeopardizing the project’s success. 
6. Analyze Risks and Mitigation Strategies: Identify potential risks for implementing the requested changes. Evaluate the impact of these risks on project outcomes and develop mitigation strategies to address them effectively. Assess whether the benefits outweigh the risks and if mitigation measures can sufficiently minimize potential negative impacts. When this step is completed, reviewing with the Project Sponsor is advisable. 
7. Communicate and Collaborate: Engage with stakeholders and communicate the evaluation outcomes and proposed decisions regarding change requests. Seek input and feedback from relevant parties to ensure transparency and promote collaboration. Address any concerns or questions raised during this process. 
8. Obtain Approval: Present the evaluated change requests, their impact analysis, and recommended decisions to the appropriate change control board or decision-making authority. Seek their approval or rejection based on the predefined criteria and governance processes. 
9. Implement Approved Changes: Once change requests are approved, update project documentation, such as the project plan, requirements, and other relevant documents, to reflect the approved changes. Communicate the changes to the project team and stakeholders, ensuring everyone knows the modifications and their implications. 
10. Monitor and Control: Continuously monitor the implementation of approved changes, tracking their impact on project objectives, timelines, resources, and risks. Ensure that the changes are implemented as planned and take corrective actions if deviations occur. 
11. Document Lessons Learned: After implementing changes, analyze the outcomes and document lessons learned. Identify what worked well and areas for improvement in the change management process to enhance future project performance. 

12 Steps to Update Schedule and Budget with Approved Changes

When integrating approved change orders, it is not as simple as updating the schedule. We need to understand the impact of the changes. This requires discussion with the various teams involved in the project and decisions on dependent actions needed to produce the desired results.

Follow these 12 steps to update your project’s schedule and budget: Assess the Change Order: Review the details of the change order, including the requested modifications and their impact on the project scope, schedule, resources, and budget. Understand the rationale behind the change order and its alignment with project objectives.

2. Evaluate the Impact: Analyze the potential impact of the change order on your project plan. Assess how it affects tasks, dependencies, milestones, and resource allocations. Determine if any adjustments need to be made to accommodate the requested changes.
3. Create a Baseline: Create a project plan baseline before implementing the change order. This allows you to compare the original plan with the modified plan once the change order is integrated.
4. Update the Project Schedule: Open your project file in Microsoft Project and navigate to the Gantt Chart or Task Sheet view. Make the necessary adjustments to the project schedule to incorporate the change order. Update task durations, dependencies, start dates, and finish dates as required.
5. Allocate Resources: Adjust resource assignments based on the change order. Assign additional resources or modify existing terms to accommodate the changes. Consider the availability and workload of resources when making adjustments. 
6. Modify Task Constraints: If the change order affects task constraints, such as start or finish dates, update these constraints accordingly. Ensure that the modified constraints align with the requested changes.
7. Adjust Task Dependencies: Modify task dependencies as needed to reflect the changes requested in the change order. Update the predecessor-successor relationships between tasks to ensure accurate sequencing.
8. Update Task Assignments: If the change order affects task assignments, update the assignments in Microsoft Project. Add or remove team members and adjust their work hours or effort estimates.
9. Revise the Project Budget: If the change order impacts project costs, update the budget accordingly. Modify cost estimates, resource rates, and other financial parameters to reflect the changes. Update the project’s cost tracking and reporting hence.
10. Track Progress and Performance: As the project progresses, monitor the impact of the change order on project performance. Compare the actual progress against the modified project plan to assess the effectiveness of the change order implementation. 
11. Communicate Changes: Communicate the integrated change order to relevant stakeholders. Ensure all team members, sponsors, and other project stakeholders know the modifications and their implications. Provide clear and timely updates to keep everyone informed.
12. Document Changes: Record the change order, including its details, approval documentation, and the resulting modifications made in Microsoft Project. Maintain a comprehensive change log to track all changes made throughout the project lifecycle.

Compare Change Orders

Our project management approach will have implications on how we manage changes. There are at least two philosophically different approaches to managing projects – conventional and Agile – in very high-level terms. In traditional project management and Agile project management, the approach to managing changes, including change orders, can differ significantly. Here’s a comparison between the two:

Conventional Project Management

1. Change Control Process: Conventional project management follows a formal and structured change control process. Change orders require detailed documentation, impact analysis, and approval from stakeholders before implementation. The emphasis is on maintaining control over changes and ensuring they align with the project’s initial plans and objectives.
2. Predictive Planning: Conventional project management relies on upfront planning and detailed requirements gathering. Change orders are seen as adjustments to the original plan and are carefully evaluated for their impacts on scope, schedule, and budget. The focus is on minimizing risks and maintaining stability in project execution.
3. Sequential Approach: Conventional project management follows a sequential or waterfall approach, completing activities in a predefined order. Changes are typically accommodated within specific change windows, and the project proceeds linearly.
4. Documentation and Formality: Change orders in conventional project management require extensive documentation, including change request forms, impact assessments, change order forms, and signoffs. The process is formal and often involves multiple levels of approval.

Agile Project Management

1. Change-Embracing Mindset: Agile project management embraces change as a natural and expected part of the project. Agile teams are prepared for changes and view them as opportunities to deliver better value to the customer. The focus is on flexibility and adaptability.
2. Iterative and Incremental Approach: Agile projects work in short iterations or Sprints, where requirements and priorities can evolve based on customer feedback. Changes are incorporated continuously, allowing for regular feedback and adjustments throughout the project.
3. Collaborative Decision-Making: Agile projects involve close collaboration between the development team and stakeholders. Change decisions are often made collectively, with team members and stakeholders working together to prioritize and implement changes that provide the most value.
4. Lightweight Documentation: Agile projects prioritize working software over comprehensive documentation. While change requests and their impacts are tracked, the emphasis is on effective communication and direct interactions rather than extensive paperwork.
5. Adaptive Planning: Agile projects utilize adaptive planning, incorporating changes as the project progresses. The focus is on delivering incremental value and responding quickly to changing requirements and market conditions.

6. Continuous Improvement: Agile projects emphasize learning and constant improvement. Changes are welcomed as opportunities for learning and adjusting project direction based on new insights.
7. Product Backlog: Changes will be put onto the product backlog for future actions, even during a Sprint (the time the team works to accomplish the immediate goals). During the Sprint, changes are not accepted.

Overall, conventional project management follows a more controlled and formal approach to change orders, focusing on stability and minimizing risks. In contrast, Agile project management embraces change, prioritizes flexibility, and seeks to deliver value through iterative and incremental development. Agile’s approach to change orders is more adaptive, collaborative, and lightweight regarding documentation.

Summary

If we do not manage the changes to our work, we will be driven by these ad hoc changes, plagued by rework, over budget, and going beyond the expected schedule. It is not just the project manager that requires an understanding of the implications of the change, but the project sponsor and indeed the customer. The effort we make to understand the change implications will ripple to the customer so their expectation will match reality. This brings us to a discussion of project baselines, which we will cover in a future article, so stay tuned!

Related Content

How to Make Your Project Scoping Process Insanely Accurate

Integrated Change Control

A Resource Leveled and Smoothed Schedule