8
Common Technical Leading Indicators
A recommended set of common Technical Leading Indicators (TLI) are described in this section. The
common Programmatic Leading Indicators (PLI) are described in Section 4.0. Each section discusses
applicable trend categories, explaining why trends in each category are important and describes the
specific trend measurements that need to be monitored. Each measurement is described, and sample
plots shown. Note that these are only examples. These indicators may be portrayed by the project in the
format that is most useful to the project. The complete set of Common Technical Leading Indicators is
presented in Appendix C along with the minimum characteristics for the displays. As long as the minimum
set of plotting characteristics is satisfied, how the project chooses to depict the trend is left up to the
project and its decision authorities.
3.1. Requirement Trends
This category includes three trends that should be monitored to assess the stability and maturity of the
products: Percent Requirement Growth, To be Determined/To Be Resolved (TBD/TBR) Closures, and the
Number of Pending Requirement Changes. Each is separately discussed in the following sections.
3.1.1. Why Are the Leading Indicators Important?
Controlling the growth of requirements is one of the best ways to reduce unplanned cost and schedule
delays later in a project life cycle. For each new requirement that is added, dozens more may be derived as
the project moves deeper into the product hierarchy. Each of these new and derived requirements will
then need to be verified, again potentially adding more cost and schedule time. Therefore, creating or
defining new requirements must be performed with care. Ensure that each requirement is truly “required”
and not just a desire or wishful thinking. Requirements should convey only those things that absolutely
must happen to produce a product that will accomplish the desired outcome. They should not dictate a
single solution nor strangle the creativity of the designer. The requirement set should allow for multiple
design options that can then be traded against key parameters such as performance, cost, and schedule.
Depending upon where the project is in the life cycle, requirement growth is not necessarily a bad thing.
During Phase A, the project moves from having no requirements to the formal definition of the
requirements culminating with the System Requirement Review (SRR). So naturally, there should be a
drastic increase in requirements. Also within phase A is the System Definition Review (SDR) at which the
architectures are presented. It is also expected that there may be additional requirements defined during
this part of the life-cycle phase.
As the project moves to Phase B and the Preliminary Design Review (PDR), the requirement growth or
velocity should be significantly slowed but realistically may see some small growth as the designs are
prototyped, gaps in the requirement set are found, unforeseen need for a requirement is identified, etc. As
the project moves into Phase C and the Critical Design Review (CDR) and the product design is finalized,
requirement growth should be very small. The later requirements are added to a project, the more difficult
they may be to enact and the more cost and schedule they may be adding. As the project completes Phase