Hybrid Waterfall-Agile Project Charter Template: When Half Your Organisation Wants Each (2026)

Why Hybrid Exists

Most enterprise projects are not pure waterfall or pure agile. PMI's 2024 Pulse of the Profession reports that 33% of projects globally use a hybrid approach, up from 23% in 2018. The 17th State of Agile Report (Digital.ai, 2024) shows 56% of organisations use hybrid alongside or instead of pure agile.

The reason is straightforward. Capex-funded projects need budget gates, regulated industries need documented audit trails, and most enterprise programmes include workstreams (data migration, hardware procurement, regulatory submission) that genuinely cannot be productively run as Sprints. At the same time, the build phase of software-heavy projects benefits from the empirical control and rapid feedback that Scrum or Kanban provide. Hybrid is what you get when you stop arguing about which framework is "better" and instead pick the right framework per phase.

Decision Matrix: Waterfall vs Agile vs Hybrid

Dimension	Pure Waterfall	Pure Agile	Hybrid
Funding model	Capex with annual review	Opex denominated in Sprints	Capex envelope released stage by stage; intra-stage delivery is Sprint-based
Scope commitment	Fixed scope, variable time and cost	Fixed time and cost, variable scope	Fixed scope at the phase-gate level, variable scope at the Sprint level
Reporting cadence	Monthly steering committee with phase-gate reviews	Bi-weekly Sprint Review with stakeholders	Monthly steering plus bi-weekly Sprint Review
Change control	Formal change request with sponsor approval	Backlog re-prioritisation by the PO	Formal CR for scope changes that cross a phase gate; PO autonomy within a phase
Documentation	PMBOK charter, project plan, risk register, communication plan	Product Goal, Definition of Done, lightweight backlog	PMBOK-style charter plus Scrum artefacts as appendices
Decision authority	Sponsor and steering committee	Product Owner with stakeholder input	Steering owns gate decisions; PO owns intra-phase decisions

Filled Example: Aurora Manufacturing ERP Replacement

Worked example: a 22-month SAP S/4HANA migration with five phases. Discovery and Design run waterfall, Build runs Scrum, Test is genuinely hybrid, Cutover returns to waterfall.

Programme name

Aurora Manufacturing ERP Replacement (SAP S/4HANA migration)

Duration

22 months (1 Jul 2026 to 31 Apr 2028)

Budget envelope

USD 14.2M total (USD 12.4M base + USD 1.8M contingency, 12.7% reserve)

Phase	Governance	Delivery	Weeks	Output
Phase 1: Discovery	Waterfall (PMBOK)	Workshops, document analysis	8	Functional and technical requirements, gap analysis vs out-of-the-box S/4HANA, migration approach
Phase 2: Design	Waterfall (PMBOK)	Workshops with SI partner	12	Functional design documents, integration architecture, master data strategy
Phase 3: Build	Agile (Scrum)	4 cross-functional teams running 2-week Sprints	40	Configured S/4HANA, custom Z-objects, integrations, test scripts
Phase 4: Test	Hybrid	Cycles of test execution (waterfall plan) plus defect triage Sprints (agile)	16	SIT pass, UAT pass, performance test pass, cutover plan signed
Phase 5: Cutover and Hypercare	Waterfall (PMBOK)	Day-by-day cutover plan	8	Live system, hypercare exit signed by sponsor

Steering Committee

Composition: CFO (Executive Sponsor and chair), COO (Senior User), CTO (Senior Technology Owner), VP Finance Transformation (Programme Director), SI Partner Delivery Director, External assurance partner.

Cadence: Monthly, with phase-gate go/no-go reviews at the end of Discovery, Design, Build, and Test.

Sprint Cadence

2-week Sprints across all 4 build teams. Quarterly cross-team Big Room Planning.

Scope

In scope: Finance (GL, AP, AR, Asset Accounting), Procurement, Production Planning, Plant Maintenance, Sales and Distribution for the three primary BUs. Master data migration from legacy systems. Integration with Salesforce CRM, Concur expenses, and ADP payroll.

Out of scope: Do not migrate retired Acquisition #4 systems (separate decommissioning project). Do not implement S/4HANA Public Cloud (selected RISE with SAP, private cloud). Do not migrate historical transaction data older than 7 years (archived). Do not include the EMEA region (Phase 2 programme).

Hybrid Failure Modes to Avoid

Calling everything 'agile' to avoid governance

Sponsor and steering committee lose visibility. By Phase 3 nobody can answer 'are we on track?' because there is no waterfall plan to compare against.

Sequential phase gates inside a Sprint

If a phase gate is a hard prerequisite for the next phase, the Sprint cannot truly start until the gate passes. The Sprint becomes a 4-week status report.

Two project managers, one on each side

One PM runs steering reports, another runs Sprints. Decisions fall in the gap. One PM with explicit dual responsibility (and a clear sponsor) works; two PMs in adjacent roles does not.

Backlog written like a Gantt chart

User stories sequenced by phase, not by value. Defeats the variable-scope premise of Scrum and turns Sprints into mini-waterfalls.

Steering committee retrofit

Adding waterfall governance to a Scrum project mid-flight, because a stakeholder wants more control. Demoralises the team and rarely produces the visibility the steering committee wanted.

Frequently Asked Questions

Is hybrid waterfall-agile a real methodology?

Yes, formally. PMI publishes guidance on hybrid approaches; the 2024 Pulse of the Profession report shows 33% of projects globally use a hybrid model, up from 23% in 2018. The 17th State of Agile Report (published by Digital.ai in 2024) shows 56% of organisations use hybrid alongside or instead of pure agile. AXELOS publishes PRINCE2 Agile specifically for the hybrid case. The methodology exists; the failure mode is teams doing it without naming it.

When should you choose hybrid over pure agile?

Three conditions: (1) regulatory or audit requirements demand documented governance gates, (2) the budget is capex with sponsor or board approval rather than a continuous opex envelope, (3) one or more workstreams in the project are genuinely waterfall (data migration, hardware procurement, regulatory submission) and cannot be productively run as Sprints. ERP rollouts, regulated drug submissions, large infrastructure programmes, and most government IT meet at least one of these conditions.

When does hybrid become worse than either pure approach?

When the team adopts the overhead of both without the benefits of either. Symptoms: 50-page PIDs that nobody reads, 4-hour planning meetings that produce neither a Gantt nor a backlog, status reports written for steering that contradict the Sprint Review demo from the same week. The 2024 State of Agile data shows hybrid teams report higher dissatisfaction than either pure-waterfall or pure-agile teams unless explicitly designed and named.

Who is the Product Owner in a hybrid project?

Inside each agile phase, the Product Owner is a named individual with backlog authority. At the programme level, the Project Manager (or Programme Director on large efforts) integrates POs across teams and is the point of escalation to the steering committee. The PO role is preserved exactly as in Scrum; what is added is the PM role above the POs to handle phase-gate governance.

Does a hybrid charter need a Definition of Done?

Yes. The DoD applies to the agile phases. The charter should reference the DoD by saying 'Definition of Done will be authored by each Scrum team in Sprint 0 and reviewed at every retrospective; current versions are appendices to this charter'. Treating the DoD as a charter appendix solves the audit-trail problem (the document exists and is approved) without freezing the DoD itself.

How long is a typical hybrid charter?

8 to 18 pages. The PMBOK charter sections (purpose, objectives, scope, milestones, budget, risk, team) carry the bulk of the content. Agile-specific content (Sprint cadence, DoD appendix, backlog management approach) adds 2 to 4 pages. The Project Board / Steering Committee composition and tolerance table add another 1 to 2 pages. Shorter than 8 pages and the document cannot carry the dual governance burden; longer than 18 pages and nobody reads past page 6.

How is risk managed in a hybrid project?

Two-tier. Programme-level risks are tracked in a charter risk register, reviewed monthly at steering, and govern phase-gate decisions. Team-level risks (impediments) surface through Sprint retrospectives and are addressed by the team or escalated to the PM. Risks that cross the threshold (impact above a defined score, often 8 on a 5-by-5 matrix) escalate from the team to the programme register. The charter should document the threshold and the escalation path.

Related on this site

PMBOK charter (the waterfall side)Scrum charter (the agile side)PRINCE2 Agile (UK government hybrid pattern)IT / ERP migration charter Enterprise charter Risk matrix (two-tier risk register)