2.10.1 Anticipate and Embrace the Need for Change
(E.G., Follow change management practices)
Changes to projects are inevitable.
Work is conducted over a life cycle in which the market, technology and stakeholder requests continue to evolve. Denying all changes would make managing projects simpler, but that is not a luxury project managers have.
Many things lead to project changes.
Causes of Project Changes
Common sources of changes include:
- Missed Requirements – Items that were not captured initially but are now obviously needed. “Not only should pressing the power button switch on the hover-bike, but pressing it again should switch it off.”
- New Regulations – Laws and policies change over time; these may lead to project scope changes. “All Hover bikes must come with Wear-a-helmet stickers”
- Specification Changes – Sometimes requirements change or testing reveals the need to change a specification. “Upon testing, the hover-bike should default hover at 15cm (6”) to avoid common obstacles such as curbs”
- Inaccurate Initial Estimates – Sometimes, the original estimate for work is wrong, and as more is learned about the tasks involved, changes to the estimates and schedules are required. “Bill’s “10 minute” fix to the hill-stalling problem is in week 2 of development and is now re-estimated as a 4-week delay.”
- Market Competition – Sometimes, competitor product releases or changing perceptions, force rethinks to the original business case or project scope. “Mega-Smash-Bikes have launched a $999 hover-bike that will do 80 km/h (50 mph). We need to match or exceed this speed and hire more lawyers.”
2.10.2 Determine Strategy to Handle Change
We need to manage project changes. How we do this varies on the development approach being used.
Traditional project management approaches have mechanisms to control changes that attempt to limit the number of changes so that only the most critical are accepted.
- This is good for preserving the original plans and baselines.
- It is problematic when there are high rates of change.
Agile approaches are more welcoming to changes and continuously reprioritize the backlog to reflect remaining work urgencies and change requests.
- This is good when everyone understands the flexibility of the approach
- It is problematic if people are expecting a largely unchanging upfront plan
Hybrid approaches try to bridge the large divide between attempts to freeze upfront plans and an ongoing free-for-all of scope evolution. They use lightweight versions of traditional scope and planning artifacts such as Vision and Scope Statements.
Then they gain formal agreement on the core scope of high-level release plans. Finally, they empower a Product Owner(PO) to manage scope evolution within the agreed scope boundary but require escalation to a Change Control Board(CCB) if any change or trend threatens to breach the agreed scope plans.
This way, the PO can manage day-to-day changes that emerge from learning more about a product or service without the cost and delays of a formal CCB. Yet, the stakeholders know if anything major comes up that could threaten the approved project, it will be escalated for wider consideration.
- This is good for facilitating minor changes with minimal delays and low cost
- It is problematic since the tolerances for what constitutes “managed by the PO” and “requiring escalation” will vary from project to project, along with the escalation steps and CCB.
2.10.3 Execute Change Management Strategy According to the Methodology
Let’s start our explanation of managing changes with a review of how traditional, plan-driven projects manage change.
Predictive, plan-driven project life cycles define how they will handle changes in a Change Management Plan.
Change Management Plan
This document explains how the change control process works and documents the roles and responsibilities of the change control board (CCB).
Organizational culture directly influences how an organization manages changes to a project.
An organization in a highly regulated environment tends to have a cautious, formal, and rigid culture. This leads to rigorous change management procedures, perhaps with multiple levels of approval. Organizations operating in new or rapidly evolving environments tend to have a lighter-touch approach to change.
The change management plan describes how changes will be managed and may include:
- Approval levels for changes
- The structure of the Change Control Board, if one is used
- The change control process
- The tools used to track and communicate change decisions
- The emergency change process
Change Control Boards
A Change Control Board (CCB) is a formally chartered group responsible for reviewing, evaluating, approving, deferring, or rejecting changes to the project. The board represents key stakeholders for the project and is tasked with assessing changes in terms of cost, schedule, risk, and value impact. They are created to manage all project change requests fairly.
A Change Control Board (CCB) may meet on-demand for high-priority requests or on a regular schedule, such as once a week or once a month. In addition to deciding on project changes, they are also responsible for recording and communicating such decisions.
Once a decision has been made by the CCB, the scope of the change is compared to the established tolerance thresholds. Changes within thresholds can be approved and initiated by the project manager. Changes outside of tolerance thresholds usually require the project sponsor to approve the change.
Now let’s see how Agile life cycle projects undertake these activities.
Product Owner as a Change Control Board
Agile approaches are often used in high change environments where many scope and trade-off decisions need to be made daily. In these situations, getting the change control board together, bringing them up to speed about the issue or request and letting them discuss and debate the pros, cons and various options would just take too long.
Instead, the Product Owner is empowered by the business to make scope, priority and change decisions on behalf of the sponsor. They are trusted to do the right thing, act on behalf of the business and customers and manage the bulk of all change decisions themselves. Unless a change would materially impact the outcome of the project, the Product Owner approves, rejects and defers changes daily.
Product Owners often consult with the Scrum Master / team lead and members of the team to get information about estimates, dependencies and risks but otherwise have the autonomy to make project decisions.
2.10.4 Determine a Change Response to Move the Project Forward
As the project progresses, we need to continuously monitor change requests, risks, issues, and team performance. Then based on these factors and customer/sponsor guidance, update our plans to deliver project outcomes and comply with our organization’s agreed procedures.
Traditional projects manage compliance and change through the process known as Integrated Change Management.
Integrated Change Management
When a potential change is identified, it is sent to the Change Control Board (CCB), which evaluates it. The CCB will assess the change to see if it is in scope as defined by the charter and evaluate its options. Finally, the CCB will decide, update the change request status, and communicate their decision to the relevant stakeholders.
If the change was approved, the project manager can start updating and re-baselining the plans. The change is then actioned through the execution of the revised plans. The main components of this process are shown below.
Changes and the Backlog
Using agile approaches, the Product Owner is responsible for conducting similar steps as identified in the Integrated Change Management approach shown above, just by themselves and with less documentation. In addition, the Product Owner monitors the internal and external business environment, looking out for opportunities, threats and change requests that might impact the project.
When a potential change is identified, they evaluate it, consulting with other stakeholders such as customers and team members to gather the required information. Then decide whether to decline, defer or approve the change. If approved, they assign a priority and put it in the backlog, displacing lower priority items down the backlog. This process is depicted in the animation below.
The animation shows a “water-line” of agreed to work below the original backlog. If we accept a change the Product Owner and other stakeholders must accept that it displaces a similar sized piece of work with a lower priority.
We can accept changes, even late in the life cycle sometimes, but we cannot defy the laws of time and space. An important note about agile projects is that all work goes in the backlog. We do not maintain a separate list of change requests or defect fixes. Everything lives in the backlog, so priorities and remaining work is visible to everyone.
Backlog Reprioritization
In addition to new requests or changes being introduced into the product backlog, Product Owners also reprioritize items in the backlog as priorities change.
Using the processes described in this module, project managers conduct planning throughout the project, whichever life cycle is adopted.
For a full explanation of how agile approaches manage changes, see the exclusive Agile Primer chapter (pages 16 – 38) in the PM Illustrated book.
Deliverables and Tools
- Change Requests
- Product Backlog
- Risk Register
- Issues Log
- Stakeholder Register
- PMIS
- Communicate with stakeholders
Related Topics
- 1.9 Collaborate with stakeholders
- 2.1 Execute project with the urgency required to deliver business value
- 2.2 Manage communications
- 2.3 Assess and manage risks
- 2.4 Engage Stakeholders
- 2.5 Plan and manage budget and resources
- 2.6 Plan and manage schedule
- 2.7 Plan and manage quality of products/deliverables
- 2.8 Plan and manage scope
- 2.9 Integrate project planning activities
- 2.11 Plan and manage procurement
- 2.12 Manage project artifacts
- 2.13 Determine appropriate project methodology and practices
- 2.14 Establish project governance structure
- 2.15 Manage project issues
- 3.3 Evaluate and address external business environment changes
Further Reading
- Article: Typical Rates of Change on Different Project Types
- Article: Agile backlog Prioritization Approaches
- Book: PM Illustrated – Agile Primer, pages 16 – 38
Congratulations! You scored 100% and won the 2.10 Manage Change Badge.