3.3 Life-Cycle Impact on Governance and Limits of Financial Authority
Key Takeaways
- Life-cycle choice shapes the governance framework: linear work relies on stage gates and progressive commitment; iterative work uses frequent reviews with rolling funding.
- Changing life cycle changes the cadence, artefacts, and location of decisions — it does not remove the need for authority and accountability.
- Limits of financial authority stop unauthorised spend and force escalation when commitments exceed delegated tolerances.
- Financial limits sit within a wider family of tolerances covering cost, time, scope, quality, risk, and benefit.
- A forecast benefit falling below the business case minimum is an escalation trigger even when cost and schedule are within tolerance.
Outcome 2c has a second half that candidates routinely under-answer: understand the impact of a project's life cycle on its governance framework and the limits of financial authority. Both halves test the same idea — governance has to be designed for the way the work actually flows, and it has to say in numbers who may commit what.
Life Cycle Impact on the Governance Framework
Governance must fit the life cycle, not fight it.
| Life cycle style | Governance emphasis | Financial authority pattern |
|---|---|---|
| Linear (predictive) | Phases with decision gates; progressive commitment of funds; formal baselines before each major phase | Larger releases of budget at gates once business case and plans are reconfirmed |
| Iterative (adaptive) | Frequent review of increments/backlogs; product owner prioritisation; continuous stakeholder feedback | Smaller, more frequent funding or capacity allocations; tighter timeboxes with ongoing viability checks |
| Hybrid | Predictive governance for high-risk or fixed elements; iterative control for uncertain product development | Split authorities: capital/contract gates for outer framework, product decisions inside sprints or increments |
In a linear life cycle, governance often asks at each gate: Is the business case still valid? Are risks acceptable? Are we ready for the next phase? Investment is released progressively so the organisation is not locked into full spend before uncertainty reduces.
In an iterative life cycle, the framework still needs authority and accountability, but decisions may be more frequent and closer to the working team. The product owner (covered in the next section) prioritises value within a product vision; the sponsor and board still own strategic alignment and overall investment. Financial authority may be set as a budget envelope for a product increment or timebox, with escalation if velocity, scope, or benefits forecasts threaten the case.
Exam point: changing life cycle does not remove governance. It changes cadence, artefacts, and where certain decisions sit — not the need for authority, accountability, and link to organisational objectives.
Limits of Financial Authority in Practice
Financial authority limits protect the organisation and the project manager.
Typical patterns you should recognise:
- Within tolerance: the project manager approves routine commitments and minor cost variances using the agreed budget and change process.
- At or near limit: the PM escalates early with options, impact on benefits, and recommendation — not a surprise at month-end.
- Beyond delegated authority: only the sponsor, steering group/board, or a higher corporate body can approve (depending on scheme of delegation).
Example: the PM’s delegated authority is £25,000 per change and 5% cost variance. A supplier variation of £40,000 that also delays a benefit-critical go-live must go to the sponsor or board, even if the technical team wants to “just get on with it.” Approving it alone would breach governance and could invalidate insurance, audit, or funding conditions.
Putting It Together for Exam Answers
When a scenario describes confusion over priorities, delayed decisions, or unauthorised spend, diagnose the structure first (functional/matrix/projectised), then the governance gaps (missing board, unclear delegation, life cycle/control mismatch), then the remedy (clarify authority, align with corporate policy, set escalation and financial limits). That chain of reasoning matches how APM PMQ long-response marks reward applied understanding, not memorised definitions alone.
Tolerances: the wider family that financial limits belong to
Financial authority is the most commonly examined limit, but it is one member of a family. Governance normally sets tolerances across several dimensions, and the project manager may act freely inside them and must escalate outside them:
| Tolerance | Typical expression | Escalation trigger |
|---|---|---|
| Cost | ±5% of the phase budget; £25,000 per change | Forecast breaches the band |
| Time | Two weeks on a phase end date | Milestone forecast moves beyond it |
| Scope | Named must-have deliverables cannot be dropped | A must-have is at risk |
| Quality | Defined acceptance criteria must be met | A criterion cannot be met as specified |
| Risk | Aggregate exposure ceiling, or no red risks unmitigated | Exposure exceeds appetite |
| Benefit | Minimum acceptable benefit level in the business case | Forecast benefit falls below it |
The benefit tolerance is the one candidates forget, and it produces one of the most reliable PMQ scenarios: a project comfortably inside cost and time tolerance whose forecast benefits have collapsed. Reporting green because the money is on plan is the wrong answer — a benefits breach is an escalation just as much as an overspend, because it attacks the justification for the whole investment.
Escalation is a governance duty, not an admission of failure
Say this explicitly in written answers. A project manager who quietly absorbs a breach — by cutting quality, using contingency without approval, or resequencing to hide a slip — has taken a decision that belongs to the sponsor or board. A project manager who escalates early with status, forecast, options, impact on the business case, and a recommendation has done the job correctly, even when the news is bad.
A project uses a linear life cycle with stage gates. Forecast cost for the next phase exceeds the project manager’s delegated financial authority, though technical work is ready to start. What is the most appropriate governance action?
A project is tracking within its cost and schedule tolerances, but the latest forecast shows expected benefits falling below the minimum level stated in the approved business case. What should the project manager do?