Review Blastoff Results (Process Notes 1.3.2)

Look at the requirements skeleton and compare what has been collected with the requirements template. Determine whether there is enough of a skeleton to reasonably complete the requirements specification. The template is a guide to the requirements specification that you have to write. The intention is not to have a complete specification at this stage, but to know if, given the time, the specification can be built.

Were the objectives from the blastoff meeting plan met? In other words, are the blastoff deliverables enough to get started on the task of gathering the correct requirements?

Are there any outstanding questions? Make a list of all outstanding problems. If the deliverables are incomplete, then the outstanding questions serve as input to a follow-up blastoff meeting.

This process makes the decision on whether the project is to go ahead. The go/no go decision must be a conscious task. The question may be asked several times during the blastoff meeting.

Jim Highsmith and Lynne Nix, in "Feasibility AnalysisMission Impossible" (Software Development, July 1966), produced the following checklist for identifying when you should not go ahead with a project:

1. Major political issues are unresolved by the blastoff.

2. Key stakeholders won't participate in the blastoff (and therefore probably the project).

3. Risks (probability of adverse consequences) are too high (technical, economic, organizational).

4. The cost-benefit ratio isn't favorable enough, especially when benefits are not measurable.

5. The internal staff's experience and training is insufficient for the project.

6. Requirements are unclear, or keep changing radically during the blastoff.

7. The risk-reward ratio is unfavorable. High risks usually need a high reward to be worthwhile.

8. Clients (in a multidisciplinary project) can't agree on exactly what the problems or objectives are.

9. No executive wants to be the project's sponsor.

10. Implementation planning seems superficial.

• There must be a measurable statement of the system objectives.

• The customers must be satisfied that the product is worthwhile.

• The developers must satisfied that they will be able to build the product.

• Both have to be satisfied with the estimates to build the product.

• The end users have to be satisfied that the product will be beneficial to them.

If things are do not look promising at this stage, it is far more economic to abandon the project now rather than in several years' time. Remember that the principal objective of the blastoff is to determine whether the project is feasible.