12 Tough Questions for Waterfall Projects

Type: Principles
Sources: I stole the idea from Tom Gilb's (generic) 12 Tough Questions


To show waterfall projects what they are missing; to show waterfall projects that say they have always been 'agile', that they really have not.

Principles and Notes

1) why aren't you able to show some useful piece of product after less than 10% of scheduled project time?

2) how do you know that you will hit the scheduled delivery date, at the start of the project?

3) how productive is your team, in terms of features delivered per month? why don't you know?

4) how do you prevent gold-plating before all the necessary features are done?

5) do you know how many defects you have implemented in the latest version of your product? why did you implement those?

6) what if you want to choose between fixed-date and fixed-scope near the end of your schedule?

7) how long does it take you to know wether a change to the system caused ripple effects?

8) how do you know that every feature you deliver is useful by the date of delivery?

9) why aren't you able to deliver a useful system halfway through the project schedule if management wants you?

10) why isn't your team committing to deliver the feature set planned for the project?

11) if the requirements will change anyway, why do you write them down way in advance?

12) do you pay your contractors cash money, even if they have not provided you with a valuable solution to your problem yet?

Related Pages

rating: +1+x

If you want to know more about a topic, simply tag the article with a 'morePlease' or 'examplesPlease' tag!


Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License