The 12-Week Fixed Deadline with a Scope-Shaped Hole
Meridian Housing, a mid-sized landlord, is running a PRINCE2 project to replace its tenant portal. The board has fixed an immovable go-live of 30 November because a regulatory reporting duty starts in December. The project manager, Dara, planned using PRINCE2 Agile with timeboxes of three weeks. Two timeboxes in, the team has delivered 14 of a planned 22 story points, and the 'repairs reporting' feature-which the regulator's guidance implies is needed-was not in the original prioritised list. The senior user insists all originally listed features must ship. The supplier's contract prices deliverables, not outcomes. Dara wants to keep the deadline, keep the board calm, and avoid a change request culture. A health check flagged 'flexing what is fixed' as amber.
1. Using PRINCE2 Agile's fixed-and-flexible concept, advise Dara on what should be fixed and what should flex here, and explain the consequence for the senior user's demand.
Read the worked answer
PRINCE2 Agile holds that time and cost are fixed and scope is flexed (with quality never flexed below tolerance and benefits actively protected). Here:
- Fixed: the 30 November date (regulatory driver), the budget, and the quality/tolerance thresholds for regulatory reporting.
- Flex: the set of features delivered, in priority order.
The senior user's 'all features must ship' demand directly contradicts the fixed/flexible model and, if accepted, converts a fixed-date project into a fixed-scope-and-date project-the classic failure mode. Dara should not simply refuse; she should make the trade-off explicit: if scope is fixed, then time, cost or quality must move, and the board must choose.
Practical route: re-prioritise the backlog with the senior user using MoSCoW, confirm that 'repairs reporting' is a Must (regulatory), and identify Should/Could items that can flex out of the November release. Any item the senior user insists on keeping as Must must be shown as a threat to the date, escalated to the board as an exception or a decision point-not silently absorbed.
2. The supplier contract prices deliverables. What is the risk to the fixed/flexible approach and what should Dara do about it?
Read the worked answer
A deliverables-priced contract fixes scope commercially, which fights the PRINCE2 Agile model of flexing scope within fixed time/cost. Symptoms: every de-scope becomes a contract negotiation, change requests multiply, and the team is incentivised to defend the list rather than protect the date.
Dara should:
- Surface the mismatch to the project board as a commercial risk, not just a delivery risk.
- Separate Must-haves (which may legitimately stay as priced deliverables) from Should/Could items, and negotiate a mechanism to trade flex items without a full change request-e.g. agreeing a pool of equivalent-value deliverables, or moving flex items to a later release under a call-off arrangement.
- Protect quality and regulatory scope explicitly in the contract language so that de-scoping cannot accidentally remove the reporting feature.
If the supplier will not flex, the board must accept that the date is at risk and record that decision. Dara's job is to make the trade-off visible, not to pretend the contract and the method agree.