Software Project Survival Guide

1. The Successful Project at a Glance

1.1. The project uses a staged delivery approach

1.2. Upper management, the customer, or both track progress by following the code growth curve

1.3. Upper management, the customer, or both track progress by keeping tabs on major milestones and deliverables

2. Quality Assurance

2.1. Project has a written, approved Quality Assurance Plan

2.1.1. Project isn’t following the written plan

2.2. Quality assurance is initiated in parallel with requirements work

2.3. Defect tracking software is placed online at requirements development time, and defects are tracked from the beginning of the project

2.4. Developers review all designs and code before they are considered to be "done"

2.4.1. No designs or code have failed their reviews, suggesting that reviews are superficial

2.4.2. Developers don’t source trace and unit test their own source code prior to submitting it for review, which gives rise to an unwieldy number of defects that have to be tracked from reviews onward

2.5. The Quality Assurance Plan calls for an independent quality assurance group

2.5.1. No funding is available for an independent quality assurance group

2.6. The Quality Assurance Plan contains measurable criteria to be used to determine whether the software is ready to be released

3. Architecture

3.1. The architecture team creates a Software Architecture document

3.1.1. The Software Architecture document has not been placed under change control

3.1.2. The Software Architecture document has not been updated to reflect changes arising during design and construction and no longer accurately describes the program

3.1.3. Developers don’t observe the project’s architecture

3.2. The architecture emphasizes simplicity over cleverness

3.3. The architecture supports the Staged Delivery Plan

3.4. The architecture addresses all the project’s requirements, and requirements coverage is documented with a completed requirements traceability matrix

4. Final Preparations

4.1. The project team creates its first estimate after preliminary requirements development is complete

4.1.1. Estimates do not account for normal activities such as holidays, weekends, and vacations

4.1.2. Developers don’t believe the estimates are realistic

4.2. Estimates are updated after detailed requirements development and again after architectural design

4.3. The project has a Staged Delivery Plan that organizes the stages into theme releases

4.3.1. The stages are not defined in detail

4.4. The project’s vision, risk management, decision making, and personnel plans are up to date

4.5. The project’s Software Development Plan is up to date and being followed

5. Survival Concepts

5.1. The project’s processes are generally oriented toward detecting as many problems upstream as possible.

5.2. Project leadership understands the critical role of well-defined processes and supports them

5.3. Project leadership recognizes that estimates made during the first half of the project are inherently imprecise and will need to be refined as the project progresses

6. Survival Skills

6.1. The project team creates a detailed written plan designed to eliminate potentially costly problems early in the project

6.2. The project emphasizes the importance of upstream work by holding Planning Checkpoint Review and making a go/no go decision when the project is about 10 percent complete

6.3. The project practices active risk management

6.4. Project plans emphasize visibility and control

6.5. The project plan involves real users early and throughout the project

6.6. The project is conducted in a productive environment, or the project plans assume lower productivity

6.7. Project plans call for a simple-to-complex approach rather than the reverse