Skip to content

The Change Scenario

Every capstone includes one change request (deliverable 13). This page supplies the scenario, the process you must follow, and what "complete" means — so that the exercise tests your judgement rather than the timing of a stakeholder's request.

Why this is a required deliverable

Change control is one of the few project management skills that only appears under pressure. A student who has never evaluated a change against a baseline, priced it, presented options, and watched a decision be recorded has not practised the skill — they have read about it. The scenario guarantees that the pressure happens.

Choose one scenario

Use whichever fits your project. If your own project produces a real change request, use that instead — a real one is always better.

Scenario A — The scope addition

Mid-delivery, a stakeholder with influence asks for something that was explicitly excluded in your scope statement. Their reason is plausible, and the request is small when described aloud.

Typical form: "Since you are already building the submission form, could it also send an email acknowledgement? It's only one more step."

Scenario B — The regulatory or policy change

The requirements move because a rule, a standard, or an organisational policy changed — before or after the decision-maker who owns it can act quickly.

Typical form: a data-retention period is confirmed at a different length than the assumption your design rests on, or an accessibility conformance level becomes mandatory for the release.

Scenario C — The external dependency slip

A dependency you do not control changes its date, affecting your critical path.

Typical form: the security review queue lengthens; the external provider's sandbox is unavailable for two weeks; a shared component is delivered late.

Scenario D — The trade demanded

A senior stakeholder asks for a date or a cost that your plan cannot meet, without offering scope, quality, or capacity in exchange.

Typical form: "We need it two weeks earlier. Can you make that work?" — which is a request for a compression decision, not a change request, and should be handled with Advanced Lesson 5.

The process you must follow

  1. Log it before discussing it. Give it an ID and a date, and record who raised it and why. Nothing is agreed verbally and applied silently.
  2. Assess the impact against the untouched baseline, not against a revised or slipped plan. Comparing a change against an already-late plan makes every change look free.
  3. Present at least three options with costs — the obvious ones are do it now, defer it, and do a reduced version; a fourth, doing something else instead, is often the strongest.
  4. Recommend one, with the reason. A change request returned to the sponsor without a recommendation wastes the authority it was escalated to.
  5. Get the decision recorded, with the name and date of who decided. Use the decision log as well if the decision changes a baseline.
  6. Update the baseline, or record the rejection. Either way, the traceability from the request to the outcome must be visible in the change log.

What to supply

Use your own project's figures. The assessment is of the reasoning, not of the numbers, but the numbers must be consistent with your other artefacts:

Input Where it comes from
The baseline being affected Your scope statement, schedule, or budget, with its version
The estimate for the change Your own estimation technique, with a basis and a range
The day rate or cost basis The one stated in your business case — not invented for the occasion
The schedule effect Which activities change, whether any are on the critical path, and the effect on the finish
The quality effect What additional testing, review, or documentation is required
The risk effect Any new risk, scored on your register's scale
Who may decide it Your charter's authority statement or decision rights table

Worked illustration

An extract in the expected form, for the LMS option. The figures are invented for teaching and are consistent with the Lab 10 style of reasoning.

Field Value
Change ID CR-001
Raised by Course administrator (high influence, supportive)
Description Add email acknowledgement on submission — currently excluded
Type Scope
Scope impact Adds one requirement (FR-07); removes nothing
Schedule impact 3 person-days, of which 1 falls on the critical path before system testing
Cost impact 3 person-days at the baseline day rate, plus 0.5 day of testing
Quality impact Two additional acceptance scenarios; the notification service must be reachable from the test environment
Risk impact New risk: institutional email relay refuses the sending domain (probability 2, impact 2, exposure 4)
Options A: build now (+3.5 days, or 1 day of schedule). B: defer to release 2 (0 days, benefit lost for this term). C: send a confirmation screen instead of an email (+0.5 day, meets the need partially). D: use the existing departmental mail tool manually (0 days, effort falls on administrative staff)
Recommendation Option C, because the underlying need is confirmation that the submission was received, which a confirmation screen satisfies at a sixth of the cost, and because the schedule effect of A lands on the critical path before testing
Decision Option C, approved by the sponsor, 2026-05-04, on the sponsor's authority
Baseline update Scope statement v1.2 (FR-07 restated), schedule v1.1 (no date change), risk register R-09 added

Note what the recommendation does: it identifies the underlying need rather than accepting the requested solution. That is the most valuable thing a project manager contributes to a change decision, and it is worth looking for in every request you assess.

What "complete" means

Requirement Evidence
Logged An ID, a date, a requester, and a reason
Assessed against the baseline Impact stated on scope, schedule, cost, quality, and risk — with the baseline version referenced
Options costed At least three options, each with its cost and consequence
Recommended One option named, with the reason
Decided The decision, the decider, and the date
Reconciled The baseline updated, or the rejection or deferral recorded
Traced The requirement, the work, and the decision link to each other

Self-check

Run these before submitting deliverable 13:

  • Could someone reading only this document tell what changed, what it cost, and who decided it?
  • Is the impact stated against the original baseline rather than a revised one?
  • Is the cost in the same units and at the same rates as my business case?
  • Did I look for the underlying need, rather than only pricing the requested solution?
  • Does the baseline in my submission reflect the decision — and if the change was rejected, is that visible anywhere?