Verdant Energy: fixing time, cost and scope at once
Verdant Energy has a six-month fixed-price contract with a vendor to build a new billing engine. The date is set by a regulatory tariff change that cannot move, the price is fixed, and the board has frozen a list of 42 features as 'the scope'. The vendor defines an item as done when the code is written and unit-tested; system testing happens in a single phase at the end. Three features the vendor has reported as complete have already failed acceptance testing by finance. Marketing has asked for a loyalty-points calculator to be added 'because the team is ahead'. The board's position is that nothing may be added and nothing may be dropped.
1. The board believes time, cost and scope can all be fixed simultaneously. What is wrong with that, and what should you put to them?
Read the worked answer
- Fixing all three is not a position, it is an unfunded risk. If scope, time and cost are all fixed, the variables that actually move are quality and the team's working hours. That is precisely how you end up with a single system-testing phase at the end and features that fail acceptance.
- The PRINCE2 Agile default is to fix time and cost, flex scope by priority, and protect quality through an agreed definition of done. Benefits can also be flexed. The board should consciously choose the fixed/flex mix rather than assume everything is fixed.
- Put a genuine choice to the board: either (a) prioritise the 42 features with MoSCoW and agree in advance that some 'coulds' and 'shoulds' may not land if velocity says they cannot, or (b) if all 42 are genuinely must-haves, accept that the date or the price must move. This is a board decision, not something the project manager absorbs silently.
- Agreeing the flex in advance reframes a later drop as the plan working, not as failure - and it protects the regulatory go-live, which is the one thing that cannot flex.
- Take it as an exception with the evidence: current honest velocity against a proper definition of done, extrapolated to the fixed date.
2. What should you do about the vendor's definition of done, and where does that sit in PRINCE2 terms?
Read the worked answer
- 'Code written and unit tested' is not done. It means most of the integration and acceptance risk is deferred to the end, where it is most expensive and least recoverable. The three failed features are the evidence, not an unlucky sample.
- Agree a definition of done for every item: acceptance criteria met, integrated and system-tested, non-functional requirements checked, documented to the required standard, reviewed by finance where relevant. Apply it from now on, not from the next release.
- It belongs in the quality theme. Product descriptions carry quality criteria and quality methods; the definition of done is how those criteria are applied at item level. Quality is the one dimension the project should not flex - if the definition of done cannot be met by the date, that is a scope or date conversation.
- Reset the reporting baseline once it is agreed, so the board sees honest velocity. Velocity measured against the vendor's version of done is fiction, and the progress reports built on it are worthless.
- Expect the honest number to look worse. Say so in advance and explain why it is safer - otherwise the reset itself will be read as the project failing.
3. How should marketing's request for a loyalty-points calculator be handled?
Read the worked answer
- Log it, size it, and promise nothing yet. In an agile context change is expected; the change theme's point is that new requirements are absorbed in priority order, not that they are refused at the door.
- Ask what it displaces. The capacity is fixed by the contract and the date. Adding the calculator means some item from the 42 does not get built, or the date moves. Present that as the choice, to the product owner and then the board, rather than discovering it as an overrun in month five.
- Challenge the premise. 'The team is ahead' almost certainly means 'ahead against an optimistic plan measured with a weak definition of done'. Once done means done, the buffer usually disappears - check before spending it.
- If it is small and separable, schedule it after go-live as a later increment, and keep the pre-go-live buffer for the regulatory date. Do not let a nice-to-have consume contingency that the immovable date depends on.