My first post in this series introduced the following evaporating cloud:
This cloud shows the conflict faced by projects - do we allow changes and keep the customers happy OR do we not allow changes and keep the date and budget? Now I want to talk about how the most common way of producing software - the Waterfall Software Development Lifecycle - try's, but fails, to break the conflict. The essence of the waterfall approach is to "prevent change": thus preventing rework, thus only doing the bare minimum, thus being the most efficient way of producing software. It does this by spending the proper time upfront to get the customer's requirements fully, unambiguously, documented and signed off before starting the design. With change (theoretically) prevented the designers can do the very best design, without interuption, and then hand it over to the programmers, who can too work without interuption. The developers eventually hand over their code to be user acceptance tested by the future users who check that everything they signed-off on all those months ago is complete. Then the software is implemented in one BIG-BANG and everyone lives happily ever after. Unfortunately, there are some unpleasant sideffects - as I've tried to show in page 1 of the "Current Reality Tree" (CRT) below. This CRT is a Theory of Constraints thinking tool that shows the cause and effect at play within my "current reality" - the project I currently work on. It's not, perhaps, the prettiest CRT on earth and I've broken a few of the rules, but it's GOOD ENOUGH for my purposes. Read the tree from the bottom up. The boxes at the tail of an arrow cause the boxes at the head of the arrow. Follow your nose and you'll get the idea. 
In short, there are some pretty icky side-effects of this approach - late integration failure, bloated software being two. But it gets worse. The rationale for the waterfall is that you can prevent change, but you can't, as shown in page 2 of the CRT below. 
Try as you might you can't prevent change. In fact, because the software takes so long to specify and build - and don't forget it's probably about 40% bigger than it needs to be, there's ample time for things to change. So your setup "change control" procedures to eithor approve or reject the change. Since you're working on virtually everything, all at the same time, you can't easily swap functions in the changed function and swap out something else to maintain the same finish date. Instead you slip your promised date, enforce overtime or miraculously absorb the change into your plan. At some stage this "scope creep" results in too much slippage and the product is descoped (triaged is the politically correct term) to bring the dates in. At the end of the day your customers aren't happy with the final product because you've produced bloated software that doesn't suit their needs AND you've probably slipped your schedule a couple of times or more.
[BTW: The seminal waterfall article was written by Winston Royce in this 1970 article. Poor chap Royce since he preferred the iterative/incremental approach, now favoured by the "agile" community, but is labelled as the inventor of the much disliked waterfall].
