Step 9: Control Changes to the Scope

Changes will happen — always. The question is not if, but how you handle them. Without control, the scope swells and the project slips; with control, every change is a conscious decision. This step brings together controlling the scope and performing integrated change control.

The goal is to make sure the project includes all the work required — and only that. Changes usually arrive to meet new stakeholder expectations, but a common mistake is to underestimate their impact in order to “exceed the customer’s expectations”. Every change has a cost and it must be accounted for: there is no free lunch. I have seen projects sink because the manager did not know how to say no.

The flow of a change

1. Request for the change (what changes and why);
2. Review of the impact on cost, schedule and risks, and of the benefits it produces;
3. Approval (or rejection), following the integrated control flow defined in the plan (Step 5);
4. Replanning that takes the change into account;
5. Execution, control and monitoring of the change;
6. Closing the deliverable that includes the change.

It is essential to make sure approved changes are beneficial — that their benefits outweigh their costs and add value to the objectives. A change also affects the planning processes and their documents, and it must be communicated clearly to the team. Every change, approved or rejected, must be recorded.

The boundary: progressive elaboration before, change after

Adding scope is not always a change — and confusing the two is what turns a project into bureaucracy or, at the other extreme, makes it grow with nobody noticing. The boundary has a clear marker: the baseline approved in Step 5.

• Before approval, the detail that appears as you get close to the work is progressive elaboration — that is normal planning, and its home is Step 2. Nobody has to authorize you to see more clearly.
• After approval, the same gesture is a change: there is an approved plan to measure against, and it only moves with an assessed impact, a recorded decision and a new baseline.

That is why this step is on demand and can be triggered at any moment of the project: it is not a stage you complete and leave behind, it is the process you trigger every time somebody asks for something different from what was approved.

On your board (ProjectAdm): the three rounds of Step 9

Record each request as a card in the Changes list. In the course package, Step 9 happens in three rounds — and the separation between them is exactly what stops the scope from growing on its own:

1. You describe what changed. The step asks what the request is and what you want the AI to detail; it hands back the impact analysis prompt ready, with the picture of your board already inside.
2. The change becomes a card. You paste the AI’s answer into the “0. Inbox” card and the card MC-001 is born (MC-002, MC-003… — the code is the stable handle for that change), with the request, the impact dimension by dimension and the recommendation. The board does not change yet: the detail stays inside the card, waiting for whoever decides.
3. The sponsor’s decision. You record approved, rejected or deferred, with who decided and why. Only on approval does the detail become plan — and a new baseline is captured.

The AI brings the change already detailed (predictive approach)

An approved change is not just a card saying “it costs 12 days”: it brings new scope — and new scope has a work package, an acceptance criterion, a risk, a date and a cost, exactly like the original plan. Instead of making you redo Steps 2, 3 and 4 (and rewrite what was already fine), Step 9 asks the AI to detail only the change.

In the first round you switch each piece of the detail on and off — and you do not have to edit any prompt for that:

• Scope — the new deliverables and work packages, with acceptance criteria, and where each one fits into your WBS;
• Risks — what is born or grows because of the change (the same format as Step 3);
• Schedule — duration, dates, owner and dependencies of the new items;
• Budget — the costs the change adds (or removes).

Answered “no” to risks? The prompt goes out without that part, and the AI does not invent work you did not ask for. The answer comes back in separate blocks — [P9] for the impact and [P9.2], [P9.3] and [P9.4] for the detail — which the step keeps inside the change card until the decision is made.

Where the new deliverable fits in the WBS — and why the codes change

A new deliverable almost never belongs at the end of the list: it goes inside a phase that already exists, next to its siblings, in the sequence in which the work happens. That is why the detail states the position by WBS code — “after 2.1” — and the course actually inserts it there, on your board. If the change creates a whole phase, that is born in the indicated position too.

And then what has to happen, happens: everything that came after moves up a number. If the new deliverable takes 2.2, the old 2.2 becomes 2.3 — and its packages follow (2.2.1 becomes 2.3.1). The course shows the renumbering item by item and updates everything that depends on it by itself: the WBS Code field on each card, the code in the title of the execution tasks (↳ 2.3 · …) and all of your documents — the WBS Dictionary, the schedule, the Project Management Plan.

An approved change is a new baseline

Approving a change means the approved plan is now a different plan. Without capturing the new baseline, Step 8 keeps comparing the actuals against a reference that is no longer true — and your planned × actual becomes fiction. So, when you apply the change, the course offers to capture the new baseline right there, with the change code in its name (“Baseline — MC-001 approved”).

And what if you need to discard a baseline — because it froze a plan that no longer exists, or because it was captured by mistake? Keeping the baseline is good practice, not a law of nature: the decision belongs to the project leader. Step 9 shows every baseline on the board, lets whoever leads choose which one to discard, and records the decision — who, when and why. From then on the project measures against the baseline that remains in force.

Critical success factors of monitoring and control

• Monitor and control according to the project plan;
• Issue the Status Report periodically;
• Follow the change approval process and, if approved, update the plan and the affected documents;
• A proactive governance process and documentation of the issues.

Predictive × Agile

In the Predictive approach, change is controlled through a formal request-and-approval process — which is where the three rounds, the detail and the new baseline described above live.

In the Agile approach, you start from the principle that changing is natural. Instead of blocking the change, the Product Owner reorders the Product Backlog every Sprint, putting what has become more valuable at the top. Control comes from the timebox: the scope of a Sprint in progress is protected; new demands go into the next one. That is why, in agile, Step 9 does not detail deliverable, date and cost: the change becomes a new order in the backlog, and whoever details it is Sprint Planning (Step 5), when the item comes up. The step delivers the impact analysis and the refinement of the backlog — what comes in, and above all what goes out or moves down to fit.

🎯 Your turn — Control changes

🎯 Objective: approve only the changes that add value — and make sure the approved ones are planned, communicated and executed.

✅ Before you start: the change approval flow defined in the plan (Step 5) and monitoring up to date (Step 8).

🗃️ On your board: record each request as a card in the Changes list.

📋 Checklist:

1. Run Step 9 and describe the request (what changes and why); choose what the AI should detail.
2. Paste the answer into the board: the change card (MC-001) is born with the impact on cost, schedule and risks — and the recommendation.
3. Take the card to whoever decides, follow the approval flow from Step 5 and record the decision with the name of the person who made it.
4. If approved, apply the detail (WBS, risks, schedule and budget), capture the new baseline and communicate it to those affected — with the updated documents.

🎁 Your deliverable: the requests documented, with the impact assessed, the decision recorded and — for the approved ones — the plan and the baseline updated.  ⏱️ Time: only when there are changes.  🛠️ Tools: ProjectAdm + data analysis (assessing impact) + decision making.

💡 Accelerate with AI: run Step 9 — it asks for the change, builds the impact prompt (with the picture of your board inside), records the card and, on approval, applies the detail and captures the new baseline. With your AI alone: “I received this change request [describe] on a project [summary] that already has an approved plan. Assess benefits × costs and the impact on scope, schedule, cost, quality, risks and stakeholders; recommend approve, approve with conditions, reject or defer, and say what the new baseline becomes. If I approve, detail the new deliverables and work packages with acceptance criteria, saying after which item of my WBS each one goes.”

💬 Tip: every change affects cost and schedule — saying “no” is managing too. And “not now” is a legitimate answer: record it as deferred, with the reason, instead of leaving it alive without a decision.

🎁 Your artifact — the Change Request Log, generated from your board

When you run Step 9, Project Together reads the Changes list and generates the Change Request Log (Excel .xlsx) into _saida/documentos/: every request with its code, its impact, its decision and who decided. Press D in the menu to regenerate it at any time.

With execution monitored and changes under control, the last step arrives: closing while making sure the value was delivered — Step 10.