i

Description

Une cascade qui dévale une paroi rocheuse par paliers

Source

Ivano Giambattista · original page

Licence

CC0 Public domain

Original photo, unretouched. The background is a version of it stylised by the site.

Predictive Methods (waterfall, V-model, spiral, RUP, PMBOK, PRINCE2, Merise, CMMI)

You will learn to distinguish so-called predictive methods (plan first, execute next): waterfall, V-model, spiral, RUP, PMI/PMBOK approach, PRINCE2, Merise, and the maturity framework…

In short

• You will be able to distinguish so-called predictive methods (plan first, execute next): waterfall, V-model, spiral, RUP, PMI/PMBOK approach, PRINCE2, Merise, and the CMMI maturity framework (which is not a lifecycle method).
• You will understand why they exist, what they truly guarantee (traceability, control, contracting) and where they break down (uncertainty, late change, late feedback).
• You will be able to say when they are still the right choice: fixed scope, regulation, fixed-price contract, like-for-like migration.
• You will see their data version: datamart scoping, business acceptance testing on figures, installation kits, version migrations.
• You can then compare them in the comparison and combine them with agile methods in Choosing Your Method and Hybridizing.

On this page

1. 1. What “predictive” means
2. 2. Waterfall
3. 3. The V-model
4. 4. The Spiral Model
5. 5. RUP, the Unified Process
6. 6. The PMI / PMBOK Approach
7. 7. PRINCE2
8. 8. Merise and the French Tradition
9. 9. CMMI: A Maturity Framework, Not a Cycle
10. 10. Strengths and Weaknesses: Rated Summary
11. 11. When Predictive Is Still the Right Choice
12. 12. Predictive applied to data
13. 13. Expert: the cost of change, the cone of uncertainty, contracts
14. 14. AI contribution
15. 15. See also

Level: 🟢→🔴

1. What “predictive” means#

🟢 Novice — A predictive method (also called “plan-driven”) assumes that we can know the essentials before building: we specify, design, and plan everything, then execute while measuring deviation from plan. Its opposite is not chaos but the adaptive approach, which plans in small chunks and learns by delivering (see Agile and Lean Methods (Manifesto, Kanban, XP, Lean, Shape Up, DSDM, SAFe, DevOps…)).

Three ideas structure all the methods in this guide:

Basic terms (scope, milestone, WBS, critical path...) are defined in the Project Management Fundamentals and the Glossary.

2. Waterfall#

🟢 Novice — The waterfall model chains phases: requirements → design → implementation → verification → maintenance. Each phase produces a validated deliverable that feeds the next one. Image: a waterfall does not flow uphill.

🟡 In practice — Origin, often misreported: Winston Royce’s 1970 paper Managing the Development of Large Software Systems presents the sequential diagram to criticize it: Royce considers this model risky as-is and proposes feedback loops, a prototype, and customer involvement. The term “waterfall” is not his. Pure waterfall is therefore largely a straw man turned standard: what is actually practiced is waterfall with feedback loops (“waterfall with feedback loops”).

When waterfall works:

• requirements are stable and understandable from the start;
• the technology is mastered (no technical discovery);
• the cost of an error found late is acceptable or offset by firm contracting;
• the organization requires formal decision gates (committees, milestone reviews, stage payments).

When it fails: feedback arrives late. The user sees the product at the end; a requirement error introduced in phase 1 is only detected in phase 4, when it is most expensive to fix.

🧪 Example — A sales datamart fully specified (star schema, 40 measures, calculation rules) before any loading. During acceptance testing, “net” revenue differs from management control by 3% because credit memo handling was missing from the specification. In waterfall, the fix goes back to design, impacts tables, loads, DAX, and tests: a full rerun. A quantitative prototype on one month of data would have exposed it by day 10.

🔴 Expert — The structural flaw is the coupling between validation and delivery: as long as nothing is delivered, nothing is validated under real conditions. Classic remedies (prototyping, incremental development, peer reviews) are borrowed from other families, showing that waterfall is a limiting case rather than an equilibrium point.

3. The V-model#

🟢 Novice — The V-model is a waterfall where each design phase is matched with a test phase at the same level. On the left, you go down (specify, design); at the bottom, you code; on the right, you go up (test, acceptance test).

🟡 In practice — The essential point is mapping: a test is written at the same time as the specification it verifies, not after coding. This requires every requirement to be testable and provides traceability from requirement → test (coverage matrix).

You must distinguish verification (“are we building the product right?”, against specifications) and validation (“are we building the right product?”, against the need). The V provides both, at different levels.

Reliable historical points: the German V-Modell (federal administration, 1990s, revised as V-Modell XT) popularized the shape; in France, the V-model became the de facto standard for business-side ownership and many public-sector IT contracts, where MOA (business ownership) and MOE (implementation ownership) are distinguished. It remains widespread in sectors with strong evidence requirements (rail, aerospace, medical, automotive): the standards used there (for example DO-178C, ISO 26262, IEC 62304 families) are explicitly expressed in level-based verification/validation.

Strengths: traceability, tests designed early, common MOA/MOE vocabulary, fit with phase-based contracts. Weaknesses: little real feedback before the right-hand side, rigidity toward change, tendency toward tunnel acceptance testing (validation happens at the very end, on one huge block).

🧪 Example (data thread) — For a datamart fed by a sales force application: need “track shelf space by banner” ↔ acceptance testing: for three sample stores, the total shown in Power BI must match the field report (tolerance: 0 on quantities, 0.01 on amounts); model specification ↔ integration test: row counts per fact table and orphan key checks; detailed design of a loading procedure ↔ unit test: idempotent rerun on a minimal dataset. The V translates very well into data tests (see the matrix topic Acceptance testing and business validation).

🔴 Expert — The V assumes stable interfaces between levels: if high-level design changes, all downstream tests are invalidated. Hence the value of splitting into subsystems with interface contracts (schemas, data contracts) frozen earlier than everything else. For data, the data contract between source and datamart is the most critical interface; see Data Sources and Contracts.

4. The Spiral Model#

🟡 Practical — Proposed by Barry Boehm (1986), the spiral model is a risk-driven cycle. Each loop goes through four quadrants: (1) set objectives and constraints, (2) analyze risks and build a prototype, (3) develop and verify, (4) plan the next loop. The size of the investment grows with each loop, but only after reducing the most serious risks.

Core idea: risk determines the process. If the main risk is the user interface, you prototype; if it is performance, you run a benchmark; if it is integration, you build an end-to-end skeleton. Boehm also defined anchor point milestones that influenced RUP.

Strengths: addresses uncertainty before committing; compatible with large projects with technical risks. Weaknesses: requires rare risk analysis skills; hard to contract (the number of loops is unknown); often misapplied as a simple waterfall with multiple passes.

🧪 Data example — Before committing to a full architecture, perform a proof loop: load one month of real data from an unstable source, measure load duration and quality (duplicates, null keys), decide “continue / change strategy.” This is a miniature spiral, and it is exactly what any good data framing should contain.

5. RUP, the Unified Process#

🟡 Practical — The Rational Unified Process (RUP, Rational Software, late 1990s, around Jacobson, Booch, and Rumbaugh, with UML) is an iterative and incremental process driven by use cases, architecture-centered, and risk-driven. It organizes the project into four phases:

And in parallel, disciplines (business modeling, requirements, analysis/design, implementation, testing, deployment, configuration management, project management, environment) whose effort varies by phase.

Strengths: architecture handled early, iterations, conceptual consistency, rich tooling. Weaknesses: heaviness (tailoring is mandatory but often poorly done), jargon, extensive documentation. Its legacy lives on in OpenUP and especially in “just enough” agile architecture practices (just enough design up front).

🔴 Expert — RUP's lasting contribution: the elaboration phase as the moment when you remove architecture risks and measure progress by what runs, not by what is documented. This idea (validating architecture with an executable increment) is echoed in the “walking skeleton” and in evolving architectures used by DevOps teams (CI/CD: Continuous Integration and Continuous Delivery).

6. The PMI / PMBOK Approach#

🟢 Novice — The PMI (Project Management Institute) publishes the PMBOK Guide, a project management body of knowledge. It does not impose one life cycle: it describes processes and knowledge areas applicable to predictive, iterative, incremental, or agile projects. The PMP certification is based on it (and for several years now has also covered agile and hybrid).

🟡 Practical — In the classic editions (up to the 6th), the guide structures the project into five process groups (initiating, planning, executing, monitoring and controlling, closing) and ten knowledge areas: integration, scope, schedule, costs, quality, resources, communications, risks, procurement, stakeholders.

The 7th edition (2021) changed logic: it moved from a list of processes to 12 principles and 8 performance domains, explicitly opening to adaptive approaches; the 8th edition, published in November 2025, keeps this principles-and-performance-domains foundation but tightens it (6 principles and 7 performance domains according to PMI).

Typical predictive tools found in any real project:

• WBS / OBS (breaking down the product or work into deliverables down to work packages);
• Critical Path (CPM) and PERT (three-point estimate: E = (O + 4M + P) / 6);
• EVM (Earned Value Management): planned value PV, earned value EV, actual cost AC. Indices: CPI = EV / AC (cost efficiency), SPI = EV / PV (schedule efficiency).
• Risk register (probability × impact), stakeholder register, RACI matrix;
• Integrated change control (change requests, control board).

EVM example: 100 person-days budgeted datamart, in week 8.

Strengths: universal vocabulary, complete toolbox, compatible with any organization (public contracts, PMO). Weaknesses: the catalog is a menu, not a method; without trade-offs, artifacts pile up; EVM applies poorly to research or discovery work (no stable “baseline”).

7. PRINCE2#

🟡 Practical — PRINCE2 (PRojects IN Controlled Environments) is a British method from public administration, now managed by PeopleCert (formerly AXELOS). Current edition: PRINCE2 7th edition (2023) (status 2026-10, check for certification updates). It is based on:

• 7 principles: continued business justification, learning from experience, defined roles and responsibilities, management by stages, management by exception, product focus, tailoring to the project environment;
• 7 themes (renamed “practices” in the 7th edition: business case, organization, plans, quality, risks, issues, progress, plus the cross-cutting “people” element (leadership, management, culture) — to be verified for exact French labels);
• 7 processes: starting up a project, directing, initiating, controlling a stage, managing product delivery, managing stage boundaries, closing.

Key concepts to retain in practice:

It is management by stages that makes PRINCE2 interesting for hybrid: within a stage, you can execute in agile — the governance framework remains (tolerances, business case, stage), execution is flexible. AXELOS/PeopleCert published a guide dedicated to alignment with agile (PRINCE2 Agile).

Strengths: clear governance, explicit early stops, very well suited to public contracts and large IT departments. Weaknesses: formalism, heaviness if all reports are applied without adaptation, risk of “PRINCE2 with a P” (ritual without thinking).

8. Merise and the French Tradition#

🟡 In Practice — Merise (1970s-1980s, France; Tardieu, Rochfeld, Colletti) is an information systems analysis and design method. It separates data and processing and distinguishes three levels of abstraction: conceptual (the what, independent of technology), logical/organizational (the organizational how), physical (implementation). Three cycles: life cycle (design → implementation → maintenance), decision cycle (choices and trade-offs), abstraction cycle (conceptual → logical → physical).

Flagship deliverables: MCD (conceptual data model, entity-relationship with cardinalities), MLD, MPD, MCT/MOT (conceptual/organizational processing models). MCD→MLD→MPD trained generations of French developers in relational databases.

Why mention it here? Because Merise is the French grandfather of data modeling and because the “French-style V-model cycle” (MOA/MOE) is its ecosystem. For data:

Strengths: modeling rigor, common language, transferability. Weaknesses: as-is modeling oriented toward transactional databases; analytical modeling (star, snowflake follows different rules (see Kimball below); sequential pace.

9. CMMI: A Maturity Framework, Not a Cycle#

🟡 In Practice — CMMI (Capability Maturity Model Integration, originating from Carnegie Mellon's SEI, now managed by ISACA) describes organizational good practices and assesses process maturity. It is not a project management method: it does not say “do X then Y,” it says “is a requirements management process defined, measured, improved?”. The maturity level model:

Version 2.0 (2018) modernized the model (practice-domain views, stated agile compatibility). The matrix principle “levels + practices” is also the one used by the maturity matrices in this section, with the difference that here we measure observable outcomes rather than process compliance (see RATING).

10. Strengths and Weaknesses: Rated Summary#

🟡 In Practice — Ratings /5, expert assessment, context: medium-sized software or data project (team of 6–15 people, 6–18 months), medium-sized organization. They are not universally applicable (cf. RATING). The full cross-table, including agile methods, is in the comparison.

Critical reading: predictability is high only if the plan is right; a 4/5 predictability rating can hide a false precision risk. Data fit remains average everywhere because the nature of data projects — discovering source quality, needs becoming clearer once people see the numbers — is not very compatible with the assumption “know everything first.” Lightweightness (overhead) is low: that is the price of governance.

11. When Predictive Is Still the Right Choice#

🟡 In Practice — Choosing predictive is not old-fashioned when:

1. Scope is externally fixed: regulation (prudential reporting, financial statements, filings), industry standard, published specifications.
2. The contract is fixed-price with an obligation of results: price and scope are fixed; a detailed plan protects both parties (see Choosing Your Method and Hybridizing).
3. The cost of a production error is extreme (human safety, finance, healthcare): verification/validation must be provable, including to an auditor.
4. The technology or migration is iso-functional: migrating a datamart from one SQL Server version to another, moving from one schema to another without changing calculation rules: everything is known, the target is comparable to the source.
5. Physical dependencies are long: hardware, tenders, infrastructure lead times, fixed delivery windows.
6. The team is distributed or outsourced without frequent interaction: documentation replaces conversation.
7. The organization has low autonomy maturity: a strong framework reassures and avoids chaos.

12. Predictive applied to data#

🟡 Practical — BI/data projects have specific traits that change how predictive approaches should be interpreted.

What fits well in a predictive framework

• Migrations (SQL Server version, compatibility level, schema, product version): known scope, objective acceptance criterion (“same numbers before/after” on a fixed dataset) → V-cycle with a non-regression acceptance testing plan.
• Regulatory deliverables: reports whose definition is external.
• Installations and kit-based deliveries: a versioned installation kit implies a deployment plan, verified prerequisites, a rollback procedure — the discipline of predictive methods (production rollout plan, operations package).
• Governance of enterprise data models: the reference model (dictionary, naming conventions) requires stability.

What resists it

• Discovering source quality: before looking, you do not know that 12% of customers have two identifiers. The plan is wrong by construction → you need a discovery pass (profiling) before committing to a firm schedule.
• Decision-making needs: decision-makers discover what they want by seeing the numbers.
• Historization and replay: historization decisions (SCD type 1/2), purge policies, load idempotence — must be decided early, expensive to change (see Modeling and Architecture).

Data-specific planning elements (to include in any predictive framework):

13. Expert: the cost of change, the cone of uncertainty, contracts#

🔴 Expert — Three ideas explain both the success and the limits of predictive methods.

1. The cost-of-change curve. The foundational argument for sequential methods is the assumption (Boehm, 1970s–80s, data from large projects) that the cost of correcting an error grows exponentially with the phase in which it is detected. This assumption has been challenged: Kent Beck (Extreme Programming Explained) argued that good technical practices (automated tests, refactoring, continuous integration) flatten the curve. The truth is contextual: the curve remains steep for hardware, contract, production data migration, regulated deployment; it flattens for well-tested code that can be deployed continuously. For a datamart: changing the name of a DAX measure before release costs a minute; changing the grain of a fact table after six months of loads costs a full reload and business revalidation.

2. The cone of uncertainty. (Boehm; popularized by McConnell in Software Estimation.) At the start of a project, the estimate varies by a factor on the order of 4 on either side (from 0.25× to 4×); it narrows as decisions are made and as work is built. Consequence: a precise commitment very early is false precision. Orders of magnitude are not measured data from your context — use them accordingly. Estimation and its pitfalls are covered in Project Management Fundamentals and in the matrix theme Planning and Estimation (PLA).

3. The nature of the contract. Predictive is above all a contractual technology: fixed-price, payment milestones, penalties, formal acceptance testing. The triangle of cost-schedule-scope is fixed (scope is the variable you try never to move), whereas agile fixes cost and schedule and varies scope (the “iron triangle” is reversed here). Hence a practical consequence: as long as the contract is fixed-price by scope, the team has an economic incentive to document deviations and reject changes; a “trust-based” relationship only holds if governance provides explicit change management with low friction. See formalizing contracts.

Useful metrics in predictive steering (read together, never alone):

These indicators are detailed, with their uses and biases, in Project Metrics and Reporting.

14. AI contribution#

🤖 AI — Where predictive approaches produce many structured documents, generative AI helps but does not replace judgment.

Prompt example: “From these 12 requirements, propose for each one a verifiable acceptance test case (input data, expected quantified result, tolerance), and flag those that are not testable.”

What AI does not replace: commitment (a human signs the plan), responsibility for acceptance testing, knowledge of real data, detection of implicit needs. A predictive-specific risk: AI produces plausible paperwork at low cost — documentation debt accumulates faster. Details in AI for Project Management (General Then Data).

15. See also#

• Logical next steps: Agile and Lean Methods (Manifesto, Kanban, XP, Lean, Shape Up, DSDM, SAFe, DevOps…) · Comparison of Project Management Methods · Choosing Your Method and Hybridizing.
• Foundations: Project Management Fundamentals · Scrum, the framework (Scrum Guide 2020) · Scrum Applied to Data, BI, and the Datamart · Methods Specific to Data Projects · Pitfalls and good practices in project management (cross-functional summary).
• Delivery: CI/CD: Continuous Integration and Continuous Delivery · CI/CD for data: foundations, datamarts, pipelines, and reports.
• Tools: project planning tools · Azure DevOps Server (ex-TFS) in Depth.
• Maturity: Governance and Steering (GOU) · Risk Management (RSK) · Scope and Requirements Management (PER).
• Glossary · Rating: Reading Ratings, Scores, and the Legend.

✻ Written by Claude Sonnet 5.5