Activity: Develop Project Plan

Define Project Milestones

The project plan first defines the dates and nature of the major milestones (see Concepts: Phases). This part of the project plan serves as the overall "road map" to the project and is created at the beginning of the project (inception phase).

To plan the phases for a project in the initial development cycle, you may have to make some educated guesses about milestones on the basis of:

• Experience with projects similar in nature and domain.
• The degree of novelty.
• Specific environment constraints such as response-time, distribution, and safety.
• The maturity of the organization.

All phases are not identical in terms of schedule and effort. Although this varies considerably depending on the project, a typical initial development cycle for a medium-sized project should anticipate the following distribution between effort and schedule:

which can be depicted graphically as

For an evolution cycle, the inception and elaboration phases would be considerably smaller. Tools which can automate some portion of the Construction effort can mitigate this, making the construction phase much smaller than the inception and elaboration phases together.

For more information on how to define the length of iterations and the number of iterations, see Guidelines: Project Plan.

Define Milestone Goals

Each milestone is focused on a specific deliverable; each provides a well-defined transition point into the next phase.

Each milestone represents a critical hurdle that the project must clear; at each milestone the project faces a go/no-go decision.

The Lifecycle Objective Milestone

The evaluation criteria for the inception phase are:

• Stakeholder concurrence on scope definition and cost/schedule estimates
• Requirements understanding as evidenced by the fidelity of the primary use cases
• Credibility of the cost/schedule estimates, priorities, risks, and development process
• Depth and breadth of any architectural prototype
• Actual expenditures versus planned expenditures.

The project may be aborted or considerably re-thought if it fails to reach this milestone.

At the Lifecycle Objective Milestone, the Business Case is reviewed to ensure that the project is economically viable. The Project Plan (rough though it is) is reviewed for reasonability and consistency with both the Business Case and with accepted practice:

• Resource estimates in the Project Plan must be consistent with the project budget (focusing on the time, staff, and development environment costs in particular)
• The Project Plan should not assume productivity levels significantly different than average experience; if the project is significantly harder than anything the organization has successfully completed before, productivity estimates should be scaled back to reflect the greater challenge of the project.

The Lifecycle Architecture Milestone

The main evaluation criteria for the elaboration phase involve the answers to these questions:

• Is the vision of the product stable?
• Is the architecture stable?
• Does the executable demonstration show that the major risk elements have been addressed and credibly resolved?
• Is the plan for the construction of sufficient detail and fidelity, and is it backed up with a credible basis of estimates?
• Do all stakeholders agree that the current vision can be met if the current plan is executed to develop the complete system, in the context of the current architecture?
• Are actual resource expenditure versus planned expenditure acceptable?

The project may be aborted or considerably re-thought if it fails to reach this milestone.

At the Lifecycle Architecture Milestone, the architecture of the product must be stable. The need for this stability is dictated by the nature of the Construction phase: in Construction the project  typically expands, adding developers who will work in parallel, communicating loosely with other developers to as they produce the product. The degree of independence and parallelism needed in Construction simply cannot be achieved if the architecture is not stable.

The importance of a stable architecture cannot be overstated. Do not be deceived into thinking that 'pretty close is good enough' - unstable is unstable, and it is better to get the architecture right and delay the onset of Construction rather than proceed. The coordination problems involved in trying to repair the architecture while developers are trying to build upon its foundation will easily erase any apparent benefits of accelerating the schedule. Changes to architecture during Construction have broad impact: they tend to be expensive, disruptive and demoralizing.

The real difficulty of assessing architectural stability is that "you don't   know what you don't know"; stability is measured relative to expected change.   As a result, stability is essentially a subjective measure. We can, however, base this subjectivity on more than just conjecture. The architecture itself is developed by considering 'architecturally significant' scenarios - sub-sets of use cases which represent the most technologically challenging behavior the system must support.   Assessing the stability of the architecture involves ensuring that the architecture has broad coverage, to ensure that there will be no 'surprises' in the architecture going forward.

Past experience with the architecture can also be a good indicator: if the rate of change in the architecture is low, and remains low as new scenarios are covered, there is good reason to believe that the architecture is stabilizing. Conversely, if each new scenario causes changes in the architecture, it is still evolving and baselining is not yet warranted.

The Initial Operational Capability Milestone

The evaluation criteria for the construction phase involve the answers to these questions:

• Is this product release stable and mature enough to be deployed in the user community?
• Are all the stakeholders ready for the transition into the user community?
• Are actual resource expenditures versus planned still acceptable?

Transition may have to be postponed by one release if the project fails to reach this milestone.

At the Initial Operational Capability Milestone, the product is ready to be handed over to the Transition Team. All functionality has been developed and all alpha testing (if any) has been completed. In addition to the software, a user manual has been developed, and there is a description of the current release.

Following this milestone, the software is released for beta testing. The training of users begins, and production roll-out is planned.

The Product Release Milestone

The primary evaluation criteria for the transition phase involve the answers to these questions:

• Is the user satisfied?
• Are actual resources expenditures versus planned expenditures acceptable?

At the Product Release Milestone, the product is in production and the post-release maintenance cycle begins. This may involve starting a new cycle, or some additional maintenance release.

Determine  the Number and Length of Iterations Within Phases

Once the length of the project phases are determined, the number of iterations and their length need to be determined. For more information on how to define the length of iterations and the number of iterations, see Guidelines: Project Plan. There are a number of iteration patterns that can be applied, depending on the type of project, problem domain and novelty of the problem domain (see also Concepts: Alternate Lifecycle Patterns).

Each iteration produces a deliverable, a release which is an executable product that is used to assess progress and quality. Because each iteration has a different focus, the functionality and completeness of the iteration deliverable will vary. Iteration goals must be specific enough to assess, at the end of the iteration, whether the iteration goals have been met. In early iterations, goals are usually expressed in terms of risks mitigated; in later iterations goals are expressed in measures of functional completion and quality.

Refine Milestone Dates and Scope

Towards the end of the inception phase, phases can be planned more accurately by taking into account the:

• Number of use cases identified.
• Complexity of the use cases already studied.
• Risks identified, both technical and business.
• Function-point, or use-case metrics.
• Result of any prototyping.

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

Define measurement plan

Define measurement plan is done once per development cycle, in the inception phase, as part of the general planning activity. The measurement plan may be revisited like any other section of the software development plan during the course of the project.

This work consist of the following:

• Define the primary management goals
• Validate the goals
• Define the subgoals
• Identify the metrics required to satisfy the subgoals
• Identify the primitive metrics that need to be collected to compute the metrics
• Write and review a measurement plan
• Put in place the collection mechanisms

See Guidelines: Metrics.