The Fixed-Price Foundation Phase Squeeze
A consultancy has signed a fixed-price contract to deliver a customer portal in 20 weeks. The sponsor insists on a full Foundation phase before any development, but sales already committed the 20-week figure to the client and the contract penalty for lateness is 2% of contract value per week. The project manager proposes compressing Foundation to 3 weeks by running the feasibility and foundations workstreams in parallel and deferring the detailed business-case modelling until after the first timebox. The technical architect warns that the portal must integrate with two legacy systems whose interfaces are undocumented, and that integration risk is the single largest unknown. The business ambassador has limited availability and can attend only one workshop per fortnight. Two of the four DSDM core roles have not yet been named.
1. Evaluate whether compressing Foundation to 3 weeks is consistent with AgilePM principles. What risks does the proposal create and what would you recommend?
Read the worked answer
AgilePM treats Foundation as the phase that must establish sufficient justification, feasibility and foundations before delivery - it is not a phase to be squeezed for contractual convenience. The proposal conflicts with the principle 'Demonstrate control' and with 'Focus on the business need', because the business case is being deferred precisely when the biggest cost/risk driver (legacy integration) is unknown.
Specific risks:
- Feasibility undermined: the undocumented interfaces are the dominant unknown. Running feasibility in parallel with foundations means the feasibility evidence may not inform the business case or the architecture. A short, timeboxed technical spike on the two interfaces is legitimate; skipping feasibility evidence is not.
- Business case deferred: AgilePM expects an outline business case in Foundation, refined at each phase/Timebox. Deferring all modelling means the sponsor cannot make an informed go/no-go at the end of Foundation.
- Roles not confirmed: two core roles unnamed is a genuine blocker. AgilePM requires the business sponsor, business ambassador/visionary, technical coordinator and team leader to be in place; missing business involvement is the classic cause of late rework.
- Ambassador availability: one workshop per fortnight over 3 weeks gives at best two touchpoints - insufficient for elicitation of requirements at Foundations level.
Recommendation: do not compress to 3 weeks by removing rigour. Instead (a) run a focused 1-week feasibility spike on the two legacy interfaces before committing the business case; (b) keep Foundation at a realistic length (typically 4-6 weeks for this scale) and negotiate the 20-week delivery window or scope with the sponsor; (c) name the missing roles before Foundation completes; (d) accept lower-fidelity modelling but produce an outline business case with explicit assumptions about integration cost. The fixed-price penalty is a commercial problem - hiding risk in a short Foundation does not remove it, it transfers it to delivery where it is more expensive.
2. The sponsor asks: 'Can we just start building and treat everything as one big timebox?' How would you respond using AgilePM concepts?
Read the worked answer
No - and the reasoning should be framed in AgilePM terms, not dogma.
- Phases have distinct purposes: Foundation exists to establish the foundations (roles, products, business case, plans) so that the Evolutionary Development / delivery phases can iterate safely. Collapsing it into 'one big timebox' removes the control point at which the sponsor can make a go/no-go decision with real information.
- Timeboxing is a control technique, not a substitute for phases: a Timebox is a fixed, short period producing a defined increment (typically 2-4 weeks). One giant timebox defeats the purpose - you lose the regular inspection/adaptation rhythm and the ability to re-prioritise at each boundary.
- MoSCoW needs a baseline: without Foundations-level requirements and prioritisation, you cannot apply MoSCoW meaningfully, so the 'musts' are undefined and the fixed deadline cannot be protected by dropping 'coulds'.
- Risk: the largest unknown (legacy integration) would be discovered mid-delivery with no feasibility evidence, exactly when it is most costly.
Constructive alternative: agree a short, genuine Foundation (with a feasibility spike), then commit to delivery via a sequence of timeboxes with a prioritised requirements list and a product breakdown. Offer the sponsor early demonstrable increments - that addresses the underlying desire ('show me progress') without sacrificing control.