2.4 Choosing a Life Cycle: Context, Culture, Strengths and Limitations

How organisational context and culture influence choice

Life-cycle selection is rarely a purely technical decision. Organisational context and culture shape what is acceptable, fundable, and enforceable.

Contextual factors that push choice

• Uncertainty and novelty — high ambiguity about needs or solution design pushes toward iterative or hybrid learning loops.
• Regulatory and safety constraints — industries with mandated evidence packs and staged approvals push toward linear phases or hybrid with strong gates on regulated streams.
• Funding model — capital programmes with board stage-gates favour linear progressive commitment; product funding by value increments can favour iterative.
• Stakeholder engagement needs — when end users must co-create requirements, iterative demos beat a single late reveal.
• Supplier market and contracts — fixed-price design-and-build may assume linear baselines; collaborative agile contracts may assume iterative scope management.
• Data and technology volatility — fast-changing platforms increase the cost of freezing everything early.

Cultural factors

Culture is the "way we decide here":

• A risk-averse, hierarchical culture often prefers detailed upfront approval, thick documentation, and linear gates. Imposing pure iterative delivery without changing decision rights can create shadow waterfall behaviour (teams iterate informally while boards still demand full frozen plans).
• A learning-oriented, empowered culture tolerates partial products, frequent re-prioritisation, and local decision-making — fertile ground for iterative methods.
• A matrix or multi-vendor culture may need hybrid designs with explicit interface rules so each partner's method does not collide.
• A culture that rewards only on-time output delivery will underfund extended-life-cycle activities (training, benefits tracking, decommissioning), so governance must deliberately protect those workstreams.

Specific project needs and legitimate adaptations

Even within one organisation, projects differ. Adaptations should be conscious and documented, not silent exceptions:

• Shorten or merge phases for low-risk, familiar work while keeping a final go-live gate.
• Add discovery/prototype iterations before a linear build for unknown user journeys.
• Run linear compliance streams in parallel with iterative product streams (hybrid), with a joint integration plan.
• Extend the life-cycle model in the PMP/plans to name operational owners and benefits reviews after handover.
• Strengthen change control on baselined linear elements while using backlog prioritisation on iterative elements.

Bad adaptation looks like calling a project "agile" while forbidding user feedback, or calling it "waterfall" while constantly reopening design with no gate discipline.

Strengths and limitations of different life cycles

Use this table in long answers: state a strength and a limitation, then link both to the scenario.

Governance implications of life-cycle choice

Life-cycle choice is a governance design decision as much as a delivery method choice.

Linear governance implications

• Formal stage-gate packs, assurance, and board or sponsor decisions at phase ends.
• Strong configuration management of baselines after definition.
• Change control becomes the main route for scope movement once baselined.
• Reviews and reporting align to phase milestones and critical path progress.

Iterative governance implications

• Frequent increment reviews replace (or supplement) rare mega-gates.
• Prioritisation authority (for example product owner / empowered business lead) must be real, or iterations stall.
• Funding may be released in tranches tied to demonstrated progress and remaining backlog value.
• Quality and compliance still need explicit definition of done, definition of ready, and non-functional standards each cycle.

Hybrid governance implications

• One overall sponsor accountability, with workstream-specific controls.
• Clear mapping of which decisions are gate decisions versus backlog decisions.
• Integration milestones where iterative outputs must meet linear baselines (for example freeze interfaces before factory acceptance).
• Reporting that shows both predictive metrics (earned value on capital works) and iterative metrics (throughput, acceptance, value delivered).

Extended life-cycle governance implications

• Identify operational owners and benefits owners before transition.
• Plan training, support, hypercare, and performance measurement as part of transition — not as an afterthought.
• Schedule post-project benefits reviews against the business case.
• For assets with finite life, plan disposal, data retention, and environmental responsibilities early enough to influence design.

Putting choice into a PMQ answer structure

A strong exam response often follows this path:

1. Diagnose context — uncertainty, regulation, culture, funding, stakeholders.
2. Select life cycle — linear, iterative, or hybrid, with one clear rationale.
3. State adaptations — what you would tailor and why.
4. Address extension — how transition, operations, and benefits will be owned beyond project closure.
5. Note limitations — what risks the chosen model introduces and how governance will mitigate them.

Worked mini-scenarios

Local authority housing retrofit programme. Technical standards and grant rules are fixed; resident communication plans can improve through pilots. Hybrid often fits: linear compliance and works phases, iterative refinement of resident engagement materials, plus an extended view of energy-bill benefits after occupation.

Start-up building a novel consumer app. Requirements will change weekly based on usage analytics. Iterative delivery with empowered product prioritisation fits; extended life-cycle thinking still matters for retention metrics and later feature deprecation.

Utility company replacing a substation. Safety cases, outage windows, and capital approval demand linear gates; benefits include reliability over decades of operation, so the extended life cycle and operational handover quality dominate sponsor interest even after the project team disbands.

Choose the life cycle that the organisation can actually govern, not only the one that looks fashionable. A brilliant iterative method in a culture that cannot prioritise or empower will fail; a pure linear method in a discovery problem will waste capital on the wrong design.