 If you read my blog, or have heard me speak, you know I'm not a fan of
serial lifecycles, such as waterfall. In fact, unless you have a short
project, where you know the requirements (and they won't change), and
your project team is stable (and won't change), I recommend against a
serial lifecycle. But if you work in an organization where your
management is firmly wedded to serial lifecycles, you need to make the
best of the situation.
First, let me explain what I mean by a serial lifecycle. First the requirements folks define the requirements. After the requirements are "complete," the architects do their analysis and high level design. Then the developers do their low-level design. After design, the developers start coding. Finally the testers start testing, possibly during development, but more likely during integration or even after integration. (It's possible for testers to design their tests starting after the requirements, but most organizations don't allow the testers to start their work until the coding has started.) After many exhaustive cycles of code-integrate-test, the organization releases the product.
It's all but impossible to obtain feedback about the work that's been done so far until coding has started. (Feedback here, is how the product is working--or not. The feedback is product feedback to the requirements folks, architects, designers, and developers.) And the real feedback doesn't happen until the testers start testing. In organizations that transfer the project from one functional group to the next, it's likely that the testers are the first people to produce feedback to the requirements folks, the architects, the designers, and the developers. That occurs very late in the project.
If you are stuck with a serial lifecycle, consider these early-in-the- project options for making that lifecycle work for you:
1. Timebox the requirements work.
I have yet to encounter a project where anyone could know all the requirements at the beginning. So, instead of trying to know all the requirements, work on obtaining the most valuable requirements and defining them so the developers and testers can start. Spend as little time as possible on this step. If you have a 9-month project, spend no more than a month on defining the requirements. Sure, not all the requirements will be defined. But the most valuable requirements--those should be clear.
2. Re-estimate at the end of each phase or stage.
When the serial lifecycle was initially defined and refined in the literature, there was a notion of gates or stages. In order to pass through the gate or successfully end the stage, management held a project review. At the management review, the project team (or
manager) explained the current progress, including the total money and time spent on the project to date, and the re-estimated amount of money and time projected to successfully conclude the project. (Most of my clients did away with these management reviews in the mid-80's, when it became impossible to predict the end of the project without actually finishing the project.)
Even if you don't have management reviews, you can still re-estimate your projects as you proceed. You do know more about this project now, even if you still don't know when you'll be done. The project team will realize more about what they do and don't know about the project. They are more likely to break the remaining tasks into smaller chunks, which will allow them to make better estimates.
3. Use prototypes wherever possible.
One of the big risks in a serial lifecycle is that the architecture (or the GUI design) ends up being not quite right for the product or the users as the requirements evolve.
One answer is to restrict changes to the requirements, but that leads to the problem of "You built what I asked for, but not what I needed." (I've met very few projects that could restrict requirements changes. Too often those requirements changes affect the architecture.)
Another alternative is to build prototypes of the architecture (or the GUI), or whatever risky area of the product you might need to explore. The way I suggest you build architectural prototypes is to fully implement several features, but not all the architecture. If you implement several features, implementing just what you need to make this feature or that one work, you will have holes in the overall architecture and design. That's ok. Your goal here is to gain feedback on the architecture, not to implement the whole darn thing.
For the GUI, consider paper prototypes, which take much less time to develop than any electronic prototype. You'll learn about what needs to change in the workflow as soon as someone uses the prototype. Once the workflow seems stable, it's reasonable to develop some electronic prototypes, to test the rest of the GUI.
I'll have more tips for the middle of the project in next month's issue of the CM Journal.
Johanna Rothman consults, speaks, and
writes on managing high- technology product development. She enables
managers, teams, and organizations to become more effective by applying
her pragmatic approaches to the issues of project management, risk
management, and people management. Her most recent book is "Manage it!
Your Guide to Modern, Pragmatic Management."
Trackback(0)
Comments 
Write comment
 |
CM Journal Articles 
TrackBack URI for this entry
Subscribe to this comment's feed