Fit-for-Purpose Governance When the Organisation Wants Phase Gates
A large insurer is adopting AgilePM for a claims-automation project. Its existing PMO mandates a stage-gate review with a signed-off, baselined requirements document before any build begins, plus a monthly RAG report. The AgilePM Project Manager has planned Foundations (4 weeks) then three timeboxes of development, with a Deployment phase. The PMO analyst has told the Project Manager that 'without a baselined requirements baseline at the end of Foundations, the project cannot start development'. The Business Visionary is nervous about starting development without a complete specification. Two weeks into Foundations, the team has a clear enough view of the first timebox's Musts to begin.
1. Reconcile the PMO's gate requirement with AgilePM's approach to requirements and phases.
Read the worked answer
AgilePM does not produce a complete, baselined requirements specification before build; the PRL is sufficiently detailed for the near term and progressively elaborated, with the Must set prioritised and the detail for later timeboxes deferred. A gate that demands a full baseline contradicts the approach and would force big-design-up-front.
Reconciliation: offer the PMO a fit-for-purpose gate - at the end of Foundations the project can evidence the business case, the prioritised Must set for the first timebox(es), the outline solution architecture, the plan and the governance roles. That is a real, auditable decision point: the organisation can stop the project there. What it cannot have is a frozen full specification, because that would remove the ability to flex scope and would be obsolete on arrival.
This is a tailoring conversation, not a compliance failure: AgilePM explicitly expects the approach to be tailored to the organisation's governance, and the PMO's underlying need - evidence before spending - is met by the Foundations products.
2. The Business Visionary wants a complete specification before development. How do you address that concern without abandoning the approach?
Read the worked answer
Address the underlying fear, which is usually 'we will build the wrong thing and find out too late'. Mechanisms that answer it within AgilePM:
- Early, demonstrable increments: the first timebox delivers working, tested functionality reviewed by the business, so 'wrong thing' is discovered in weeks, not months.
- Modelling in Foundations: enough business process and solution modelling to make the first timeboxes safe, without specifying everything.
- Explicit Must set and acceptance criteria for the first timebox, agreed by the Business Ambassador, so the business controls what 'done' means.
- A timebox review with real go/no-go: the business can stop or redirect after each timebox.
Agree a compromise: a short, timeboxed elaboration session at the start of each timebox to confirm detail with the Business Ambassador. If the Visionary still insists on a full specification, escalate as a tailoring decision to the Sponsor with the schedule and flexibility consequences stated explicitly - the Project Manager's job is to make the trade-off visible, not to absorb it silently.