Ars Technica has an interesting read on Microsoft’s evolving development practices. The article has a perfect description of the development practices at UNC:
For example, lots of companies develop in-house applications to automate various business processes. In the course of developing these applications, it’s often discovered that the old process just isn’t that great. Developers will discover that there are redundant steps, or that two processes should be merged into one, or that one should be split into two. Electronic forms that mirror paper forms in their layout and sequence can provide familiarity, but it’s often the case that rearranging the forms can be more logical. Processes that were thought to be understood and performed by the book can be found to work a little differently in practice.
Often, these things are only discovered after the development process has begun, either during development or even after deployment to end users.
This presents a great problem when attempting to do all the design work up front. The design can be perfectly well-intentioned, but if the design is wrong or needs to be changed in response to user feedback, or if it turns out not to be solving the problem that people were hoping it would solve (and this is extremely common), the project is doomed to fail. Waiting until the end of the waterfall to discover these problems means pouring a lot of time and money into something that isn’t right.
“We spent money on it years ago and it needs to be implemented” never ends up well.