A change, a defect and a version nobody agreed

Step 1 - do not accept it, and do not refuse it. An informal 'yes' from the PM to a director is how projects acquire unfunded scope. Acknowledge, log, and start a formal impact assessment.

Step 2 - full impact, not just the supplier's number

Dimension	Impact
Cost	£95,000 against a £30,000 change budget
Schedule	+4 weeks on the critical path → go-live week 34, two weeks past the week 32 regulatory deadline
Benefits	Four weeks of deferred benefit at £40,000/week = £160,000
Total real cost	≈ £255,000, not £95,000
Risk	Consumes all remaining 10 days of contingency and then some

Step 3 - authority

£95,000 alone would sit in the sponsor's band (£20,000–£100,000). But the change affects the approved go-live date and pushes delivery past a regulatory deadline. Under the stated governance it therefore goes to the change advisory board, with the sponsor presenting. The PM's job is to prepare the assessment and a recommendation, not to decide.

Step 4 - options to put to the CAB

• A. Reject / defer to phase 2. Cleanest for cost, date and compliance. The operations director gets nothing this year - require them to state the cost of that in benefit terms.
• B. Accept but phase the delivery. Build the dashboard within existing resourcing but deploy it after the week 30 go-live as a separate release. This captures most of the benefit at a fraction of the critical-path impact, if the dashboard is genuinely decoupled from the portal launch. This is the option to test technically first.
• C. Accept and descope. Remove £95,000 and roughly four weeks of lower-value in-scope functionality to hold the date and budget. Requires someone to decide what is less valuable than a dashboard - a business decision, not a PM one.

Recommendation: take B and C to the CAB as the serious options, with the technical assessment of decoupling attached. Reject A only if the operations director cannot articulate the benefit.

Step 5 - stakeholder handling. The operations director is senior, motivated and has raised this late. Engage them before the CAB with the full impact figures, so they arrive at the meeting understanding the trade-off rather than discovering it. A director who feels ambushed becomes a sponsor-level problem.

Default position: DEF-112 is a defect, not a change. The requirement exists; the delivered item does not meet it. Fixing it is rework within approved scope, funded from the project budget, not from the £30,000 change budget and not through the change board.

But the facts here are genuinely ambiguous, and the ambiguity changes the answer. The requirement says 'reconcile to the finance ledger' without specifying granularity. The developer's daily-reconciliation reading is defensible on the words. That means this is not a clear-cut defect against a precise specification.

Process

1. Confirm the interpretation was documented and accepted. If the requirements specification or a signed design document records daily reconciliation and the business signed it off, the per-transaction behaviour is new scope - raise a change request for £14,000. If the granularity was never agreed, it is a defect in the requirements, and the project owns it.
2. Quantify the business impact. A 3% error rate on a ledger report may be immaterial if the report is reconciled manually downstream, or material if it drives a regulatory return. Get the finance owner to state which. This determines urgency, not the process.
3. Log it in the defect register with a root cause. 'Requirement was ambiguous and the ambiguity was not resolved at review' is the finding. The action is on the requirements review process, not on the developer.
4. Schedule it against contingency, consciously. Eight days against 10 days of remaining schedule contingency consumes 80% of the buffer, for £14,000. Options: absorb in parallel using non-critical-path resource (preferred if available); accept a later fix if the report is not used before go-live; or trade it against the 10 days, which leaves the project effectively unprotected for the remainder.
5. Report it. A defect found at week 14 that hits 3% of transactions is a quality signal for the whole reporting workstream. Check the same reconciliation logic in the other reports before assuming this is isolated - that is the difference between fixing a bug and fixing a class of bugs.

What not to do: do not let the operations director's CR-041 and DEF-112 be traded against each other informally ('we'll fix your defect if you drop the dashboard'). Both must be assessed on their own merits and recorded separately, or the configuration record becomes fiction.

This is a configuration management failure, and it is more dangerous than either the change or the defect because its full extent is unknown.

Immediate (this week)

1. Establish the facts. What changed between v2.1 and v2.3? Is v2.3 an approved, mandatory baseline or a draft? Was v2.3 issued under the supplier's own change control, and were we notified? Get the change log, not a summary.
2. Impact analysis across the configuration. Identify every configuration item built, tested or documented against v2.1 - code, interface maps, test scripts, data models, training material, the design document set. The build is the obvious one; the test scripts are the one that hides.
3. Freeze and baseline. Declare v2.3 the controlled baseline (or v2.1 if v2.3 is not yet mandatory), record the decision, and put a single owner on the interface specification. Nothing is built against an uncontrolled document from now on.
4. Function point / CR. If adopting v2.3 adds work, raise a change request with a costed impact - including the retest cost, which is often larger than the rebuild.

Assessment

• Cost of moving now: rework plus full regression of the interface at week 14, with 16 weeks left. Painful but affordable if caught this week.
• Cost of moving later: the same rework plus re-testing everything that has already passed UAT, plus a real chance of discovering the incompatibility during cutover or, worse, in production.
• Cost of not moving: only viable if v2.1 remains supported for the life of the portal. Get that in writing from the platform owner, with a support end date. Verbal reassurance is worth nothing here.

Recommendation: move to v2.3 now if it is a mandatory baseline and v2.1 support has a defined end date before the portal's expected life. Do it at week 14 rather than week 26 - the cost is the same rework with half the time to absorb it.

Root cause and fix

• There was no configuration librarian and no distribution list for supplier documents. Assign configuration management accountability to a named person, however part-time.
• Introduce a fortnightly configuration status account: which items are at which version, what is pending, what has been superseded.
• Add a configuration audit at each stage gate and before go-live: does what was built match what was approved?
• Raise the issue with the supplier formally - the specification changed without notification, and the contract should require notification of interface changes as a condition of the fixed price.