Activity:  Develop Measurement Plan

The Measurement Plan describes the goals which the project must track towards for successful completion and the measures and metrics to be used to determine whether the project is on track.

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

Define the Primary Management Goals

The Project Manager should decide which of the project's requirements and constraints are important enough to require an objective monitoring program. Additionally, organizational requirements may be imposed that are related to business needs (cost reduction, time-to-market and productivity improvements), not directly to project needs. Typically, a project manager will want to track the growth in capability and reliability of the software under construction, as well as expenditures (effort, schedule, other resources), and there may be performance and other quality requirements, as well as memory and processor constraints. See Guidelines: Metrics for more details. The sources of information for selection of goals include the Vision, Risk List and Business Case, as well as organizational requirements and constraints not specified in the Rational Unified Process.

Validate the Goals

The Project Manager should review the selected goals with relevant stakeholders to ensure that the focus of the goals selected is correct, that there is adequate coverage of all areas of interest and risk, that it is possible to reduce the goals to collectible metrics and that adequate resources can be committed to the measurement program.

Define the Subgoals

It may be difficult or impossible to formulate direct measures for some high-level or complex goals. Instead it is necessary to decompose such a goal into simpler subgoals, which together will contribute to the achievement of the high-level goal. For example, project costs will not usually be tracked simply through a single overall cost figure, but through some Work Breakdown Structure, with budget allocated to lower levels and cost information collected at this lower level of granularity. The depth of decomposition should be limited to a maximum of two levels of breakdown below the primary or high-level goal. This is to limit the amount of data collection and reduction needed, and because it may become very difficult in deep hierarchies to be sure that tracking the subgoals is really contributing to understanding progress against the high-level goal.

Identify the Metrics Required to Satisfy the Subgoals

The task here is to associate the subgoals with some entity or artifact with measurable properties or attributes. Metrics that are objective and easily quantified are to be preferred.

Identify Project Indicators

Project "indicators" are pieces of project information that give a picture of the health of the project's progress against the software development plan. Typically a project manager will be concerned with indicators that apply to the project's scope of work, budget, quality, and risks. The project manager should associate the project indicators with the goals they help to achieve. As a project progresses, the project manager will monitor these indicators and instigate corrective actions when they exceed pre-defined trigger conditions.

These project indicators may include:

• Total spending vs. budget
• Revised scope (work done + estimates to complete) vs. planned scope
• Defect density vs. quality objectives
• Risk indicators (situations that tell you a risk is being realized)

The Project Manager should also define the sources of information for the project indicators. These indicators, in most cases, will be consolidated project measures calculated from more granular primitive metrics that are reported by the project team on a regular basis. How these primitive metrics are to be captured, and the process for using them to calculate the project indicators is defined in the project's Measurement Plan. Other indicators (especially risk indicators) may be simply the status of whether a particular situation has occurred or not. For these cases, the source of the information on the indicator status is all that needs to be identified.

In order to maintain effective control of the project, the project manager defines threshold (or trigger) values/conditions for each of the defined project indicators. These threshold conditions are recorded in the appropriate sections of Section 4.4 Project Monitoring and Control of the Software Development Plan. When these thresholds are exceeded, the project manager must take corrective action in order to bring the project back on track. Depending on the severity of the condition, the project manager may be able to resolve the situation within his authority. If the situation goes beyond the project manager's authority he will need to issue a Change Request and activate the project's change control process.

Identify the Primitive Metrics Needed to Compute the Metrics

In this step, the elementary data items, from which the metrics will be derived, are identified. These are the items that will need to be collected.

Write the Measurement Plan

The Measurement Plan captures the goals, subgoals and the associated metrics and primitive metrics. It will also identify the resources (e.g. Project Measurements) and responsibilities for the metrics program.

Evaluate the Measurement Plan

The Project Manager should have the Measurement Plan reviewed by:

• those directly engaged in the metrics program (in the default organization, the Assessment Team, see Guidelines: Project Plan, Project Organization
• the Project Review Authority (PRA)
• a metrics expert external to the project, unless there are individuals in the Assessment Team who are considered experts.

Put in Place the Collection Mechanisms

The instructions, procedures, tools and repositories for metrics collection, computation, display and reporting have to be acquired or produced, installed and set-to-work according to the Measurement Plan. This will include the Project Measurements artifact.

See Guidelines: Metrics.

Copyright  © 1987 - 2001 Rational Software Corporation

Rational Unified Process