The term ‘waterfall’ is seen in lots of different posts without any clear definition of what the writers of those posts mean by the term. The only constant seems to be in each of the writer’s view ‘waterfall’ is not Agile, and generally represents bad project management practice. In summary, the agile advocates view seems to be:
Agile: A well-defined flexible project delivery process, based on the Agile Manifesto, applicable to software development and a wide range of other “soft projects” such as business change. Agile = Good!
Waterfall: Any project delivery process that is not Agile. Waterfall = Bad!
There are many problems with this simplistic viewpoint starting with the fact the concept of ‘waterfall’ had a very short life and with the possible exception of a few, very traditional, software development organizations, no one uses waterfall for anything.
History of Waterfall.
To the best of my knowledge, the first publication to use the term Waterfall was in the 1976 paper Software Requirements: Are They Really a Problem, by T.E. Bell and T.A. Thayer. This paper misrepresented the 1970 paper Managing the development of large software systems, by Dr Winston Royce[1]. Royce proposed an iterative approach to the development of large systems, but Bell and Thayer falsely claimed he supported ‘waterfall’[2].
Summary diagram from Royce 1970.
The real start of Waterfall was the publication in 1988 of DOD-STD-2167A by the US Department of Defense, which established uniform requirements for the development of software based on the Waterfall approach[3].
Extract from DOD-STD-2167A
Problems with the Waterfall approach were quickly identified and in 1996 MIL-STD-498 was released by the US Department of Defense to correct the problems. Officially Waterfall was dead and buried but many companies had adopted waterfall and because waterfall projects were slow and subject to delay, hourly paid staff and contractors had a powerful incentive not to change despite many better software development processes being developed starting from the early 1980s.
Other types of projects and project delivery.
Waterfall was a short-lived software development methodology. The vast majority of projects in the construction, engineering, oil & gas, defence, and aerospace industries use project delivery methods based on the approaches described in A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Sixth Edition, and a range of other standards. These other projects generally have three phases:
- A definition phase undertaken by the client organization to define the capabilities of the product being developed
- A procurement phase where the client selects a delivery agent for the development of the product
- A delivery phase where the delivery agent builds and delivers the product
The design of the product (ship, building, rocket, etc.) may be undertaken in full or in part during any one of the three phases. A minimum level of design is required to initiate procurement, but for simple buildings and civil engineering projects, it is not unusual for a complete design and specification to be provided by the client.
The procurement phase may be a simple pricing exercise, or a complex, and phased, design process (sometimes even involving the production of working prototypes), with selection being based on the capabilities of the design produced by the successful tenderer.
Then, in many projects, a significant amount of detailed design is still required during the delivery phase, including shop drawings produced by subcontractors and suppliers.
Similarly, the procurement arrangements vary widely. The client may choose to enter into some form of alliance or partnership with the preferred delivery agent based on shared risk and profits, or the client may choose a hard-dollar contract based on a fixed price to deliver a fixed scope, or some other form of contractual arrangement.
The only certainties are that the typical project approaches used for the vast majority of ‘other’ projects bear no resemblance to the waterfall approach, and this ‘other’ classification includes more than two-thirds of the world’s projects by value.
Conclusions
- I suggest it is time to follow the US DOD lead from 1994 and bury the concept of ‘waterfall’ – using the name 30 years after it was officially dropped is long enough.
- People involved in the ‘Agile’ industry need to wake up to the fact that software development is only one of many types of project. Most of the ‘other’ types of project do not use Agile, and they certainly don’t use waterfall.
- Agile and agility are not synonymous – all organisations benefit from a degree of agility, but this has nothing to do with selecting the best project delivery methodology (more on this later).
- In the 21st century, Waterfall is not synonymous with over documentation and/or bad project management. There is plenty of bad project management practice around. But bad management needs to be called out for what it is – 99.999% of the time the bad managers are not trying to use waterfall in their work.
Ditching the concept of waterfall does create a couple of challenges – we all have an understanding what Agile means as a project delivery process, we need similar generally accepted classifications for other types of project delivery – more on this later. Similarly, the bad management practices branded as ‘waterfall’ need to be identified and understood, you cannot improve a bad process until the root cause of the problem is understood.
For more on Agile management see: https://mosaicprojects.com.au/PMKI-ITC-040.php#Process1
Note: THE MYTH OF THE ‘WATERFALL’ SDLC by expands on this post in far greater detail and is highly recommended as a reference: http://www.bawiki.com/wiki/Waterfall.html
[1] Download a copy of the 1970 Royce paper: https://mosaicprojects.com.au/PDF-Gen/Royce_-_Managing_the_development_of_large_software_systems.pdf See Fig. 10.
[2] Download a copy of the 1976 Bell & Thayer paper: https://mosaicprojects.com.au/PDF-Gen/software_requirements_are_they_really_a_problem.pdf
[3] Download DOD-STD-2167A Defense System Software Development (1988): https://mosaicprojects.com.au/PDF-Gen/DOD-STD-2167A.pdf
Pat Weaver
Lynda Bourne
Aavssitedev's Blog
I don’t know, Pat… Better do more research?
What is called “Waterfall” coming from the IT aficionados is actually a MISNOMER. The “Phase Gate Method” dates back OFFICIALLY to around 1955, coming from either Esso (now ExxonMobil) or Diamond Shamrock Oil, and shows the INTEGRATION of the Asset Life Span combined with the Project Life Span. But I suspect it was in “common use” well before that, evolving as the “best tested and PROVEN” model with the exploitation of oil starting in 1859. (https://msipipeprotection.com/brief-history-oil-drilling-us/)
To see an example of the full or complete Asset v Project Management Life Spans (still in use today), here is a graphic clearly showing the relationship between the Asset Life Span and the Project Life Span coming from a published paper by Chevron Oil (Figure 17 https://build-project-management-competency.com/1-4-1-1-unit-1/) and another from Zadco Oil (circa 1990) which is now a consortium between ADNOC, ExxonMobil and JODCO). Figure 22 shows the Asset and Project evolution life spans, based on what is known in construction as the “MacCleamy” or “Paulson” curve which was developed about 1970 by the IT sector and known as the “Boehm” Curve. https://www.danieldavis.com/macleamy/
So your claims that “Waterfall” did not originate with the US Government, but much earlier with oil and gas, circa 1955 and probably much earlier, around 1860.
Also worth noting is that what was shown in the PMBOK Guide (Figure 2-13) failed to show that it was an INTEGRATED Asset and Life Span model. Mercifully, PMI has “retired” the 6th Edition before it causes any further damage or half truths. https://www.pmi.org/-/media/pmi/documents/public/pdf/pmbok-standards/faq-pmbok-guide-sixth-edition-retirement.pdf
If you go here, https://build-project-management-competency.com/1-4-1-1-unit-1/ Figures 11 through 22; you can see the CORRECT progression, especially Figure 11, which shows the PROJECT ASSET DELIVERY options that are based on the % of SCOPE or OBJECTIVE AND the tolerance of changes by the key stakeholders. Those two variables determine which “Project Delivery Option” should be chosen.
Curiously enough, we just signed a 2-year-long “pilot project” to develop and improve what is known in oil and gas as “Front-end loading” (FEL) processes. (Asset Phase Gates 1, 2, 3 and 4). As your Conclusion #4 alludes to the fact that if OWNER ORGANIZATIONS would follow the PHASE GATES of the INTEGRATED ASSET and PROJECT LIFE SPANS, they would do a better job of producing more SUCCESSFUL ASSETS. Whether the PROJECTS will be more or less successful remains to be seen, as while we may or may not see any CORRELATION, we remain skeptical that there is necessarily any CAUSATION between the success or failure of the PROJECT and the success or failure of the ASSET produced by the project. (See Sydney Opera House?)
Pat, if you have not done so yet, take 10 minutes time to watch this INTEGRATED video from the UK’s Institute of Asset Management https://www.youtube.com/watch?v=Zp62O373q3c&t=16s and then look at the companies that belong to the IAM. https://theiam.org/corporate-directory/
You can also download the IAM’s “The Anatomy of Asset Management”- https://theiam.org/media/1486/iam_anatomy_ver3_web-3.pdf and the IAM’s “Specifications for Optimized Management of PHYSICAL (or any ASSETS!!!) https://theiam.org/knowledge-library/bsi-pas-55/
After reading these references, you can appreciate why looking at PROJECT MANAGEMENT (ISO 21500) without integrating it with ASSET MANAGEMENT (ISO 55000) will never work.
“Project Management” is primarily the realm of CONTRACTORS and CONSULTANTS. Project management is the primary DELIVERY SYSTEM for not only PHYSICAL ASSETS but ALL 5 classes of ASSETS. This is why OWNER organizations struggle implementing projects using project management tools & techniques IN HOUSE using their own people. (The world of the “accidental” project managers.)
This goes back to Esso or Diamond Shamrock with their “Integrated Asset, Portfolio, Program and Project Management Business Model” from 1955.
Some definitions of waterfall and critical success factor for ânot waterfallâ
https://www.sciencedirect.com/topics/computer-science/waterfall-methodology
Click to access pr-15-0045-making-agile-work-in-government.pdf
Click to access AD1107788.pdf
From https://www.mitre.org/sites/default/files/pdf/08_0906.pdfTraditional
systems engineering approaches such as the waterfall method predicated on long development cycles and emphasizing formally structured requirements, specifications, and integration testing at the end of the project are no longer practical and new approaches such as spiral development are being tried.
Glen B. Alleman, MSSM, USC
Integrated Program Performance Management
[signature_3854252480]
+1-303-241-9633
glen.alleman@niwotridge.com
Here’s MIL STD 2167
http://everyspec.com/DoD/DoD-STD/DOD-STD-2167A_8470/
to see that Iterative anbd incrementla development is the SW development standard in the US DoD since 22 October 1983
2167A (1988) replaces 2167 (1985) which was an iterative standard. While 2167A (1988) states any method can be used, it explicitly requires a fully detailed plan to be prepared before work starts and specifies the testing sequence – waterfall in all but name.
2167A was replaced by MIL-STD-498 in 1994 which was more amenable to iterative developments.
That Plan is called the Integrtaed Master Plan (IMP)
The IMP is part of the proposal, with its
– Program Event
– Significant Accomplishments
– Accomplish Criteria
With the IMP, the Integrated Master Schedule can be developed, and placed on baseline to be reviewed at the Integrated Baseline Review (IBR). The Tasks and their Work Packages in the IMS, feed the Accomplishment Criteria. These items can follow several topologies, Iterative and Incremental is the common one for software intensive systems in our domain. But the structure of the IMS changes are the program proceeds dependent on the changes tot eh baseline as the program proceeds, through the Change control process during execution.
But the IMP and it’s SAs and ACs requires a contract change, since those are the basis of progress payments from the contract.
Take a look at DOD-STD-2167 and DOD-STD-2167A to see that the term “iteration” appears 15 times.
The diagram you posted (Figure 1 – System Development cycle) in both standards, with the system life-cycle, is the Integrated Master PLAN for the IMP Program Events – SRR, SDR, SSR, PDR, CDR, TRR and NOT the Integrated Master Schedule
2167 was based on an iterative approach.
2167A mentions ‘iterative’, but requires a complete fully detailed plan that cannot be changed before work starts and specifies in detail the sequence of development – ‘waterfall’ in all but name.
2167A installs rhe Integrated Master Plan, just a 2167 did.
Yes the “fully detailed plan” is on Baseline as part of the contract award. The detailed sequence of work is also on baseline starting with the propose and cannot be changed without a Contractural Baseline Change process.
This is contractual process of DoD acquisition. It may not be your domains process, but it is our.
Any changes are made through the formal Change Control process.
But since the IMP is NOT the schedule, the actual structure of the work processes are not defined in 2167.
Figure 1 in 2167A is NOT a schedule it is a PLAN, defined by the Program Events – this are NOT milestones. The Program Events (PEs) SRR, SDR, … PDR, CDR, TRR not milestones,
Program events as described in the IMP-IMS Step-by-Step guide I sent before and restated here with a DoD Logo https://tinyurl.com/yk3zlq8c