PRINCE2 Foundation (PRINCE2): The Supplier Who Cannot Say No

Where the organisation theme broke down

• Project board not meeting: the board is the body that makes decisions beyond the project manager's tolerance. Not meeting since initiation means the project has effectively been running without direction. The Executive should have insisted on stage-boundary reviews and exception reporting.
• Senior User: added scope without a change request. The Senior User is accountable for specifying the users' needs and for realising benefits - including the benefit that the project stays within its agreed scope and cost.
• Senior Supplier: committed to a fixed price but allowed work to start on unapproved scope. The Senior Supplier is accountable for the supplier's delivery and for the integrity of the supplier's commitment. The technical lead's 11-week estimate should have reached the project manager formally.
• Project Manager: accepted scope informally, failed to raise a change request, failed to escalate the 11-week impact, and proposed to recover time by cutting testing - a quality risk that undermines the products.
• Project Assurance: should have flagged that changes were being made outside change control and that the board had not met.

Root cause: accountability for change and for the supplier commitment was not exercised. The 'client is paying' rationale confuses customer goodwill with authorised change.

Correct path

1. Capture the request. Both new requirements are recorded as change requests (or as requests for change), however 'nice to have' they seem. 'Nice to have' is not a status in PRINCE2; only approved, rejected or deferred is.
2. Assess impact. The project manager assesses impact on time (11 weeks), cost, scope, quality, risk and benefits - and on the business case. The Senior Supplier confirms the estimate.
3. Consult the change authority. If the project board has delegated change authority (e.g. a Change Authority for changes under a threshold), the request goes there. If not, it goes to the board.
4. Decide. Approve, reject or defer. Deferral is legitimate for the 'nice to have' if the business case does not justify it now - and it should be logged, not silently started.
5. Update. If approved, update the plans, business case, risk register and product descriptions, and record the decision in the change log.

Escalation

The 11-week impact is likely beyond the project manager's time tolerance for the stage. The project manager should raise an exception report to the board, describing the situation, impact, options and a recommendation. The board then decides: extend the schedule, reduce scope, or reject the change.

What must not happen: starting work before approval, and recovering time by cutting testing. Cutting testing is a quality change and must go through the same control.

Content of a progress report (tailored to one page)

• Period covered and status summary (RAG by dimension: time, cost, scope, quality, risk, benefits)
• Work done and work planned for next period
• Products completed / quality status
• Issues and changes - including the two new requirements and their status
• Risks - top risks, changes since last report
• Tolerance status - is the project within stage tolerances?
• Business case status - still viable?
• Lessons

What the Executive should focus on

1. The 11-week impact and the absent change control - this is the biggest threat to the business case and to the fixed supplier commitment.
2. The proposal to cut testing - the Executive should reject this as a quality risk that trades short-term schedule for long-term failure.
3. The board's own failure to meet - the Executive should call a board meeting and re-establish stage-boundary control.

Judgement: a one-page report is fine as tailoring, but it must still surface the tolerance breach and the change decisions. Brevity is not a reason to omit the items the board exists to decide.