Define 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. As a project progresses,
the project manager will monitor these indicators and instigate corrective actions when they exceed
pre-defined trigger conditions (see Define procedure & thresholds for corrective action).
These project indicators may include the following:
-
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 definition of these indicators is driven by the project's budget, quality objectives and schedule
(detailed in the Software Development Plan) and is captured in the project's Measurement Plan and Risk
Management Plan.
|
Define project indicators - Systems Engineering Note
For application to software development, the budget, schedule, and so forth, are found in the Software Development Plan. In the systems engineering context, the
budget, schedule, and so forth, are found in the System Development Plan. In the following steps, "Development Plan"
refers to the Software Development Plan or the System Development Plan, depending on the level and context for the project. |
Define sources for project indicators
The projector 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.
Section 4.4 Project Monitoring and Control of the Software Development Plan should include a brief
description of the project indicators that will be used on your project. Note that there are separate
sub-sections in this section of the SDP covering control of the project's schedule, budget, and quality.
Control of project requirements is dealt with separately in the Requirements Management Plan.
|
Define Technical Performace Measurement Plan
Technical Performance Measures are a set of key performance or technical attributes selected from the Supplementary
Specifications or Use-Case Model as critical indicators of system effectiveness, that, if not achieved, put the system
development at risk of overrunning cost, schedule, or performance constraints. TPMs are tracked by the Project Manager
against a planned profile, and the breaching of planned thresholds by TPMs signals to the Project Manager that a cost,
schedule, or technical re-plan might be needed. TPMs are thus an adjunct to progress tracking, when simple tracking of
activity completion or functional delivery is inadequate because of technical risk. The technical Performance
Measurement plan captures the critical factors, the planned achievement profile (over time), assessment timing, and
contingency planning. The table shows some examples of TPMs (taken from NASA Systems Engineering Handbook SP-610S,
June 1995):
Examples of High-Level TPMs for Planetary Spacecraft and Launch Vehicles
High-level Technical Performance Measures (TPMs) for planetary spacecraft include:
-
End-of-mission (EOM:) dry mass
-
Injected mass (includes EOM dry mass, baseline mission plus reserve propellant, other
consumables, and upper stage adaptor mass)
-
Consumables at EOM
-
Power demand (relative to supply)
-
Onboard data processing memory demand
-
Onboard data processing throughput time
-
Onboard data bus capacity
-
Total pointing error
Mass and power demands by spacecraft subsystems and science instruments might be tracked separately
as well. For launch vehicles, high-level TPMs include:
-
Total vehicle mass at launch
-
Payload mass (at nominal altitude or orbit)
-
Payload volume
-
Injection accuracy
-
Launch reliability
-
In-flight reliability
-
For reusable vehicles, percent of value recovered; for expendable vehicles, unit production
cost at the nth unit
|
Examples of TPMs.
|
Define procedure for team status reporting
Once the primitive metrics and project indicators have been defined, you should define the procedure and
reporting frequency for project team members to report their status. This procedure should describe the
process for booking time against activities, reporting the completion of tasks, achievement of project
milestones and reporting of issues. To ensure a consistent flow if information, it is typical for standard
templates to be defined for timesheets and team member status reports.
This procedure is documented in Section 4.4.5 Reporting Plan of the Software Development Plan.
|
Define procedure thresholds for corrective action
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 (by issuing appropriate work orders). 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.
|
Define procedure for project status reporting
Section 4.4.5 Reporting Plan of the Software Development Plan should also describe the frequency and
procedure for the project manager to report project progress to the Project Review Authority (by issuing a
Status Assessment). This procedure describes when and where scheduled and un-scheduled PRA Reviews will
occur, and what information is to be included in the Status Assessment. The project manager will use the
Issues List for continuous recording and tracking of problems (that are not the subject of some other
management control instrument, such as the Change Request or the Risk List) in the periods between the
production of Status Assessments.
|
|