Scope and Change Management in PM²: changing deliberately, not by inertia
Seventeenth article in the “Learning PM² Through a Project” series
Scope is not the list of things a team thinks it will do. It is the approved boundary of the project: deliverables, requirements, limits, assumptions and criteria that establish what the project will and will not produce.
Changing scope is not failure. New needs, constraints and opportunities normally emerge. The problem begins when change enters the project without an explicit decision about its impact.
Scope: inclusion also means exclusion
A sound scope makes four aspects visible:
| Element | Question |
|---|---|
| Deliverables | What will be produced and handed over? |
| Requirements | Which capabilities, rules and constraints must be met? |
| Boundaries | What explicitly remains outside the project? |
| Acceptance criteria | How will we prove that the result is acceptable? |
Saying “we will build booking management” leaves everything open. Saying “web and app release for booking, cancellation and waiting-list management, without integration with physical turnstiles in the first release” makes the boundary discussable, estimable and governable.
Scope creep: the risk of small additions
Scope creep is the gradual, uncontrolled expansion of scope. It often starts with seemingly harmless requests:
- “let’s just add one field”;
- “it is a quick change”;
- “while we are at it”;
- “there is no need to formalise it”.
Each individual addition may be small; the cumulative effect can consume capacity, delay release, increase defects and remove attention from priority benefits.
Change Management: the correct process
In PM², a change request modifies an approved project element: a requirement, scope, plan, cost, schedule, organisation, deliverable or another baseline item.
The essential cycle is:
flowchart LR
A[Request] --> B[Log in Change Log]
B --> C[Impact assessment]
C --> D[Competent authority decision]
D -->|Approved| E[Update baseline and communicate]
D -->|Rejected or deferred| F[Record outcome and rationale]
E --> G[Implement and verify]
Logging does not create bureaucracy for its own sake. It preserves the request’s rationale, alternatives, decision-maker and resulting plan changes.
Impact assessment is not only a technical estimate
Before deciding, consider at least these dimensions:
| Dimension | Example question |
|---|---|
| Value and priority | Which benefit does it add? Is it more important than what it displaces? |
| Scope and requirements | Which requirements, acceptance criteria and deliverables change? |
| Schedule and dependencies | Does it move dates, milestones or external dependencies? |
| Effort, cost and resources | Who must work on it, and what will they not be able to do? |
| Quality and risk | Does it introduce complexity, regression, security or new constraints? |
| Adoption and communication | Does it change training, procedures or user expectations? |
The decisive question is not “can we do it?” but “is it worth doing now, under these conditions, compared with the alternatives?”
Fixing, clarifying, changing: three different cases
| Case | Example | Treatment |
|---|---|---|
| Defect | The waiting list does not promote the next user as specified. | Correct implementation against the approved requirement. |
| Clarification | A requirement says “configurable time” and it is defined that the unit is minutes. | Document the detail if it does not alter the underlying agreement. |
| Change | The manager requests waiting-list priority based on membership type, which was not planned. | Log, impact-assess and decide. |
Do not label something “only a clarification” to avoid a decision. If it changes the result, rules, effort or baseline, it is a change.
Who decides?
The PM coordinates the process: captures the request, ensures assessment, prepares options and updates documents after the decision. The PM does not automatically decide every change.
Authority depends on agreed governance and delegation:
| Impact type | Typical decision |
|---|---|
| Within PM tolerances and delegation | PM, with traceability and communication. |
| Affects business priorities, benefits or material requirements | PO/BM and, if necessary, PSC. |
| Affects solution feasibility, capacity or quality | SP involved in assessment and relevant decision. |
| Changes budget, mandate or a significant commitment | PSC/AGB, according to project rules. |
The exact threshold is not universal; it should be defined in the Project Handbook, relevant plans or governance mandate.
The Annotatio case: CSV export of attendance
For Smart Bookings, the baseline includes bookings, cancellations, a waiting list and an occupancy dashboard. Two weeks before go-live, the manager asks for a CSV export of attendance “because it would be very useful”.
A serious assessment might produce:
| Option | Impact | Possible decision |
|---|---|---|
| Include in the release | +5 days; new tests and guide update; go-live risk. | Approve only by moving the date. |
| Substitute a lower-priority feature | Date unchanged, but an existing requirement moves out. | PO/BM decide the trade-off. |
| Plan it for the next release | Go-live protected; value postponed. | Log and communicate the deferral. |
“Yes, it is useful” is not enough to decide. Change management makes the price visible and lets the authority choose which value to favour.
Do not confuse these
| Statement | Correction |
|---|---|
| “Every change is a problem.” | A change can increase value; it must be assessed and decided. |
| “If it is small, it need not be logged.” | Size does not remove cumulative impact or the need for traceability. |
| “The Change Log is only for approved changes.” | It also records rejected, deferred or withdrawn requests and their rationale. |
| “Approval is the last step.” | After approval, baselines, plans, communications and verification must be updated. |
Three questions to anchor it
- Which approved item would this request change?
- What would we have to stop doing if we included it now?
- Who has authority to accept the trade-off?
Flashcards
Q: What is scope creep?
A: The gradual, uncontrolled expansion of scope through additions that are not assessed or approved.
Q: What must happen before implementing a change?
A: Logging, impact assessment, competent decision and controlled baseline update.
Q: Is the PM always the authority that approves changes?
A: No. It depends on governance, delegation and impact.
Exam-style question
A user requests a new booking-priority rule. The team can develop it in two days with no external costs. The PM authorises development immediately, without updating documentation or informing the PO.
What is the main error?
Answer: technical ease does not replace Change Management. The new rule may change fairness, user experience, acceptance criteria, tests and business priorities. The request should be logged, assessed and decided by the competent authority before the baseline is updated and implementation begins.
Source
Change Management, the Change Management Plan and Change Log are covered in the European Commission’s PM² Methodology Guide 3.1.
Next: Risk Management, for anticipating uncertain events rather than merely chasing problems that have already happened.