Artifact: Project Plan

Purpose

The following people use the project plan:

• The project manager, to plan the project schedule and resource needs, and to track progress against the schedule.
• Project team members, to understand what they need to do, when they need to do it, and what other activities they are dependent upon.

Brief Outline

1. Objectives

A brief description of the purpose of the Project Plan.

2. Scope

A brief description of what the Project Plan applies to; what is affected or influenced by this document.

3. References

A list of related or referenced documents.

4. Phase Plan

An overall project "road map", showing how to allocate time to the phases and specifying what will be achieved at each major milestone. Include a timeline or Gantt chart.

5. Schedules

Diagrams showing iterations within phases, release points, demos, and other milestones.

6. Objectives of Each Iteration

Brief descriptions of what the iterations are called, the main objectives are for each iteration, what risks they address, etc.

7. Releases

Brief descriptions of each release, whether demo, beta, etc.

8. Resource plan

Organization, staffing plans, training plans.

9. Cost

The project’s budget.

Timing

The project plan is created during the Inception phase, and updated throughout the project as changes occur, but especially at the end of an iteration.

Responsibility

The Project Manager is responsible for the integrity of the Project Plan, ensuring that:

• The Project Plan is up to date and accurately reflects the best available project information.

Additional Information

To build a phase plan for a project in the initial development cycle, you may have to make some educated guesses about milestones on the basis of experience, degree of novelty, specific environment constraints, and the maturity of the organization.

If the product is in an evolution cycle, the phase plan may be easier to define.

• Towards the end of the inception phase, a more accurate phase plan can be defined, taking into account the number of use cases identified and their complexity, risks identified, and the result of any prototyping.

This very rough plan is updated during the elaboration phase. It serves as the basis for building the project plan.

To build the project plan, you can assume at least one iteration per phase (unless you have a very simple development effort):

• One iteration in the inception phase, producing for example some proof-of-concept prototype or some user-interface mockup.
• One iteration in the elaboration phase to produce an architectural prototype.
• One iteration in the construction phase to build the product (up to beta release).
• One iteration in transition to finish the product (general availability release).

From there, many variations are possible (see "Iteration Strategies" in Guidelines: The Iteration Plan):

• If the product is exploring a totally new domain, you may need to add iterations in the inception phase to consolidate the concepts, show various mock-ups to a cross-section of customers or end users, or build a solid response to a request for a proposal.
• If a new architecture must be developed, or there is a large amount of use-case modeling, or there are very challenging risks, you should plan to have two or three iterations in the elaboration phase.
• If the product is large and complex, and developed over a long period, you should plan to have three or more iterations in the construction phase.
• You should plan to have several iterations in the transition phase if, because you must minimize the time to market, you must deliver the product with a reduced set of functionality, or if you feel you might need a lot of small adaptations to the end-user base after a period of use.

Be aware, however, that the larger the project is, the larger the development organization will be, and the longer the iterations will be. This is due to the time and effort involved in communication within a large organization.