An interesting risk comes near the end of a project, at the moment the
"consumer bit" flips. By this we mean that the users go from believing that
nothing will ever be delivered to believing that the team might actually
pull it off. The good news is that the external perception of the project has
shifted: whereas on Monday the users would have been happy if anything
were delivered on Tuesday, they become concerned that not everything
will be delivered. This is the bad news. Somewhere between the first and
second beta, you find yourself inundated with requests for features that
people want to be sure are included in the first release. Suddenly, these
become major issues. The project manager goes from worrying about
delivering minimal acceptable functionality to a situation in which every
last requirement is now "essential" to the first delivery. It is almost as
though, when this bit flips, all outstanding items get elevated to an "A"
priority status. The reality is that there is still the same number of things
to do, and the same amount of time in which to do them. While external
perceptions may have changed, prioritization is still very, very important.
If, at this crucial moment, the project manager loses his nerve and starts
to cave in to all requests, he actually puts the project in schedule danger
again! It is at this point that he or she must continue to be ruthless and
not succumb to new requests. Even trading off something new for
something taken out may increase risk at this point. Without vigilance,
one can snatch defeat from the jaws of success.
"From Waterfall to Iterative Development" [PDF]
Previous Topic
