One of the most useful decisions a project manager can make at the beginning of the project is to choose a lifecycle for the project. Here’s the way I think about lifecycles:
Not every lifecycle is appropriate for every project. In fact, many lifecycles are inappropriate for many projects. If you can’t determine the requirements fully at the beginning, don’t use a waterfall. If you don’t have a lot of time, plan to chunk the product, either with the chunking lifecycles or with the agile lifecycles.
Test groups get into trouble when they think they can use a waterfall lifecycle. Most of the test groups I’ve met don’t know the requirements before they start developing their tests, so I regularly recommend that the test groups choose a different lifecycle from the rest of the project. Sure, it’s harder to integrate the milestones, but how else can you succeed?
Think about what your customers think is important (time to market/release, feature set, defect levels). In what order does schedule, feature set, or defects matter to which of your customers? Then, review your risks.
If you think you’re going to learn a lot with this project, you have tremendous technical risk. If you know a lot about what you have to do, but the time is short, you have schedule risk.
When you have both schedule and technical risk, consider using an agile lifecycle. If you have just schedule risk, consider a chunking lifecycle. For just technical risks, an iterative lifecycle.
If you’re an experienced project manager, you can divide up the project into several phases, each with it’s own lifecycle (I once led a research phase using a spiral lifecycle, and then moved to design to schedule for the deliverable part of the project).
No lifecycle is completely perfect, but each has possibilities for your project. Consider which lifecycles are most appropriate for your use on this project.