<<

. 2
( 9)



>>

2f The Speci¬cation is being properly performed.

The Speci¬cation is being properly performed when the Design Reviews or
Milestone Reviews are properly passed and accepted by the customer and the
product is fabricated or produced in accordance with the design and accepted
by the customer.
You can only answer YES to this assertion if you answered YES to assertions
2a, 2b, 2c, 2d, and 2e. If you answered NO to any of those assertions, you must
rectify the situation before proceeding.
Ensure that every major milestone, such as the Preliminary Design Review
(PDR) has inch stones leading up to it. Performance must be evaluated at every
inch stone. Evaluate performance using the requirements of the major mile-
CHECKING PROGRAMMATIC PERFORMANCE 23


stone and develop a ˜˜percent complete™™ chart for each inch stone and for the
milestone.

3 POLICIES, PLANS, AND PROCESSES

3a There is a clear trail between standard policies and plans
and the Project/Program Plan and Technical Plan.

The Project/Program and Technical Plans link to standard policies and plans
through two avenues. One avenue is through enterprise policies and processes;
the other is through the requirements document (contract). The requirements
document (contract) references those standards through the Statement Of Work
(SOW) and the Speci¬cation.
You should have a Standards Traceability Matrix (STM) similar to Table
2-8.

Ta b l e 2 - 8 ” S t a n d a r d s Tr a c e a b i l i t y M a t r i x ( S T M )
Y
FL
STANDARDS APPEARANCE
Industry Customer Enterprise Project Plan Technical Plan
AM


ISO-9001 ISO-9001 Enterprise Quality Para 4.6.8 Part I, Para
Policy 09350 4.5.6
MIL-STD-100 Enterprise Engineering N/A Part II, Para
Standards 06050 1.2.3
TE




The STM shown here is a multipurpose table in that the requirement source
such as the contract paragraph, the company standard, and the standards docu-
ments are all included in one chart. You can use this technique to divide the
three requirements into three separate charts. The STM is further explained in
Attachment 13.

3b There is a clear trail between customer policies and plans
and the Project/Program Plan and Technical Plan.

Customer policies and plans are linked to the Project/Program Plan through
the requirements document (contract). The Statement Of Work (SOW) and the
Speci¬cation should clearly spell out those customer policies, processes, and
plans that are invoked as a part of the contract.
BLUEPRINT FOR PROJECT RECOVERY
24


You should have an STM similar to Table 2-9.

Ta b l e 2 - 9 ” S t a n d a r d s Tr a c e a b i l i t y M a t r i x ( S T M )

STANDARDS APPEARANCE
Industry Customer Enterprise Project Plan Technical Plan
ISO-9001 ISO-9001 Enterprise Quality Para 4.6.8 Part I, Para
Policy 09350 4.5.6
MIL-STD-100 Enterprise Engineering N/A Part II, Para
Standards 06050 1.2.3




The STM shown here is a multipurpose table in that the requirement source
such as the contract paragraph, the company standard, and the standards docu-
ments are all included in one chart. You can use this technique or separate the
three requirements into three separate charts. The STM is further explained in
Attachment 13.

3c There is a clear trail between enterprise policies and plans
and the Project/Program Plan and Technical Plan.

A clear trail between enterprise policies and plans and the Project/Program
Plan and Technical Plan exists when the Vision drives the Mission Statement,
which, in turn, drives the Policies. The Policies are the foundation that sets
standards for the Processes and Plans. The Project Plan and Technical Plan are
a fundamental part of all the plans and should re¬‚ect the parts, sections, chap-
ters, and paragraph upon which they are based.
The documentation of a corporation, company, or enterprise is near the top
of the management ˜˜to do™™ list on how to run a company. The only things at
higher rungs are the Strategic Plan, the Mission Statement, and the Vision. If
the entity is ongoing and the documentation is at fault, it is not a good sign. If
the documentation does not exist, it™s even worse. If it is a new start, the entity
should look upon the situation as a learning experience and ¬x the documenta-
tion. If the project documentation is lacking and the enterprise documentation
is in order, it is an indication that there is a disconnect between the enterprise
and the programs it runs. This can be overcome by using an ˜˜Executive Sum-
mary™™ that is agreed to by enterprise management and program management
before the program is kicked off. The continuity is maintained by a Project
CHECKING PROGRAMMATIC PERFORMANCE 25


Advisory Council, a group of senior executives assigned to follow and advise
each project.
You should have an STM similar to Table 2-10.

Ta b l e 2 - 1 0 ” S t a n d a r d s Tr a c e a b i l i t y M a t r i x

STANDARDS APPEARANCE
Industry Customer Enterprise Project Plan Technical Plan
ISO-9001 ISO-9001 Enterprise Quality Para 4.6.8 Part I, Para
Policy 09350 4.5.6
MIL-STD-100 Enterprise Engineering N/A Part II, Para
Standards 06050 1.2.3




The Standards Traceability Matrix shown here is a multipurpose table in that
the requirement source such as the contract paragraph, the company standard,
and the standards documents are all included in one chart. You can use this
technique or separate the three requirements into three separate charts. The
STM is further explained in Attachment 13.

4 ORGANIZATION

4a The numbers of personnel assigned to each task are correct.

When you ¬rst start your project, the organization chart and staf¬ng table
from the proposal will probably be your guides. As the project progresses, per-
formance will be the rule. You must constantly ask yourself: ˜˜Is the job getting
done?™™ Then, follow up with these questions: ˜˜Is the job getting done without
working overtime?™™ ˜˜Is the morale of the team high?™™ If the answer to all those
questions is YES, you™re probably in good shape. You must however also ask
yourself: ˜˜Do I have too many people?™™ The job could be getting done, you are
not working overtime, and morale is high but you have too many people. Yes,
that actually does happen on projects! Optimizing manpower is a constant task.
If your project is a large one that will last over a period of time, it is possible
that the organization chart and manpower table will change. It is normal to
have one organization and manpower table for design and another for test,
production, and so forth. That™s another reason you must ask yourself the open-
ing question frequently.
BLUEPRINT FOR PROJECT RECOVERY
26


4b The mix of personnel to accomplish the task is appropriate.

The mix of personnel to accomplish the task is appropriate if the job is
getting done and the mix of personnel matches the mix shown on the organiza-
tion chart and the staf¬ng plan.
Mix, of course, means the different types of persons assigned, not just the
numbers. The starting point is usually the proposal or the document that was
the basis for providing the correct technical manpower and for costing the man-
power for the project. The correct mix is absolutely essential. It is the basis for
correctly accomplishing the task technically and for maintaining the budget.
It is important to keep the organization chart and the staf¬ng plan up-to-
date. Keep all staf¬ng plans from the proposal on to show the transitions of
personnel from time to time in the project. This will help when accounting for
personnel changes and will provide an operational history for the next bid.

4c The personnel are acting and reacting as a team.

Just because a group of individuals are assigned to a project does not mean
they are a team. In order to be a team, the individuals must act and react with
regard to the team™s goals. The group acts and reacts as a team when the re-
sponses to team goals are greater than the responses to individual goals.
While actions and reactions are the most important factor, there are other
considerations that will help the group to continue to act as a team. First, and
most important, is to have had team training using a facilitator quali¬ed to
conduct team training and an acceptable team training format. Second, which
is usually a result of team training, is that the team has a Vision (see glossary)
and a Mission Statement (see glossary).

5 TEAMING, ALLIANCES, AND SUBCONTRACTS

5a The subcontracts were properly de¬ned.

The tasks of subcontractors, which include Teaming (see glossary) and Alli-
ances (see glossary), are properly de¬ned if there is a clear trail between the
customer™s requirement documents (SOW and Speci¬cation) to the subcontrac-
tor™s requirements document (subcontract SOW and subcontract Speci¬cation)
using a Requirements Flow-down Matrix (RFM) and from the subcontractor™s
CHECKING PROGRAMMATIC PERFORMANCE 27


requirements documents through the subcontractor™s process using a Subcon-
tract Requirements Traceability Matrix (SRTM).
An RFM with the characteristics shown in Table 2-11 should be used.
Additional information can be found in Attachment 8.
Additionally, the subcontractor should have an SRTM, such as that shown
in Table 2-12.
The current industry standard is a family of products titled DOORS (for
large and enterprise wide projects) and DOORSrequireIT (for smaller projects).


Ta b l e 2 - 1 1 ” R e q u i r e m e n t s F l o w - D o w n M a t r i x ( R F M )

Company Design S/C Plan S/C A S/C B
Spec Para Reqt WBS Plan Para Para Para Para
1.3.2 02-03-01 5.3.2 5.3.2 1.3.2 1.3.2
1.3.3 02-03-02 5.3.3 5.3.3 1.3.3 N/A
1.3.4 02-03-03 5.3.4 5.3.4 1.3.4 1.3.4
QA Plan 04-01-01 8.2.6 8.2.6 4.3.6 4.3.6
CM Plan 05-01-01 9.3.1 9.3.1 5.6.2 5.6.2




Ta b l e 2 - 1 2 ” S u b c o n t r a c t s R e q u i r e m e n t s
Tr a c e a b i l i t y M a t r i x ( S R T M )

Unit System
SOW/ WBS S/C SOW/ Test Test
Spec Para Requirement Number Spec Para Number Para Monitor
SOW
4.3.1 Security 06-03-02 N/A T-0304 4.4.1 Smith


Spec
3.2.1 System weight 02-04-03 3.4.6 T-0045 3.4.1 Jones
shall be less
than 10,000
pounds
BLUEPRINT FOR PROJECT RECOVERY
28


Both are commonly referred to as ˜˜Doors.™™ Additional information on Doors
can be found in Attachment 7.

5b The subcontract tasks are within the capabilities of each
team member, partner, or subcontractor.
The subcontract tasks are within the capabilities of each team member, part-
ner, or subcontractor if each has performed the same or a similar task before
and no substantial changes have since occurred (i.e., critical personnel are still
in place, and critical facilities are still available) or the subcontractor has some
unique capability or capacity to perform the task. Such data should be main-
tained by the enterprise as a part of the Vendor/Subcontractor Database. If your
enterprise does not keep such a database, a ˜˜quick ¬x,™™ can be reached by
constructing a matrix with the tasks along the side and a place for program
entries across the top. The potential subcontractor then identi¬es the program
where the same or a similar task has been performed.
If anything has changed (i.e., critical personnel are no longer available, criti-
cal facilities are not available, etc.) you should go to Chapter 4, Cause Descrip-
tion 5b (NO), Recovery section. If the subcontractor has a unique capability or
capacity to perform that has not been tried before, this is the time to create a
Risk Mitigation Plan (see Attachment 3).
As project manager, it is a good idea (in my opinion absolutely necessary)
that you have written con¬rmation of this fact. Do not simply accept the state-
ments of Marketing (who usually makes Teaming Agreements) or Management
(who usually makes Alliances) that the company with whom you are aligned is
quali¬ed to perform the task. Teaming Agreements and Alliances are frequently
made for political purposes. If you ¬nd such a situation exists, refer to Chapter
4, Cause Description 5b (NO) for recovery.

5c The subcontracts were properly negotiated.
The subcontracts were properly negotiated if they are fully understood by
both parties and contain a balance between all the elements, and if:

’ The amount of money to be paid is adequate to complete the task.
’ The time allowed is adequate to complete the task.
’ Both you and the subcontractor understand what is to be done and when.

It is the responsibility of the requirements de¬nition (negotiation) team to
ensure that this balance exists and that minutes are documented and signed.
CHECKING PROGRAMMATIC PERFORMANCE 29


One of the best ways to ensure balance is to require that the project manager
be on the requirements de¬nition (negotiation) team. The project manager will
ensure there is a balance or will suffer the consequences.

5d The subcontracts are properly monitored.

The subcontract is properly monitored when the work being performed is
being monitored by lead technical and project personnel using accepted moni-
toring techniques such as:

’ Subcontract Progress Reviews”Subcontractor presents technical prog-
ress, budget status, schedule status, deliverables status, and data status
’ Subcontractor Meetings”Special, single subject meetings as required
’ Technical Interchange Meetings (TIMs)”Informal reviews of technical
subjects
’ Design Reviews”Formal reviews of designs. Subcontractor presents and
defends the design and its support
’ In-Process Reviews”Usually, informal reviews between milestones
’ Pretest Meetings”Brie¬ngs to establish the basis for a test
’ Posttest Reviews”Review of test data and issuance and formalization of
action items and, if appropriate, sign-off

These reviews must be conducted at frequent and consistent intervals. The
lower in the hierarchy (e.g., the project is lower in the hierarchy than company,
etc.), the more frequent the review.
Simply conducting these meetings and reviews does not mean the subcon-
tract is performing properly; it only means that the subcontract is being moni-
tored properly. But, if the subcontract is not being monitored properly, you will
not know if it is performing properly.
Within each of these must be monitoring points or metrics that indicate that
an event is in tolerance or out-of-tolerance.

5e Team members, partners, and subcontractors are
performing properly.

Team members, partners, and subcontractors are performing properly when
all monitored events are being performed on schedule, within budget, and in a
BLUEPRINT FOR PROJECT RECOVERY
30


technically competent way. The method you use in determining this status is to
conduct regular and frequent reviews at strategic points in the process to ensure
that performance is proper. Such reviews are presented in detail in Cause De-
scription 5d.
Monitored events are those events that are typical for a particular review.
Usually, Schedule Reviews, Budget Reviews and Progress Reviews are held con-
currently. Within each review there must be monitoring values and metrics to
determine if the project is performing in tolerance. While projects vary in¬nitely
in subject matter there are some values that must be monitored on all projects.
Such meetings are frequently called Plans, Progress, and Problems Meetings.
Such values and metrics are, at a minimum:


’ Actual cost to date versus planned cost to date
’ Actual performance to date versus planned performance to date
’ Cost at completion
’ Completion date
’ Performed activities versus planned activities for last period
’ Problems and recommended resolution
’ Planned activities for next period

6 MATERIALS

6a Purchase Orders were properly written.

Each Purchase Order is complete and properly written when it contains:
Reference Number, Order Date, Vendor, Contact Information, Name of Item,
Stock (Catalog) Number, Number of Units, Price, Delivery Schedule, Delivery
Location, Purchaser, and Authorizing Signature.
It is bene¬cial that the information contained in the Purchase Order be com-
plete and properly written for a few reasons. For example, it conveys to the
vendor exactly what is expected. Also, you must know exactly the status of each
Purchase Order because of the impact it has on your schedule and your budget.
Most companies have preprinted Purchase Order forms. If yours does not,
create your own. Even if your Purchase Order form is nothing more than a
memo, at least it is documentation of what has been ordered and provides a
basis for the schedule and for ¬nancial accountability. If your preprinted form
CHECKING PROGRAMMATIC PERFORMANCE 31


does not contain all the information above, I suggest you add the information
within the body of the Purchase Order.

6b All vendors are competent to perform their tasks.
All vendors are competent to perform their tasks if they have passed the
criteria set forth in your enterprise standards. If you do not have enterprise
standards, the following should be established as the criteria:

’ Technical Performance
’ Cost Performance
’ Delivery Performance
’ Management Performance
’ Procurement Policies and Plans
’ Quality Assurance Program (see Attachment 6 for Quality Assurance
Plan)
’ Cost of Quality Position (see glossary)

Figure 2-1 on the following page provides a framework for collecting this
data.

6c Purchase Orders are properly monitored.
The Purchase Order is properly monitored when the work being performed
is being monitored by the Materials Manager calling upon technical and pro-
gram personnel as required and using accepted monitoring techniques such as:

’ Vendor Progress Reports
’ Vendor Meetings
’ In-Process Reviews

The above include schedule and budget, if proper.
These reviews must be conducted at regular, frequent, and strategic intervals.
Simply conducting these meetings and reviews does not mean the vendor is
performing properly; it only means that the Purchase Order is being monitored
properly. But, if the Purchase Order is not being monitored properly, you will
not know if the vendor is performing properly.
BLUEPRINT FOR PROJECT RECOVERY
32


Figure 2-1 ” Vendor Evaluation Sheet

VENDOR EVALUATION

4-Jul-02
Date

High-Flyer
Program

National Software
Subcontractor/Vendor

Analog Selction Algorithm
Equipment/Software

G. Smith
Evaluator

0-5
Scale Factor


Item Consideration Rating*


1 Organization 3
2 Management 4
3 Manpower 5
4 Access to Management 5
5 Processes 3
6 Procedures 2
7
8
9
10
Subtotal** 22
No. of items rated** 6
Average of ratings (Subtotal/No of items)** 3.7
*An evaluated number within the Scale Factor.
**Calculated number.


M-M Form
CHECKING PROGRAMMATIC PERFORMANCE 33


Within each of these reviews there must be monitoring points or metrics
that indicate that an event is in tolerance or out-of-tolerance.
If schedule is critical, the Purchase Order should include an incentive or
liquidated damages clause that is invoked in the event the delivery time is not
kept.

6d Vendors are performing properly.

Vendors are performing properly when all monitored events are being per-
formed on schedule, within budget, and in a technically competent way. The
method you use in determining this status is to conduct regular and frequent
reviews at strategic points in the process to ensure that performance is proper.
Such monitored events typically are:


’ Vendor Meetings, including Schedule Reviews and Budget Reviews1
’ Technical Interchange Meetings2
Y
’ In-Process Reviews
FL

7 PERSONNEL
AM


7a Each person is competent to perform the tasks assigned.
TE




It should be apparent whether or not each person is competent to perform
the tasks to which he or she is assigned. It is not usual to have job descriptions
for project positions, so the personnel must learn what is expected of them in
other ways. The best way is through team training, where each individual is
apprised of the expectations of his position and the input the individual needs
from others.
Knowing what is expected is one thing. Competency is quite another. The
best way to establish competency is to interview each person before assigning
individuals to the project. In a small company, you can usually rely on reputa-
tion and personal contact. In a large company, you may need to interview the
´ ´
individuals and read their background resumes. When the project is running,
you judge competency by your observation, by MBWA (Management By Walk-
ing Around), and by asking questions of other team members.
Competency (a long-term characteristic) is not the same as reaction (a short-
term characteristic). In other words, don™t characterize a person based on a
BLUEPRINT FOR PROJECT RECOVERY
34


single sample of work or on his or her response on one day (the person may be
having a bad day). Conversely, don™t expect the ˜˜leopard to change its spots™™
based on a single day of responses.
Refer to Cause Description 7a (NO) for recovery.

7b Each person is available when needed.

If each person is available when needed, it will be self-evident. As project
manager you will constantly be scanning the personnel and you can tell if any-
one is missing. Watch the wording here carefully. As project manager, you must
control the personnel. If you operate in a matrix organization, you must have
an understanding with the functional manager that, once assigned, the person-
nel report to you. You must be a party to any planned absences.
No matter if you operate in a matrix or a projectized organization, you must
keep up with your people and what they are doing from day to day.

7c Salaries/wages are equal to or less than those bid.

It should be clear by simply looking at the details supporting your budget
that the individual salaries are equal to or less than those that were bid. You
must use your judgment in this case. Use the bottom line of the budget as the
guide”it is easier to achieve the bottom line than to achieve each and every
line item. It may be to your bene¬t to have an individual of higher pay in a
certain position and several of lower pay in other positions. You must make
that judgment.
Take care if your program is longer than a few months and you use the
matrix form of management. You may ¬nd that salaries ¬t the bid pro¬le at the
start of the program but some of your people get raises during the conduct of
the program. People should be rewarded for good work and should have raises
when they are due. Just make sure those raises are built into your budget.

7d Interpersonal con¬‚icts do not exist.

Interpersonal con¬‚icts do not exist when there is mutual respect between the
members of the team.
If you have no interpersonal con¬‚icts at all, one of two things is happening:
You are the luckiest project manager alive, or you are not very close to the
people part of your project. Even if you answered YES to this assertion, it might
CHECKING PROGRAMMATIC PERFORMANCE 35


be a good idea to look at the Recovery association in Chapter 4, Cause Descrip-
tion 7d (NO) just to give the question a little more depth.

8 TRAINING

8a All personnel have been adequately trained.

All personnel have been adequately trained when they know their basic jobs
thoroughly, when they know the mission of the team, when they know the
product(s) to be produced, and when they know what part they play on the
team and in developing the product(s).
It is advantageous to the project and the team and frequently to the individ-
ual that they be cross-trained. If it is not in your plan, it should be”unless it is
against union rules or against some other rule over which you have no control.

8b The training program is economical.

The training program is economical when the dollar cost of the training
program is equal to or less than the value derived from the training program.
Further, in order to be economical, the value imparted to the individuals attend-
ing the training class must be worth the time employed in attending the pro-
gram, for every person in attendance.

9 DATA MANAGEMENT

9a The proper amount of data is being delivered on time.

The proper amount of data is being delivered on time when the data deliver-
ies match the data required in the Data Plan, and the Data Plan matches the
requirements. Some documents are delivered once (i.e., System Test Results),
and some require multiple deliveries (i.e., Monthly Status Reports).
Each line item of deliverable documentation in the requirement should con-
tain a delivery date or schedule of dates, a format, a content requirement, and
the name of the person responsible for generating the data. If it does not, you
should create these requirements. All requirements are then included in the
Data Plan.
Your deliveries may be formalized as they are in a government contract. In
this case, you will have a Contract Data Requirements List (CDRL) that spells
BLUEPRINT FOR PROJECT RECOVERY
36


out what is to be delivered and numerous Data Item Descriptions (DIDs) that
spell out the frequency of submission and the format of the submission.
Your Data Plan should specify in what form the data is to be delivered and
to whom. Many projects have engineering deliver raw or re¬ned reports to the
Data Manager, who adds the boiler plate, coordinates the review, reproduces
the number of copies necessary, and handles distribution. These same tech-
niques, except for reproduction, can be used for electronic transmissions as
well.

10 QUALITY
10a The Quality Plan is thorough, complete, and authorized.
The Quality Plan is thorough, complete, and authorized when it completely
addresses and ¬lls the requirements of the Quality Standards imposed by stan-
dard, customer, or your internal requirements document and it is authorized
by the highest quality of¬cial of the enterprise. (See Attachment 6 for a Quality
Assurance Plan outline complete with explanations and details.)

10b Speci¬c quality characteristics were identi¬ed that are
important to the project.
Speci¬c quality characteristics were identi¬ed that are important to the proj-
ect when these characteristics are documented and used as a checklist.

10c Quality is measured so that improvement or degradation is
clear.
Quality is measured so that improvement or degradation is clear when each
quality characteristic is measured and tracked via metrics.
Quality is measured so that improvement or degradation is clear when each
quality characteristic shows clear improvement or degradation between the cur-
rent reading and some standard or the last reading.

11 FINAL DELIVERY
11a Final delivery was accepted by the customer without delay.
It is expected that ¬nal delivery will be accepted by the customer without
delay because it is one of the most important steps in the closure process. In
order to ensure that this happens, the following must have been completed:
CHECKING PROGRAMMATIC PERFORMANCE 37


’ Design Reviews or milestone reviews signed by customer
’ All In-Process Documentation completed
’ All Deliverable Documentation delivered
’ All In-Process Tests accepted by the customer
’ The ¬nal System Test accepted by the customer
’ Product shipped to the point of delivery and in deliverable condition

11b Third-party or drop shipping is not involved.

Third-party or drop shipping is not involved whenever the product is
shipped directly from your facilities to the customer™s facilities.
If drop shipping is involved, you must have absolute control over shipping
and receiving of the product. See 11b (NO).

Notes

1. Usually not for an FFP contract.

2. Unless the product is a commercially available commodity (i.e., a catalog item).
CHAPTER 3




CHECKING TECHNICAL
PERFORMANCE


3.1 General

Checking technical performance is fundamental to a smooth-running project.
The best time to accomplish this task, of course, is when you are planning the
project; however, you can check your project performance at any time by using
the checklist provided here.

3.2 Technical Performance Checklist

Table 3-1 is the Technical Performance Checklist. Use this table to check the
content of your plans and processes when planning the project or to con¬rm the
Technical Plan when the project is running. The Technical Recovery Checklist is
presented in Chapter 5 of this book.
38




.......................... 9758$$ $CH3 12-09-02 08:29:39 PS
CHECKING TECHNICAL PERFORMANCE 39


Ta b l e 3 - 1 ” Te c h n i c a l P e r f o r m a n c e C h e c k l i s t

51 ARCHITECTURE Explain Yes
51a All Critical Success Factors (CSFs) such as Mean Time To Repair 41
(MTTR), Mean Time Between Failure (MTBF), etc., have been
documented and understood
51b All modules/subsystems are well de¬ned 41
51c All key functions such as time, length, weight, performance 42
requirements, and interfaces, etc., listed in the requirements are
appropriately covered
51d All major elements (physical and data) are described and justi¬ed 42
51e All key aspects of user interfaces are well de¬ned 42
51f The Architecture hangs together conceptually 42
52 DESIGN Explain Yes
52a The design process is correct and traceable to enterprise, customer, 42
and standard processes
52b The design is correct and traceable to the requirements 43
52c The design is ef¬cient 43
52d The design adequately addresses issues that were identi¬ed and 43
deferred to design at the architectural level
52e The design is partitioned into manageable segments 44
52f The design accounts for supportability, Life Cycle Cost (LCC), total 44
cost of ownership, and future expansions
52g Technical Performance Measures (TPMs) such as data retrieval 45
time, weight, error rate, etc., have been de¬ned and accommodated
53 DESIGN REVIEWS Explain Yes
53a All Design Reviews were completed according to required processes 45
53b The customer approved each Design Review 45
54 IN-PROCESS REVIEWS Explain Yes
54a All required In-Process Reviews were conducted according to 45
required processes
54b Each In-Process Review was approved by the appropriate authority 46
55 PROTOTYPES Explain Yes
55a The prototypes re¬‚ect the requirements 46
55b Prototypes were constructed incrementally 47
55c Prototype changes were incorporated into the design using the 47
Change Control Process
55d Each prototype change was reviewed and accepted by the originator 47
of the requirements
(continues)
BLUEPRINT FOR PROJECT RECOVERY
40


Ta b l e 3 - 1 ” ( C o n t i n u e d )

56 SUBCONTRACTS Explain Yes
56a The sum of all subcontracts re¬‚ects all tasks allocated 48
56b Each subcontract contains all tasks allocated 48
57 PURCHASE ORDERS Explain Yes
57a The sum of all Purchase Orders re¬‚ects all purchases to be made 48
57b Each Purchase Order is complete 49
58 PRODUCTION/MANUFACTURING Explain Yes
58a All production/manufacturing processes are traceable to standard, 49
customer, or enterprise processes
58b The line(s) were properly designed and set up for this (these) 50
product(s)
58c Shop orders were correct and thorough 50
58d The materials were proper for the processes and the product(s) and 50
do meet the requirements
59 UNIT TEST Explain Yes
59a Each Unit Test correctly re¬‚ects the requirement 51
59b Each design element that applies to the routine/module/subsystem 51
has its own test case
59c Unit Test ¬ndings were reviewed for completeness and forwarded 51
to be incorporated into Subsystem Tests and the System Test
59d All Problem Test Reports (PTRs) were captured, dispositioned 52
(allocated for action), and worked off
60 SYSTEM TEST Explain Yes
60a The System Test Plan/Procedure was approved by the customer 52
60b The System Test is traceable to the requirements 52
60c The System Test tested all elements of the system concurrently 52
60d The System Test was performed under appropriate load(s) 53
60e The System Test was performed using the same kind of personnel 53
that will be used by the customer
60f The System Test was properly documented and incorporated the 53
test results of all prior-level tests
61 CONFIGURATION MANAGEMENT Explain Yes
61a The Con¬guration Management Plan (CMP) is thorough, 53
complete, and authorized
61b Change requests were presented and approved by an appropriate 54
level of the Review Board
61c Version controls are in place and are re¬‚ected on (in) the product 54
62 SYSTEM EFFECTIVENESS FACTORS Explain Yes
62a All required System Effectiveness Factors have been appropriately 54
considered
CHECKING TECHNICAL PERFORMANCE 41


Starting at 51a, read each assertion in the table. If you can answer YES to the
assertion, check it off and proceed to the next one. If you need an explanation
of the assertion, go to the page number listed under the ˜˜Explain™™ column for
that assertion.


3.3 Technical Explanations

Each assertion listed in the Technical Performance Checklist is supported by a
Cause Description. In the case of the performance checklist, the support is to
broaden and deepen the understanding of the assertion. Following are explana-
tions of the assertions found in the Technical Performance Checklist.

51 ARCHITECTURE

51a All Critical Success Factors (CSFs) such as Mean Time To
Repair (MTTR), Mean Time Between Failure (MTBF), etc.,
have been documented and understood.

All Critical Success Factors (CSFs) such as MTTR, MTBF, etc., must have
been documented and fully understood as the same by both parties. When those
CSFs are incorporated into the design, a clear trail must exist from each CSF to
its incorporation into the design.

51b All modules/subsystems are well de¬ned.

All modules/subsystems are well de¬ned whenever all parameters that go
into making up the module or subsystem are understood. While this statement
can be somewhat subjective, it must be answered in objective terms. If there are
parameters that are not understood, they must be de¬ned. Look carefully at the
old saw: ˜˜We know what we know and we know what we don™t know, but our
problems are evidenced when issues arise that we don™t know we don™t know.™™
There is another old saw that states: ˜˜You certainly have a keen grasp of the
obvious.™™ The point is that all issues and considerations must be ˜˜thought
through™™ in order to discover possibilities that are not mentioned. Whenever
one of these possibilities is uncovered, it should be investigated and docu-
mented.
BLUEPRINT FOR PROJECT RECOVERY
42


51c All key functions such as time, length, weight, performance
requirements, and interfaces, etc., listed in the requirements
are appropriately covered.
All key functions, performance requirements, and interfaces, etc., listed in
the requirements are appropriately covered when all are listed on the ordinate
(the ˜˜Y™™ axis”along the side) of the Requirements Traceability Matrix (RTM)
(see Attachment 7) and the Requirements Flow-Down Matrix (RFM) (see At-
tachment 8), and the WBS locations are listed on the abscissa (the ˜˜X™™ axis”
across the top or bottom). The requirements are appropriately covered when
there is an ˜˜intersect™™ between all requirements and all the WBS locations
showing dispositions.

51d All major elements (physical and data) are described and
justi¬ed.
All major elements (physical and data) are described when they are under-
stood equally by all parties involved. All major elements (physical and data) are
justi¬ed when they contribute to the whole of the unit or system.

51e All key aspects of user interfaces are well de¬ned.
All key aspects of user interfaces are well de¬ned when they follow the ac-
cepted standards established for the industry such as IBM™s User Access Guide1
and/or Microsoft™s Interface Guidelines2 or other appropriate interface guide-
lines. Accepted psychological, physical, and human factors standards should be
followed as well.

51f The Architecture hangs together conceptually.
The Architecture hangs together conceptually when the system speci¬cation
describes the functional components of the system in terms of their behaviors
and provides component-to-component interfaces resulting in a sum of the
parts to make a whole.

52 DESIGN
52a The design process is correct and traceable to enterprise,
customer, and standard processes.
The design process is correct and traceable to enterprise, customer, and stan-
dard processes whenever the required numbers and types of Design Reviews
CHECKING TECHNICAL PERFORMANCE 43


and the content of each Design Review are traceable to the standard, the cus-
tomer, and the enterprise processes.
The design process is driven by enterprise, customer, and standard policies
and processes. The links between these processes should appear on your Stan-
dards Traceability Matrix. The Standards Traceability Matrix is further ex-
plained in Attachment 13.

52b The design is correct and traceable to the requirements.
The design is correct and traceable to the requirements when every element
of the produced product is directly traceable to a requirement. All the elements
of the design process are brought into focus through the Requirements Trace-
ability Matrix (RTM). The RTM will trace the requirement from the speci¬ca-
tion through the design process, through the quali¬cation (preproduction) test
process, through the manufacturing process, and through the ¬nal (operational)
test to end with the ¬nal delivery to the customer. The RTM is an inherent part
of the Technical Plan, which is attached to the Project Plan.
Y
Let™s take a moment to look at ethics. As you review the requirements that
you will perform to, you must look at these requirements as a professional.
FL
After all, that™s why you are being hired. If you ¬nd a requirement that you
know is wrong or will not work, you have an obligation to advise your customer
AM


of that fact. If you ˜˜sandbag™™ this issue and try to make it up with a change
later on, you are guilty of unethical conduct. Under some cases, you may be
guilty of illegal conduct. To simply trace the requirement to its source is not
TE




suf¬cient. It must, to the best of your professional knowledge, be a valid re-
quirement.

52c The design is ef¬cient.
The design is ef¬cient when it performs as the requirements document (con-
tract) demands, has the inherent reliability, maintainability, and availability de-
manded by the requirements document (contract) or meets at least the same
quali¬cations for these factors for competing products, and is economical in its
design and production and throughout its life-cycle. Ensure that all CSFs (See
Cause Description 51a) are incorporated as well.

52d The design adequately addresses issues that were identi¬ed
and deferred to design at the architectural level.
The design adequately addresses issues that were identi¬ed and deferred to
design at the architectural level when those architectural elements have been
BLUEPRINT FOR PROJECT RECOVERY
44


de¬ned and are traceable to the design. Further, they must be addressed in the
appropriate Design Review and clearly identi¬ed in the design.

52e The design is partitioned into manageable segments.

The design is partitioned into manageable segments when the segments are
logical, can be de¬ned, can be tested, can be scheduled, and can be costed. The
purpose of this partitioning is to create groupings for the Work Breakdown
Structure (WBS) that are manageable and consistent with the resources avail-
able (i.e., assigned internally or subcontracted, outsourced, or purchased as nec-
essary).

52f The design accounts for supportability, Life Cycle Cost
(LCC), total cost of ownership, and future expansions.

The design accounts for supportability, Life Cycle Cost (LCC), total cost
of ownership, and future expansions whenever all these factors are taken into
consideration in the design, production, implementation, and operations and
maintenance alternatives.
The objective of an LCC analysis is to provide a basis for choosing the most
cost-effective approach to the entire life cycle/total cost of ownership system,
product, or unit within the available resources. Sometimes this can include
planned or estimated future expansions as well. Pre Planned Product Improve-
ment (P3I) and the phasing in of those improvements should be a part of your
up-front planning. The analysis must cover the entire lifespan of the system,
product, or unit.
The LCC process provides a systematic methodology for evaluating and
quantifying the cost impacts of alternative courses of action. It can be used to
support trade-off analyses between several product design con¬gurations or the
sensitivity of a speci¬c design to changes. The LCC can, and probably will, affect
the distribution of costs between up-front design or production costs and ¬eld
operation and maintenance costs. Care must be taken to involve the entire life-
span of the system, product, or unit. Frequently, only design or production
costs are considered, leaving operation and maintenance costs to be added later.
If the speci¬cation calls for a Design To Cost (DTC) approach, its result may
well be different from the LCC. Be certain to check with the customer regarding
intent. The customer could have intended LCC but said DTC or some similar
term. The results will likely be different.
CHECKING TECHNICAL PERFORMANCE 45


John C. Sterling provides an excellent comparison of LCC models at: www.
nissd.com/sdes/papers/deslcc.htm.

52g Technical Performance Measures (TPMs) such as data
retrieval time, weight, error rate, etc., have been de¬ned and
accommodated.

Technical Performance Measures (TPMs) such as data retrieval time, weight,
error rate, etc., have been de¬ned and accommodated whenever the TPMs are
fully understood and appear in the related WBS sections and the related test
procedures.

53 DESIGN REVIEWS

53a All Design Reviews were completed according to required
processes.

All Design Reviews were completed according to required processes when
the events of the Design Review are directly traceable to the requirements stipu-
lated in standard processes, customer (contract and contract referenced) proc-
esses, and enterprise processes. In the event these processes are not available to
you, see Cause Description 53a (NO).

53b The customer approved each Design Review.

The customer will have approved each Design Review if the customer has
signed a sheet that con¬rms that the customer (through its representative, if
necessary) agrees to the Design Review package, the Design Review, and the
Design Review minutes, including Design Review action items.

54 IN-PROCESS REVIEWS

54a All required In-Process Reviews were conducted according
to required processes.

All required In-Process Reviews were conducted according to required proc-
esses when the events of the In-Process Reviews are directly traceable to the
requirements stipulated in standard processes, customer (contract and contract
referenced) processes, and enterprise processes.
BLUEPRINT FOR PROJECT RECOVERY
46


54b Each In-Process Review was approved by the appropriate
authority.

The appropriate authority will have approved each In-Process Review if the
appropriate authority has signed a sheet that con¬rms that the appropriate au-
thority (through their representative, if necessary) agrees to the In-Process Re-
view package, the In-Process Review, and the In-Process Review minutes, in-
cluding In-Process Review action items.

55 PROTOTYPES

55a The prototypes re¬‚ect the requirements.

The prototypes re¬‚ect the requirements when the customer or client agrees
that the prototype satis¬es or demonstrates the requirements.
Prototyping is a technique for gathering and validating requirements
through an early representation of the product. In prototyping, you gather pre-
liminary requirements that you use to build a representation of the solution”a
prototype. You review this with the customer, who may or may not give you
additional or different requirements. You incorporate these changes and review
them with the customer again. This repetitive process continues for an agreed
number of iterations or until the product meets the customer™s needs. The limi-
tations are established by the contract, agreement, or understanding.
Gathering requirements can mean the difference between a project™s success
and its failure. Some developers tend to gather requirements forever and some
do not gather them at all. Your project timeline must include the time required
for gathering and developing a comprehensive list of requirements. Developers
typically gather requirements in one-on-one interviews, but you can take advan-
tage of a number of alternative techniques as well.
The most certain (and slowest) method of keeping up with prototype con-
¬guration or content is to follow the basic guidelines of any product develop-
ment (requirement, baseline, change process, incorporation of change, etc.). As
an alternative, it is generally agreed nowadays that the prototypes re¬‚ect the
requirements if a physical inventory and/or functional test of the prototype(s)
re¬‚ect the actual requirements at critical points.
Prototypes are not the end products; consequently, you should modify, trun-
cate, or abbreviate the tests to expend the minimum amount of effort and re-
sources consistent with proving the issue.
CHECKING TECHNICAL PERFORMANCE 47


55b Prototypes were constructed incrementally.

For software projects, incremental construction is usually a necessity for
complex programs. The purpose of incremental construction is to create mod-
ules that are in themselves testable and provable. This becomes a timesaver
whenever you are testing a complex system, and the test fails somewhere along
the line. Whenever a test fails, the system reverts back to the last increment that
passed its tests. Whenever two tested modules are put together and the test fails,
it is likely that the interfaces are incorrect. It is also possible that the speci¬ca-
tion for one or more of the modules is incorrect. All these conditions must be
taken into consideration.
Incremental construction is generally less critical for hardware projects, but
it follows the same general precepts as software projects.

55c Prototype changes were incorporated into the design using
the Change Control Process.

Prototype changes were incorporated into the design using the Change Con-
trol Process (See Technical Cause Descriptions 61a, 61b, and 61c) when the
changes are traceable through the product to the documentation that author-
ized the change.
Prototypes should be treated the same as First Articles in their development.
This is particularly true if your process takes the prototype (or Breadboard or
Brassboard) directly to development or production. Granted, many changes are
devised during the prototype process and incorporated into the prototype to
validate their ef¬cacy. Indeed, that™s what the prototype process is all about.
However, if it is concluded that the in-process change should be a part of the
prototype, its constituents must be incorporated at some point through the
Change Control Process.
See Cause Description 55a. See the glossary for de¬nitions of these terms.

55d Each prototype change was reviewed and accepted by the
originator of the requirements.

Each prototype change was reviewed and accepted by the originator of the
requirements whenever a clear trail exists from the requirement to the accep-
tance.
In the world of prototypes, this is the equivalent of a change process. Many
times, prototype changes will be verbal from the originator. When you get a
BLUEPRINT FOR PROJECT RECOVERY
48


verbal requirement, stop and document the requirement, even if it™s just a note.
Otherwise, when you get to the end of the prototype, you will have no idea of
its contents.
If you get a change to the prototype and it does not pan out, don™t discard the
documented requirement. It is a good way to keep up with resources such as com-
puter time and labor hours that have been consumed and could be reimbursable.
56 SUBCONTRACTS
56a The sum of all subcontracts re¬‚ects all tasks allocated.
The sum of all subcontracts re¬‚ects all tasks allocated if the totality of all
subcontracts and all work to be performed internally add up to the total re-
quirements in the requirements document (contract).
The Requirements Traceability Matrix (RTM) is the tool that ties together
the requirements from the requirements document (contract) to where and
how the requirements are being performed. The Work Breakdown Structure
(WBS) should follow the RTM directly with respect to speci¬ed equipment or
modules and indirectly with respect to tasks or performance parameters. In the
vernacular, this situation is referred to as the program or project having no
holes or overlaps.
When evaluating subcontracts for holes and overlaps, consideration must be
given to the fact that there will be some overlaps with respect to required proc-
esses. For instance, if a certain quality program is required of the overall pro-
gram, it must be ˜˜¬‚owed down™™ to each of the subcontractors. In this case, it
might appear to be an overlap but it is not. It is, in fact, an appropriate alloca-
tion of requirements.
56b Each subcontract contains all tasks allocated.
Each subcontract contains all tasks allocated when the tasks contained in the
subcontract are equal to the assigned tasks from the Requirements Flow-Down
Matrix (RFM) and are re¬‚ected in the Requirements Traceability Matrix
(RTM).
57 PURCHASE ORDERS
57a The sum of all Purchase Orders re¬‚ects all purchases to be
made.
The sum of all Purchase Orders re¬‚ects all commercially available products
to be purchased for the program or project.
CHECKING TECHNICAL PERFORMANCE 49


The Requirements Traceability Matrix (RTM) is the tool that ties together
the requirements from the requirements document (contract) to where and
how the requirements are being performed. The RTM should follow the Work
Breakdown Structure (WBS) directly with respect to speci¬ed equipment or
modules. In the vernacular, this situation is referred to as the program or proj-
ect having no holes or overlaps.
When evaluating Purchase Orders for holes and overlaps, consideration must
be given to the fact that there will be some overlaps with respect to required
processes. For instance, if the ˜˜Buy America™™ clause is required of the overall
program, it must be ˜˜¬‚owed down™™ to each of the Purchase Orders. In this
case, it might appear to be an overlap but it is not. It is, in fact, an appropriate
allocation of requirements.

57b Each Purchase Order is complete.

Each Purchase Order is complete and properly written when it contains:
Reference Number, Order Date, Vendor, Contact Information, Name of Item,
Stock (Catalog) Number, Number of Units, Price, Delivery Schedule, Delivery
Location, Purchaser, and Authorizing Signature.
Most companies have preprinted Purchase Order forms. If yours does not,
create your own. Even if your Purchase Order form is nothing more than a
memo, at least it is documentation of what has been ordered and provides a
basis for ¬nancial accountability.

58 PRODUCTION/MANUFACTURING

58a All production/manufacturing processes are traceable to
standard, customer, or enterprise processes (see glossary).

All production/manufacturing processes are traceable to standard, customer,
or enterprise processes when the heritage of the process is clearly referenced in
the process.
Manufacturing processes are usually very involved and have tremendous ef-
fect on the ¬nal product. If the processes have been in effect for some time and
neither the line nor materials have changed, chances are the processes are okay.
Changing either the line (Cause Description 58b) or the materials (Cause De-
scription 58d) can have an effect on the processes that was unanticipated.
BLUEPRINT FOR PROJECT RECOVERY
50


58b The line(s) were properly designed and set up for this
(these) product(s).

The line(s) were properly designed and set up for this (these) product(s) if
the line produces the product according to the requirements.
If the line design, the processes, or the materials have not changed, chances
are that the design of the line is okay. Changing either the processes (Cause
Description 58a) or the materials (Cause Description 58d) can have an effect
on production that was unanticipated. If the line design has changed, there has
likely been an effect on the product that was unanticipated.

58c Shop orders were correct and thorough.

Shop orders were correct and thorough when the end product produced is
the product that was speci¬ed by the customer.
Shop orders contain the need for an output product. Shop orders usually
refer back to the speci¬cation (speci¬ed or derived) that the end product must
meet. Obviously the speci¬cations will be applicable to the end-product in mea-
surement terms such as size, weight, functionality, etc. Usually, shop orders
refer to the techniques or process, tools, raw products, etc., that must be used
to produce the end product.
Many products require that a number of piece parts be provided to create
the ¬nal end product. Shop orders control each step of the overall process to
ensure that the ¬nal end product is the product speci¬ed. This process is true
of either hardware or software.
Shop orders differ from work orders in that shop orders specify a product to
be provided (e.g., rod, software module, etc.) whereas work orders specify a
service to be provided (i.e., replace light bulb, etc.).

58d The materials were proper for the processes and the
product(s) and do meet the requirements.

The materials were proper for the product(s) when the product meets the
requirements. The materials must meet the requirements of the processes and/
or materials list, and they must be the materials that were speci¬ed in the sub-
contract or Purchase Order.
CHECKING TECHNICAL PERFORMANCE 51


59 UNIT TEST

59a Each Unit3 Test correctly re¬‚ects the requirement.

Each Unit Test correctly re¬‚ects the requirement when each element of the
Unit Test is directly traceable to each element of the unit requirement (speci¬-
cation) through the Requirements Traceability Matrix (RTM) or Subcontract
Requirements Traceability Matrix (SRTM).

59b Each design element that applies to the routine/module/
subsystem has its own test case.

Each design element that applies to the routine/module/subsystem has its
own test case when there is a direct correlation between the requirement and the
elements tested in the unit, subsystem, or system test through the Requirements
Traceability Matrix (RTM) or Subcontract Requirements Traceability Matrix
(SRTM).

59c Unit Test ¬ndings were reviewed for completeness and
forwarded to be incorporated into Subsystem Tests and the
System Test.

Unit Test ¬ndings were reviewed for completeness and forwarded to be in-
corporated into Subsystem Tests and the System Test when the Unit Tests are
traceable to the next level tests. When the Program Test Plan (PTP) is devel-
oped, it must include ˜˜stacking™™ the quali¬cation and acceptance tests from the
lowest level (Unit Tests) to the highest level (System Test). Care must be taken
in the PTP to ensure that all units or subsystems placed under subcontract as
well as units and subsystems you have developed adhere to this philosophy.
This technique is sometimes called the ˜˜Test Flow Forward Technique.™™
When developing the PTP and the test requirements for the subcontracts,
the Requirements Traceability Matrix (RTM) must be used to account for the
requirements being ˜˜¬‚owed down™™ into the PTP. The PTP must accommodate
the ˜˜¬‚ow-down™™ and then, in turn, account for the ˜˜¬‚ow-up™™ of the product
responses. The PTP should allow for building the system from the bottom up
through the use of the test ¬‚ow.
BLUEPRINT FOR PROJECT RECOVERY
52


59d All Problem Test Reports (PTRs) were captured,
dispositioned (allocated for action), and worked off.

All Problem Test Reports (PTRs) were captured, dispositioned, and worked
off when there is complete accountability for every error that occurred during
test conduct and every error was captured, dispositioned, corrected, and veri-
¬ed. The System Test, as written, must subsequently run without error.

60 SYSTEM TEST

60a The System Test Plan/Procedure was approved by the
customer.

The System Test Plan/Procedure was approved by the customer when the
System Test Plan/Procedure has been provided to the customer with lead time
adequate for customer review, and the customer agrees with and approves the
¬nal content. The review/approval cycle may require iteration before approval
is achieved.

60b The System Test is traceable to the requirements.

The System Test is traceable to the requirements when each requirement is
forward traceable through the unit and the subsystem to the system via the
Requirements Traceability Matrix (RTM). Each unit or subsystem requirement
must be tested at least once at the appropriate level (i.e., at the unit level or at
the subsystem level). System level requirements must be visible and backward
traceable to the requirement through the RTM. The exceptions to this statement
are those requirements that are only visible at the system level. Your RTM
should re¬‚ect this particular situation by showing the requirement in the left-
most column and the place where it is tested in the System Test. All columns
in-between will have no entries or dashes.

60c The System Test tested all elements of the system
concurrently.

System Test tested all elements of the system concurrently when all elements
of the system are called into play as they will be whenever the system is operat-
ing in its normal mode.
CHECKING TECHNICAL PERFORMANCE 53


60d The System Test was performed under appropriate load(s).4

The System Test was performed under appropriate load(s) when the loads
on the system are the loads required by the speci¬cation.

60e The System Test was performed using the same kind of
personnel that will be used by the customer.

The System Test was performed using the same kind of personnel that will
be used by the customer with regard to training, education, experience, etc. To
conduct with engineers a system test that was designed to be run by Level 1
technicians is an invalid test even when you follow all the other procedures of
the test. Many times the customer will stipulate that the actual users must per-
form the System Test. In that case, there is no question. When you are planning
your project, ensure you have set aside time to train or expose these persons to
the system and its demands.
Y
60f The System Test was properly documented and
FL
incorporated the test results of all prior-level tests.
AM


The System Test was properly documented and incorporated the test results
of all prior-level tests when the results of the Unit Level Tests and the Subsystem
Level Tests are clearly visible in the construct and conduct of the System Test.
The System Test should be an incremental test that relies upon the successful
TE




completion of all Unit and Subsystem Tests operating together under appro-
priate system loads.

61 CONFIGURATION MANAGEMENT

61a The Con¬guration Management Plan (CMP) is thorough,
complete, and authorized.

The Con¬guration Management Plan (CMP) is thorough, complete, and au-
thorized when it follows the format required by the customer and/or the enter-
prise and maintains the required content as speci¬ed in customer or enterprise
con¬guration management policy. Further, the CMP must be signed by an au-
thority that is authorized to sign such documents (usually the vice president or
director of engineering, or an equivalent position).
The Con¬guration Management process could easily be looked upon as the
BLUEPRINT FOR PROJECT RECOVERY
54


Janus process. Remember the Roman god Janus who looked both backward
and forward? That™s what the Con¬guration Management process does. It looks
backward to the baseline, as established, and forward to the test process that
will prove the viability of a change.

61b Change requests were presented and approved by an
appropriate level of the Review Board.

Change requests were presented and approved by an appropriate level of the
Review Board when the presentations and approvals followed the Con¬guration
Management Plan (CMP). See Attachment 5 for more information.

61c Version controls are in place and are re¬‚ected on (in) the
product.

Version controls are in place and are re¬‚ected on (in) the product when the
affected product is appropriately marked with the version that describes it in
the Version Description Document (VDD) (see glossary) and to which it has
been tested.

62 SYSTEM EFFECTIVENESS FACTORS

62a All required System Effectiveness Factors5 have been
appropriately considered.

To say that all required System Effectiveness Factors have been appropriately
considered, means that all the System Effectiveness Factors have been appropri-
ately considered in both the product and the processes.

Notes

1. Systems Application Architecture”Common User Access Guide to User Interface De-
sign. IBM Corporation, 1991 IBM Document Number SC34-4289 (available through
IBM ¬eld of¬ces).

2. The Windows Interface Guidelines for Software Design. Redmond, Wash.: Microsoft
Press, 1995.
CHECKING TECHNICAL PERFORMANCE 55


3. De¬ned as the smallest stand-alone component that produces a de¬nable output
from a de¬nable input. The unit may be hardware or software. In the case of hard-
ware, power can be external (i.e., a separate unit).

4. Loads are stresses placed upon a system. Loads are those stresses in units typical
for the product such as pounds, watts, ergs, numbers of subsystems, etc.

5. The System Effectiveness Factors refer to Reliability, Availability, Maintainability,
Supportability (including Logistics), Susceptability, Producibility, Human Engineer-
ing, Safety, and Security.
CHAPTER 4




RECOVERING FROM
PROGRAMMATIC PROBLEMS

4.1 General

You will probably be alerted to having a programmatic problem by observing
that one or more of your programmatic measurements or metrics is out of
tolerance. Naturally, you will want to discover the cause of this condition, and
that is where this chapter comes in. The Programmatic Recovery Checklist can
be used at any time, not only for recovery but as an adjunct to planning or
checking programmatic performance.

4.2 Programmatic Recovery Checklist

Table 4-1 is the Programmatic Recovery Checklist. Use this table to ¬nd and
isolate a problem in the programmatic part of your project. The Programmatic
Performance Checklist is presented in Chapter 2 of this book.
56




.......................... 9758$$ $CH4 12-09-02 08:29:46 PS
RECOVERING F ROM PROGRAMMATIC PROBLEMS 57


Ta b l e 4 - 1 ” P r o g r a m m a t i c R e c o v e r y C h e c k l i s t

1 STATEMENT OF WORK (SOW) Recovery Yes
1a (NO) The SOW was not properly de¬ned 59
1b (NO) The SOW is not within our capabilities 60
1c (NO) The SOW was not properly interpreted 62
1d (NO) The SOW was not properly negotiated 64
1e (NO) The SOW is not being properly monitored 65
1f (NO) The SOW is not being performed properly 66
2 SPECIFICATION Recovery Yes
2a (NO) The Speci¬cation was not properly de¬ned 67
2b (NO) The Speci¬cation is not within our capabilities 69
2c (NO) The Speci¬cation was not properly interpreted 70
2d (NO) The Speci¬cation was not properly negotiated 71
2e (NO) The Speci¬cation was not properly monitored 72
2f (NO) The speci¬cation is not being properly performed 73
3 POLICIES, PLANS, AND PROCESSES Recovery Yes

<<

. 2
( 9)



>>