- A Project Planning Plan
- Planning Phases
- Life-cycle Models
- Choosing a Life-cycle Approach
- An Adaptive Life-cycle Approach
- Process and Role Overlap
- Getting Planning Just Right
3.4 Choosing a Life-cycle Approach
When choosing a life-cycle model, there are three factors to consider: speed, size, and uncertainty. The evolutionary approach is great for small to medium-sized projects with a large uncertainty. RAD may be best for small, high-speed projects. Waterfall may be optimum for large projects with long time frames and low uncertainty. Adaptive models may be necessary to meet the needs of rapid, largely uncertain projects.
In choosing a life-cycle model, avoid adopting the advice of industry experts who may not typically deal with the same kind of project that you are. When making the choice of a software development approach, managers are likely to review technical magazines and books seeking expert advice. They then adopt the recommendations of the mega-expert. When magazine and book publishers solicit authors, they usually look for experts with impeccable credentials. They choose the Director of Information Technology at MegaCorp responsible for 10,000 developers working on a client-server system deployed around the globe and in orbit with 300,000 mission-critical users. These people obviously make recommendations based upon the best practices that are essential to success in their particular environment.
The problem is that these solutions aren't necessarily the most productive or optimal for the majority of applications that are not as large, have more uncertainty, or require more rapid development. Solutions don't necessarily scale up well, but neither do they scale down. Just because MegaCorp finds it invaluable, doesn't mean it works well at Modest, Inc. Still, the managers at Modest, Inc., read that the Director of IT at MegaCorp swears by it, so they decide they ought to be doing it as well.
The mega-expert may insist that a strict waterfall approach is essential to any project, but the reverse can happen as well. If a person is promoted to a large-scale project after a long string of ad hoc successes on small to medium-sized projects, he is likely to continue what has worked in the past. That approach will probably not scale up successfully.
There is no one-size-fits-all process model. You should decide whether a particular process model, or any “best practice” for that matter, is really the best solution for your particular company, for your particular project, and for your particular people.
Unfortunately, the flexibility to change process models to match each project is probably not feasible in most organizations. You should choose a process to match your corporate temperament and your typical engagement size.
For the typical project I recommend my own variation of the adaptive model that I think works well for most small to medium-sized projects and offers a high tolerance for uncertainty.