CHECKPOINTS OF THE PROCESS

Three sequences of project checkpoints are used to synchronize stakeholder expectations throughout the lifecycle:

1)Major milestones,

2)Minor milestones, and

3)Status assessments.

The most important major milestone is usually the event that transitions the project from the elaboration phase into the construction phase.

The format and content of minor milestones are highly dependent on the project and the organizational culture.

Periodic status assessments are crucial for focusing continuous attention on the evolving health of the project and its dynamic priorities.

The purpose of these milestones is not only to demonstrate how well a project is performing but also to achieve the following:

Synchronize stakeholder expectations and achieve concurrence on three evolving perspectives: the requirements, the design, and the plan.

Synchronize related artifacts into a consistent and balanced state.

Identify the important risks, issues, and out-of-tolerance conditions.

Perform a global assessment for the whole lifecycle, not just the current situation of an individual perspective or intermediate product.

Milestones must have well-defined expectations and provide tangible results.

Three types of joint management reviews are conducted throughout the process:

Major Milestones: these system-wide events are held at the end of each development phase. They provide visibility to system-wide issues, synchronize the management and engineering perspectives, and verify that the aims of the phase have been achieved.

Minor Milestones: these iteration-focused events are conducted to review the content of an iteration in detail and to authorize continued work.

Status Assessments: these periodic events provide management with frequent and regular insight into the progress being made.

Each of the four phases consists of one or more iterations and concludes with a major milestone when planned technical capability is produced in demonstrable form.

Major milestones at the end of each phase use formal, stakeholder-approved evaluation criteria and release descriptions;

Minor milestones use informal, development team controlled versions of these artifacts.

MAJOR MILESTONES

In an iterative model, the major milestones are used to achieve concurrence among all stakeholders on the current state of the project.

Different stakeholders have very different concerns:

Customers: schedule and budget estimates, feasibility, risk assessment, requirements understanding progress, product line compatibility.

Users: consistency with requirements and usage scenarios, potential for accommodating growth, quality attributes.

Architects and system engineers: product line compatibility, requirements changes, trade-off analyses, completeness and consistency, balance among risk, quality, and usability.

Developers: Sufficiency of requirements detail and usage scenario descriptions, frameworks for component selection or development, resolution of development risk, product line compatibility, sufficiency of the development environment.

Maintainers: Sufficiency of product and documentation artifacts, understandability, interoperability with existing systems, sufficiency of maintenance environment.

Others: Possibly many other perspectives by stakeholders such as regulatory agencies, independent verification and validation contractors, and sales and marketing teams.

The essence of each major milestone is to ensure that the requirements understanding, the life-cycle plans, and the product’s form, function, and quality are evolving in balanced levels of detail, and to ensure consistency among the various artifacts.

The general status of plans, requirements, and products across the major milestones

Milestones Plans Understanding of problem space (Req.)

Understanding of solution space (product.)

Life-cycle objectives

Definition of stake holder responsibilities, low-fidelity life-cycle plan, high-fidelity elaboration phase plan

Baseline vision, including growth vectors, quality attributes, and priorities, use case model

Demonstration of at least one feasible architecture. Make/buy/ reuse trade-offs, initial design model.

Milestones Plans Understanding of problem space (Req.)

Understanding of solution space (product.)

Life-cycle architecture

High-fidelity construction phase plan (bill of materials, labor allocation), low-fidelity transition phase plan

Stable vision and use case model, evaluation criteria for construction releases, initial operational capability, draft user manual.

Stable design set, make/buy/reuse decisions, critical component prototypes

Initial operational capability

High-fidelity transition phase plan

Acceptance criteria for product release, releasable user manual

Stable implementation set, critical features and core capabilities, objective insight into product qualities

Product release Next-generation product plan

Final user manual Stable deployment set, full features, complaint quality

Lifecycle Objectives Milestone

At the end of the inception phase is the first major project milestone or Lifecycle Objectives Milestone. At this point, you examine the lifecycle objectives of the project, and decide either to proceed with the project or to cancel it.

Evaluation Criteria

Stakeholder concurrence on scope definition and cost/schedule estimates

Agreement that the right set of requirements have been captured and that there is a shared understanding of these requirements.

Agreement that the cost/schedule estimates, priorities, risks, and development process are appropriate.

All risks have been identified and a mitigation strategy exists for each.

Lifecycle Architecture Milestone

Milestone: Lifecycle Architecture At the end of the elaboration phase is the second

important project milestone, the Lifecycle Architecture Milestone.

At this point, you examine the detailed system objectives and scope, the choice of architecture, and the resolution of the major risks.

Evaluation Criteria

The product Vision and requirements are stable. The architecture is stable. The key approaches to be used in test and

evaluation are proven. Test and evaluation of executable prototypes have

demonstrated that the major risk elements have been addressed and have been credibly resolved.

The iteration plans for the construction phase are of sufficient detail and fidelity to allow the work to proceed.

The iteration plans for the construction phase are supported by credible estimates.

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.

Actual resource expenditure versus planned expenditure is acceptable.

Artifacts

Prototypes.Risk List Development Process Development Infrastructure Software Architecture Document

Initial Operational Capability 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.

Evaluation Criteria

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?

Artifacts

"The System" The executable system itself, ready to begin "beta" testing.

Deployment Plan. Implementation Model (and all constituent

artifacts, including Components) Test Model Training Materials

MINOR MILESTONES (2 per iteration)

The number of iteration-specific, informal milestones needed depends on the content and length of the iteration.

Iteration readiness review: this informal milestone is conducted at the start of each iteration to review the detailed iteration plan and the evaluation criteria that have been allocated to this iteration.

Iteration Assessment Review: this informal milestone is conducted at the end of each iteration to assess the degree to which the iteration achieved its objectives and satisfied its evaluation criteria, to review iteration results, to review qualification test results, to determine the amount of rework to be done, and to review the impact of the iteration results on the plan for subsequent iterations.

PERIODIC STATUS ASSESSMENTS

Objective: To ensure that the expectations of all stakeholders are synchronized and consistent.

Status assessments provide the following:

I.A mechanism for openly addressing, communicating, and resolving management issues, technical issues, and project risks.

II.Objective data derived directly from on-going activities and evolving product configurations.

III.A mechanism for disseminating process, progress, quality trends, practices, and experience information to and from all stakeholders in an open forum.

Periodic status assessments are crucial for focusing continuous attention on the evolving health of the project and its dynamic priorities.

They force the software project manager to collect and review the data periodically, force outside peer review, and encouragement dissemination of best practices to and from other stakeholders.

By standardizing the format and the metrics that are reviewed, an organization can also enable project-to-project comparisons and dissemination of best practices far more efficiently.