Wednesday, July 25, 2012

Why Waterfall Gurantees Wrong Solution: Project Management


I think this applies for IT jobs where the customers really don't have a good idea of what they want, it doesn't apply to things like compilers or cell phones where the functionality is usually based 95% of what the last version or competitor was. 


It is still good to have a waterfall to have some sort of plan in place that puts some bounds of what is to be done and how it is going to be done. I have seen too many projects use Agile as an excuse to not have a waterfall process or plan at all. 


A Better Project Model than the "Waterfall"

This happens every day: A "solution" is handed to a team to build. The team determines the scope of the work, develops a project plan and promises a set of features by a specific date. It is assumed that these features will solve some business problem or meet an executive directive because someone with a paygrade higher than the execution team has blessed the work. And with this set of features and project plan the waterfall cycle begins again.
The team begins to define the work in painstaking detail, outlining every possible scenario, use case, back-end integration point, and business rule. The design team takes it from there, visually articulating the placement of every pixel and the logic behind every input field, check box, and submit button. Soon the software engineers will get their turn at bat followed closely by their compatriots in quality assurance and then, finally, after the t-shirts have been printed and the launch parties have died down, the company's customers will get their first chance to use the new product.
Despite the confidence inspired by all of this upfront planning and design, the only guaranteed thing to come out at the end of this waterfall process is the wrong solution. It's not that the project sponsor chose an inadequate feature set or that the system's user experience was poor. The team delivered the wrong solution because the project was based on unvalidated assumptions. These assumptions were presented as requirements and as such were not positioned as something that could be disproved or even questioned.
article continues here

No comments:

Post a Comment