Waterfall project management is a linear, sequential methodology where progress flows steadily downward through defined phases, much like a physical waterfall. In this model, each stage—such as requirements, design, implementation, and testing—must be fully completed and approved before the next one begins.
Waterfall Project Plans, .xls and .mpp file formats respectively
Core Characteristics
Sequential Design: No overlapping phases; each “cascades” into the next.
Documentation-Driven: Extensive upfront planning and detailed records are required at every step.
Fixed Scope: Requirements are gathered at the start, making the project’s timeline and budget highly predictable but difficult to change.
Specialised Use: Best suited for regulated industries like aerospace, construction, and healthcare, where changes are costly or safety is paramount.
Historical Timeline by Era and Year
The following timeline tracks Waterfall from its origins in post-WWII engineering to its current role in hybrid project management.
Examples, Waterfall Plan On a Page POaP in MS PowerPoint format
The Pre-Formal Era (1950s – 1969)
Software development adopted structured, sequential approaches from engineering, largely driven by complex, high-risk projects.
1956: Herbert D. Benington documented a sequential process for the SAGE project, establishing the technical roots.
Late 1960s: NASA applied linear, rigid methodologies to Apollo missions, setting a precedent for high-stakes, documentation-heavy development.
1968: The NATO Software Engineering Conference highlighted the “software crisis,” prompting a push for formal, disciplined development models.
The Formalisation Era (1970 – 1979)
The model was officially, yet ironically, described and named.
1970: Dr. Winston W. Royce published his foundational paper on managing large software systems, often cited as the origin of the “Waterfall” model, though he originally presented it as a cautionary, flawed approach.
1976: T.E. Bell and T.A. Thayer likely first used the term “Waterfall” in literature.
The Institutional Era (1980 – 1999)
Waterfall became the mandatory standard for large-scale, complex projects.
1985: The U.S. DoD mandated DOD-STD-2167, cementing Waterfall as the standard for military software.
1989: The UK Government introduced PRINCE2, deeply influenced by Waterfall principles.
1994: The U.S. DoD formally abandoned strict Waterfall mandates for more flexible methods.
The Modern & Hybrid Era (2000 – Present)
Waterfall transitioned from the default standard to a specialised methodology.
2001: The Agile Manifesto marked a shift toward iterative development, reducing Waterfall’s dominance.
Present Day: It remains vital in regulated sectors (e.g., aerospace) and is often combined with Agile in hybrid approaches.
Waterfall project management is a linear, sequential methodology
Click on the link in the website banner above to purchase example, editable template project plans shown and many others.
Scrum is a lightweight framework within the broader Agile methodology used to manage complex work through iterative, incremental delivery. It organizes work into fixed-length cycles called sprints, typically lasting two to four weeks, to deliver a usable “increment” of value at the end of each cycle.
Core Components (The 3-5-3 Structure)
The framework is built around three accountabilities, five events, and three artifacts.
1. Three Accountabilities (Roles)
Product Owner: Represents the customer and stakeholders. They manage the Product Backlog and prioritize work to maximize the value delivered by the team.
Scrum Master: A servant leader who coaches the team on Scrum theory and removes impediments that block progress.
Developers: A cross-functional, self-managing team that does the actual work to create the product increment.
2. Five Events (Ceremonies)
The Sprint: The container for all other events; a time-boxed period where work is performed.
Sprint Planning: The team defines what will be delivered in the sprint and how the work will be achieved.
Daily Scrum: A 15-minute daily check-in for developers to synchronize progress and plan the next 24 hours.
Sprint Review: Held at the end of the sprint to inspect the outcome with stakeholders and adapt the Product Backlog.
Sprint Retrospective: An internal team meeting to reflect on the process and identify improvements for the next sprint.
3. Three Artifacts
Product Backlog: An ordered, evolving list of everything needed for the product.
Sprint Backlog: The subset of product backlog items selected for the current sprint, plus a plan for delivering them.
Increment: The concrete sum of all completed backlog items that meet the Definition of Done.
The Three Pillars of Empiricism
Scrum is founded on empirical process control, which relies on:
Transparency: The process and work must be visible to everyone involved.
Inspection: Frequent checks of artifacts and progress to detect variances.
Adaptation: Adjusting the process or product if an inspection reveals unacceptable deviations.
Key Values
Success with Scrum depends on the team’s commitment to five core values: Commitment, Courage, Focus, Openness, and Respect.