<<

. 3
( 9)



>>

3a (NO) There is not a clear trail between standard policies and plans and
Project/Program Plan and Technical Plan 74
3b (NO) There is not a clear trail between customer policies and plans and
the Project/Program Plan and Technical Plan 75
3c (NO) There is no clear trail between enterprise policies and plans and the
Project/Program Plan and Technical Plan 76
4 ORGANIZATION Recovery Yes
4a (NO) The numbers of personnel assigned to each task are not correct 77
4b (NO) The mix of personnel to accomplish the task is not appropriate 78
4c (NO) The personnel are not acting and reacting as a team 82
5 TEAMS, ALLIANCES, AND SUBCONTRACTS Recovery Yes
5a (NO) The subcontracts were not properly de¬ned 83
5b (NO) The subcontract tasks are not within the capabilities of each team
member, partner, or subcontractor 84
5c (NO) The subcontracts were not properly negotiated 87
5d (NO) The subcontracts are not properly monitored 88
5e (NO) Team members, partners, and subcontractors are not performing
properly 89
6 MATERIALS Recovery Yes
6a (NO) Purchase Orders were not properly written 91
(continues)
BLUEPRINT FOR PROJECT RECOVERY
58


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

6b (NO) All vendors are not competent to perform their tasks 91
6c (NO) Purchase Orders are not properly monitored 92
6d (NO) Vendors are not performing properly 95
7 PERSONNEL Recovery Yes
7a (NO) Each person is not competent to perform the tasks assigned 95
7b (NO) Each person is not available when needed 97
7c (NO) Salaries/wages are not equal to or less than those bid 98
7d (NO) Interpersonal con¬‚icts do exist 99
8 TRAINING Recovery Yes
8a (NO) All personnel have not been adequately trained 101
8b (NO) The training program is not economical 102
9 DATA MANAGEMENT Recovery Yes
9a (NO) The proper amount of data is not being delivered on time 103
10 QUALITY Recovery Yes
10a (NO) The Quality Plan is not thorough, complete, and authorized 104
10b (NO) Speci¬c quality characteristics that are important to the project
were not identi¬ed 105
10c (NO) Quality is not measured so that improvement or degradation is not
clear 105
11 FINAL DELIVERY Recovery Yes
11a (NO) Final delivery was not accepted by the customer without delay 106
11b (NO) Third-party or drop shipping is involved 107



Starting at 1a, 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 answer NO to the
assertion, go to the page number listed under the ˜˜Recovery™™ column for that
assertion.

4.3 Programmatic Recovery Cause
Descriptions

Each assertion listed in the Programmatic Recovery Checklist, shown in Table
4-1, is supported by a Cause Description. In the case of the Programmatic Re-
covery Checklist, the support is to broaden and deepen the understanding of
RECOVERING F ROM PROGRAMMATIC PROBLEMS 59


the assertion and to provide a recovery from the issue raised by your answer to
the assertion. Following are explanations of the assertions found in the Pro-
grammatic Recovery Checklist.

1 STATEMENT OF WORK (SOW)

1a (NO) The SOW was not properly de¬ned.

When an SOW is not properly de¬ned, it can, and probably will, affect the
budget, the schedule, and the quality of the product. But you need to be careful
in claiming that the SOW is not properly written”it could be that you interpre-
ted it incorrectly.

RECOVERY

Determine what the customer really wants. Discovery of this kind of situa-
tion probably means you bid the requirement(s) incorrectly and could be in for
a lot of headaches. Further, you need to know why the requirements de¬nition
(negotiating) team made the interpretation it did so the problem won™t happen
again. If you have a good negotiator and a reasonable customer, you may be
able to adjust the requirements document (contract) to incorporate the new
interpretation as added scope. If not, and if the award has already been made
and accepted, you™ll have to absorb the cost.
To adjust the requirements, use the following process:

’ Meet with the customer.
’ Go through each paragraph of the SOW that is or might be in question.
’ Come to an understanding with the customer as to exactly what he wants.
’ Come to an understanding with the customer on how recovery can be
made. This includes:
• Schedule Recovery
• Financial Recovery
• Technical Recovery

Document all those ¬ndings and cosign the minutes of the meetings.
If the award has not been made, go through the same process. In this case
you have more leverage because your obligation begins only after you accept
the contract.
BLUEPRINT FOR PROJECT RECOVERY
60


One way to ensure that this does not happen again is to have the project
manager on the proposal team and the negotiation team. If it does happen
again, maybe you need a new project manager!
If your project does not have an SOW, create one. If you do not have an
outline for an SOW, use the following or consider the additional resources
below:


’ Task Description
’ Deliverable Documents List
’ Period of Performance
’ Schedule
’ Reference Documents
’ Modifying Factors (for instance, the number of labor hours of speci¬c
disciplines that must be provided)
’ Speci¬cation


Any item in or referenced by the SOW is a legal part of the SOW. Therefore,
each of these items must be understood. It is a good idea to search the entire
SOW and ¬nd all the requirements and the modi¬ers and group them together
for your own purposes.
A properly de¬ned SOW will contain (either incorporated or appended) the
¬ndings of the requirements discussions (negotiations). These ¬ndings are as
much a part of the requirements document (contract) as the initial document.

Additional Resources:

MIL-STD-245

1b (NO) The SOW is not within our capabilities.

You can make a quick assessment of your ability to perform the task by using
the Experience Window in Table 4-2. Ask yourself the customer and product
questions and then compare your answers to the answers and capabilities shown
in the table.
That™s not the end of it, however. Just having customer experience and prod-
uct experience is not enough; it must be positive experience. If you have had
RECOVERING F ROM PROGRAMMATIC PROBLEMS 61


Ta b l e 4 - 2 ” E x p e r i e n c e W i n d o w

Have Customer Have Product Capability to
Condition Experience Experience Perform
1 Yes Yes High
2 No Yes Moderate
3 Yes No Low
4 No No Unknown




experience with this customer, but it was not positive experience, you must
neutralize the negative effects. If you do not do this, your ability to perform (or
win) is in doubt. The same is true of product experience. If you have negative
experience with a product, you are in the same boat. If either your customer
experience or your product experience is negative, it is likely you will move
downward at least two conditions on the chart. In other words, if you have
good product experience but bad customer experience, you no longer have a
high ability to perform. It is likely you now have a low to unknown ability to
perform. Generally speaking, negative experience is worse than no experience.
In addition to satisfying the conditions of the table, you must:

’ Provide the personnel required to perform the task.
’ Provide the facilities required by the task.
’ Provide the ¬nances required by the payment schedule to support the
task.
’ Perform the requirements of the Speci¬cation (as evaluated under Cause
Description 2f).

Risk increases as the condition numbers become greater. Chances are that
you are here because your ability to perform is ˜˜moderate™™ or less. If it is ˜˜un-
known,™™ you probably should not have bid the task in the ¬rst place. Neverthe-
less, a problem exists that must be recti¬ed.

RECOVERY

Create a matrix similar to the one shown in Table 4-3 and list all the require-
ments or tasks (this includes the contents of referenced documents as well as
BLUEPRINT FOR PROJECT RECOVERY
62


Ta b l e 4 - 3 ” Ta s k Q u a l i f i c a t i o n

Project A Project B Project C Project D Project E
Task 1 X
Task 2 X X
Task 3 X
Task 4 X
Task 5 X X
Task 6



explicitly included documents) as rows and the projects (including IR&D pro-
grams) that the enterprise has performed as columns. Every requirement or task
should have an ˜˜X™™ at the intersection between the requirement and at least
one program. If not, continue with the process to try to bring the SOW within
your capabilities.
To try to bring the SOW within your capabilities, you must create a Risk
Mitigation Plan and determine how the risk can be neutralized. (Note that Task
6 in the table has no entries and therefore must be brought within your capabili-
ties). If the SOW is truly not within your capabilities, you have two alternatives,
neither of which is usually within the purview of the project manager but must
be de¬ned and then taken to management for approval or action.
If the task is within the state of the art, you may be able to buy resolution by
teaming or creating an alliance with another company. Sometimes, simply hir-
ing one or several individuals with the requisite knowledge will solve the
problem.
If it is not within the state of the art and you have not already bid the project
then no-bid. If it is not within the state of the art and you have already bid the
project, then ethics requires that you must immediately meet with the customer
and discuss the issue. Of course, you are at the mercy of the customer and his
lawyers at this point, and you may well end up repaying whatever reparations
are necessary (i.e., you committed and expanded funds but did not perform).
This is the point where we ask ourselves the perennial 2 .. wake-up question:
˜˜Why did we bid this thing in the ¬rst place?™™

1c (NO) The SOW was not properly interpreted.
When an SOW is not properly interpreted, it can, and probably will, affect
the budget, the schedule, and the quality of the product. In order to be properly
RECOVERING F ROM PROGRAMMATIC PROBLEMS 63


interpreted, it must obviously contain all the pertinent information that needs
to be interpreted.
Discovery of this kind of situation probably means you bid the task or scope
incorrectly and could be in for a lot of headaches. Further, you need to know
why the requirements de¬nition (negotiating) team made the interpretation
they did so it won™t happen again. If you have a good negotiator and a reason-
able customer, you may be able to adjust the contract to incorporate the new
interpretation as added scope. If not, you™ll have to absorb the costs.
In order to be properly interpreted, an SOW must be properly de¬ned. An
SOW is properly de¬ned when it fully describes the products or services to be
delivered and states when and where they are to be delivered. Each product
or service (sometimes called Contract Line Item Numbers or CLINs) must be
separately listed. Additionally, the following documents should be referenced,
but are usually not included:


’ Task Description Y
’ Deliverable Documents List (sometimes called Contract Data Require-
FL
ments List or CDRL)
’ Period of Performance
AM


’ Schedule
’ Reference Documents (referenced but not included)
’ Modifying Factors (for example, the number of labor hours of speci¬c
TE




disciplines that must be provided)
’ Speci¬cation
’ Financial Information (usually referenced but not included in the SOW)


Any item in or referenced by the SOW is a legal part of the SOW in a program
and an ethical part of the SOW in both a program and a project. Therefore,
each of these items must be understood. It is a good idea to search the entire
SOW and ¬nd all the requirements and the modi¬ers and group them together
for your own purposes.

RECOVERY

Meet with the customer, and use the content listing above as a guide for your
meeting. Ensure that every item is covered. Go through each paragraph of the
BLUEPRINT FOR PROJECT RECOVERY
64


SOW that is or might be in question. Come to an understanding with the cus-
tomer as to exactly what the customer wants. Come to an understanding with
the customer on how recovery can be made. This includes:


’ Schedule Recovery
’ Financial Recovery
’ Technical Recovery


Document all the understandings. It may be advisable to reverse contract
(see glossary) the customer and, when approved, include those understandings
in the requirements document (contract) as an of¬cial change. Be careful”
some customers take a dim view of this action.
One way to ensure that this does not happen again is to have the project
manager and the technical manager on the proposal team and the negotiation
team. Then, if it happens again, maybe you need a new project manager!

Additional Resources:

MIL-STD-245

1d (NO) The SOW was not properly negotiated.

Very simply, a poorly negotiated SOW is one in which there is either a mis-
understanding of the task or a lack of balance between the scope of work to be
accomplished, the amount of money to be paid, and the time allowed to com-
plete the task. Usually, the performer of the work is concerned only if the scope
of work exceeds the budget or the schedule. But the other side of the equation
should also be true. Every negotiation should be a win-win negotiation. Other-
wise, the aggrieved party will attempt to ˜˜get even.™™

RECOVERY

Determine what the customer really wants. Then determine what you are
willing to do. If you can resolve any of the issues so that they are within scope,
you™re in luck. If not, stand by for an overrun. Your enterprise policies should
call for complete minutes of the negotiation, signed by both parties. If they
don™t, establish your own policy that does. Establish a standard checklist for
RECOVERING F ROM PROGRAMMATIC PROBLEMS 65


your discussions. If you do not have such a checklist, please refer to Attachment
17.

’ Meet with the customer.
’ Go through each paragraph of the SOW that is or might be in question.
’ Come to an understanding with the customer as to exactly what he wants.
’ Come to an understanding with the customer on how recovery can be
made. This includes:
• Schedule Recovery
• Financial Recovery
• Technical Recovery

One way to ensure this does not happen again is to have the project manager
and the technical manager on the proposal team and the negotiation team. If it
happens again, maybe you need a new project manager!

1e (NO) The SOW is not being properly monitored.

The SOW is not properly monitored when the work being performed is not
being monitored by lead technical and program personnel using accepted moni-
toring techniques.

RECOVERY

Establish appropriate meetings and reviews to monitor all aspects of your
project. Table 4-4 shows the most common meetings and reviews usually estab-
lished for a project.
Because of the variability of projects, the content of these meetings and re-
views must be your own.
These interchanges must be conducted at frequent intervals. The lower the
position in the hierarchy, the more frequent the interchange. In other words,
Schedule Reviews should be held more often than Customer Reviews.
Just because the SOW is being properly monitored does not necessarily mean
the program is running properly; it only means that it is being monitored prop-
erly. The point is that if the program is not being monitored properly, you will
not know it until it is too late.
The reviews must have metrics established to indicate if each event is in
BLUEPRINT FOR PROJECT RECOVERY
66


Ta b l e 4 - 4 ” M e e t i n g s a n d R e v i e w s

Review or Meeting Cause Description Appearance
Schedule Reviews 1f, 5e, 6d
Budget Reviews 1f, 5e
Design Reviews 11a, 51e, 52a, 53
Technical Interchange Meetings 1f, 5d, 5e, 6d
Subcontractor Meetings 5d, 5e
In-Process Reviews 5d
Customer Meetings 5d, 5e




tolerance or out-of-tolerance. The content of each of the reviews must be appro-
priate for that review.

1f (NO) The SOW is not being performed properly.

The SOW is not being properly performed when any review shows that per-
formance is out-of-tolerance in such elements as:


’ Schedule
’ Budget
’ Design

RECOVERY

First, schedule the necessary meetings. Since you are having problems, the
meetings should be more frequent than normal at ¬rst. The frequency can be
decreased as the program progresses.
Second, review the measurements and metrics and determine which are out-
of-tolerance and which are in tolerance. For those that are out-of-tolerance, you
need to make a tactical decision as to how to handle each one. Some may be
allowed to run normally and, with increased scrutiny, will in time be brought
back into tolerance. For instance, there may be times when an event is behind
RECOVERING F ROM PROGRAMMATIC PROBLEMS 67


schedule today or this week but will be back on schedule by next month. That
is frequently a problem with the plan. If this is the case, let it run and return to
schedule later. Don™t fool yourself, however. Ensure that the event will be back
in tolerance shortly. Make a note of the situation so the plan can be changed
for the next project. Others may require a Tiger Team (a group formed to
resolve this speci¬c issue) to bring them back into tolerance. You must make
that judgment on-site.
Third, when all the measurements and metrics are back in tolerance, monitor
all events closely and regularly. Because elements of the project have been out-
of-tolerance and, as a consequence, additional effort has been expended, it may
be advisable to replan the project. If this is necessary, refer to the ˜˜Recovery™™
section presented in Cause Description 2d.

2 SPECIFICATION

2a (NO) The Speci¬cation was not properly de¬ned.

If you do not thoroughly understand the Speci¬cation, it is not properly
de¬ned. Granted, the problem may be your fault but, if you don™t understand
it, it makes no difference. You must understand the Speci¬cation before pro-
ceeding further. A Speci¬cation that is not properly de¬ned is one that is either
not understandable or not testable.
It is the responsibility of the requirements de¬nition (negotiating) team to
ensure that these conditions are satis¬ed. One of the best ways to ensure this is
to require that the technical manager be on the requirements de¬nition (negoti-
ating) team. The technical manager will ensure that there is full understanding
and that the result is testable or will suffer the consequences.

RECOVERY

Understand the Speci¬cation. Read it and dissect it if necessary. Use a check-
list to evaluate the Speci¬cation. If you don™t have a checklist, use the following:


’ Scope of the Document
’ Applicable documents
’ Requirements
BLUEPRINT FOR PROJECT RECOVERY
68


’ Item De¬nition
’ Performance Characteristics
• The performance requirements related to manning, operating, main-
taining, and logistically supporting the prime item to the extent these
requirements de¬ne or constrain design of the prime item and include
response time, throughput rates, and exclusion times
’ Physical Characteristics
• The design constraints and standards necessary to assure compatibility
of prime item components
’ Interfaces between the principal item being speci¬ed and other items with
which it must be compatible
’ The major components of the principal item and the primary interfaces
between such major components
’ Quali¬cation Requirements (for software) or Quality Assurance Provi-
sions (for hardware)


If a particular issue is not addressed in the Speci¬cation, it needs to be dis-
cussed. Minutes must be taken, and both parties need to agree to and sign the
minutes. You may be able to get some events to be considered out-of-scope and
get them funded. Even if you don™t get this concession, at least you™ll know
˜˜how big the bear is.™™ You may well need to replan your program around this
new understanding.
If you are dealing with a government Speci¬cation, there is an application
developed by NASA that can help with the Requirements Traceability chore.
That product is called SpecsIntact, meaning ˜˜Speci¬cations kept intact.™™ The
product was developed and is used primarily for facility projects but can be
used for others as well. Information can be requested from:

SpecsIntact
Kennedy Space Center, FL 32899
Technical Support line “ 321-867-8800
Fax: 321-867-1444
E-mail: specsintact@ksc.nasa.gov
Web site: http://si.ksc.nasa.gov/specsintact/index.asp
RECOVERING F ROM PROGRAMMATIC PROBLEMS 69


Additional Resources:

MIL-STD-490

2b (NO) The Speci¬cation is not within our capabilities.

If the Speci¬cation is not within your capabilities, you must either determine
what will bring it within your capabilities or walk away from it. If you have not
bid the task or if the contract has not been awarded, you have the alternative of
simply no-bidding or stopping your proposal effort. If you have already been
awarded the program, it™s a different story.

RECOVERY

First, you must establish your strengths and weaknesses; that is, where you
have experience and can perform and where you do not have the ability to
perform.
Based on the assumption that ˜˜if you™ve done it before you can do it again,™™
a quick assessment can be made of the task by using the Task Quali¬cation
Matrix shown in Table 4-5.
The Task Quali¬cation Matrix lists all the requirements or tasks in the left-
most column and the projects (including IR&D programs) that the enterprise
has performed across the top. Every requirement or task should have an ˜˜X™™ at
the intersect with at least one project. If not, continue with the process to try to
bring the Speci¬cation to within your capabilities.
To bring your capabilities up to the requirements of the Speci¬cation, you


Ta b l e 4 - 5 ” Ta s k Q u a l i f i c a t i o n

Project A Project B Project C Project D Project E
Task 1 X
Task 2 X X
Task 3 X
Task 4 X
Task 5 X X
Task 6
BLUEPRINT FOR PROJECT RECOVERY
70


¬rst need to create a Risk Mitigation Plan and determine how the risks (such as
Task 6 in the table above) can be neutralized.
It™s no fun to have a ˜˜tiger by the tail.™™ If this situation occurs, you could
have a real problem.
If the Speci¬cation is truly not within your capabilities, you have two alterna-
tives, neither of which is usually within the purview of the project manager but
must be de¬ned and then taken to management for approval or action.
If the task is beyond your capabilities but within the state of the art, you may
be able to buy resolution by teaming or creating an alliance with another com-
pany. Sometimes, simply hiring one or several individuals with the requisite
knowledge will solve the problem.
If the task is beyond your capabilities and is not within the state of the art
and you have not already bid the project, then no-bid. If you have already bid
the project, you must immediately sit down with the customer and lay out the
problem and the answers that have been tried and that failed to work. What
you are trying to do here is expand the content of the diversity attacking the
problem. All these steps must be undertaken as rapidly as possible. If you have
a failure and know you have a failure with no recourse, you must notify your
customer at the earliest possible time. It may hurt and hurt severely, but that™s
the only ethical thing to do.

2c (NO) The Speci¬cation was not properly interpreted.
When a Speci¬cation is not properly interpreted, it can, and probably will,
affect the budget, the schedule, and the quality of the product.

RECOVERY

Determine what the customer really wants. Discovery of this kind of situa-
tion probably means you bid the requirement(s) incorrectly and could be in for
a lot of headaches. Further, you need to know why the requirements de¬nition
(negotiating) team made the interpretation they did so it won™t happen again.
If you have a good negotiator and a reasonable customer, you may be able to
adjust the requirement to incorporate the new interpretation as added scope. If
not, you™ll have to absorb the costs. Use the following process:

’ Meet with the customer.
’ Go through each paragraph of the Speci¬cation that is or might be in
question (I really recommend that you don™t skip any).
RECOVERING F ROM PROGRAMMATIC PROBLEMS 71


’ Come to an understanding with the customer as to exactly what is wanted.
’ Come to an understanding with the customer on how recovery can be
made. This includes:
• Schedule Recovery
• Financial Recovery
• Technical Recovery


One way to ensure this does not happen again is to have the project manager
and the technical manager on the proposal team and the requirements de¬ni-
tion (negotiation) team. If it happens again, maybe you need a new project
manager.

Additional Resources:

MIL-STD-245

2d (NO) The Speci¬cation was not properly negotiated.

If the Speci¬cation was not properly negotiated, you may or may not have
an opportunity to renegotiate. If you do not have an opportunity to renegotiate,
you are likely looking into an overrun. A Speci¬cation is not properly negotiated
if there is a difference of opinion between the customer and the contractor as
to the meaning or content of any element of the Speci¬cation.

RECOVERY

If you have an opportunity to renegotiate, use the following outline or one
of your own. The point is to use a control mechanism. See Attachment 17.


’ Scope of the Document
’ Applicable Documents
’ Requirements
’ Item De¬nition
’ Performance Characteristics
• The performance requirements related to manning, operating, main-
taining, and logistically supporting the prime item to the extent these
BLUEPRINT FOR PROJECT RECOVERY
72


requirements de¬ne or constrain design of the prime item and include
response time, throughput rates, and exclusion times
’ Physical Characteristics
• The design constraints and standards necessary to assure compatibility
of prime item components
’ Interfaces between the principal item being speci¬ed and other items with
which it must be compatible
’ The major components of the principal item and the primary interfaces
between such major components
’ Quali¬cation Requirements (for software) or Quality Assurance Provi-
sions (for hardware)


If you do not have an opportunity to renegotiate (this is the norm), you will
need to replan your program. Replanning will include attempting to achieve a
balance between the three items scope, schedule, and budget. The issue will be
that scope exceeds schedule or budget or both. How do you do that?
First, establish any of these variables as ¬xed; the other two can be the vari-
ables to be renegotiated. If schedule is king, the scope can be reduced or funding
increased. If the budget is absolute, scope can be reduced or time expanded.
A primary rule of thumb is that the longer a program runs, the more it will
cost. On a hardware program, you will get more return from compressing the
existing schedule than from trying to reduce labor. On a software program,
compressing the schedule without a concomitant reduction in scope will likely
increase defects and, consequently, cost. Look for operations that will increase
the ef¬ciency of the operation and thus reduce the time it takes to perform the
operation. There are many ways to accomplish this, but any of them could
have a legal impact on the contract (for instance, working unpaid overtime).
Use the problem-solving processes discussed in Chapter 6 of this book and
select the options that are right for you, your team, and your contract.
Don™t overlook minimizing labor, but make it a lower priority than optimiz-
ing the schedule.

2e (NO) The Speci¬cation was not properly monitored.

If the requirement is valid and monitoring responsibility has been assigned
but has gone out of control without your knowledge, the fault lies in one place
RECOVERING F ROM PROGRAMMATIC PROBLEMS 73


and one place alone, with the monitor. If monitoring responsibility was not
assigned, it™s your fault.
You must insist on a Requirements Traceability Matrix (RTM) and an appro-
priately assigned monitor.

RECOVERY

Start back with the Speci¬cation and develop a Requirements Traceability
Matrix (see Attachment 7) similar to Table 4-6 below. Add a column for the
monitor™s name.
Cover every requirement, assign monitoring responsibility for every require-
ment, and establish a schedule for frequent reporting from the monitor to the
project leadership.

Ta b l e 4 - 6 ” 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 ( R T M )

Y Unit System
SOW/ WBS S/C SOW/ Test Test
FL
Spec Para Requirement Number Spec Para Number Para Monitor
SOW
AM


4.3.1 Security 06-03-02 N/A T-0304 4.4.1 Smith


Spec
TE




3.2.1 System weight 02-04-03 3.4.6 T-0045 3.4.1 Jones
shall be less
than 10,000
pounds




2f (NO) The Speci¬cation is not being properly performed.

The Speci¬cation is not being properly performed when the in-process re-
views or the design reviews were not passed properly or were not accepted by
the customer or when the product was not fabricated or produced in accor-
dance with the design or was not accepted by the customer.
The problem must be that the requirements are not being satis¬ed. You had
to state that the Speci¬cation was properly de¬ned (1a), within your capabilities
(1b), properly interpreted (1c), and properly negotiated (1d) in order to get
BLUEPRINT FOR PROJECT RECOVERY
74


here in the ¬rst place. Therefore, you must proceed with the understanding that
the requirements are not being satis¬ed.

RECOVERY

Return to the Speci¬cation and cross-check the Speci¬cation with the Re-
quirements Traceability Matrix (RTM). Determine which of the requirements
are not being met using Table 4-7 as a start.
Ta b l e 4 - 7 ” P r o b l e m C r o s s - R e f e r e n c e Ta b l e

Does the problem lie in: Go to Cause Description
Architecture 51a, 51b, 51c, 51d, 51e, 51f
Design 52a, 52b, 52c, 52d, 52e, 52f,
52g
Design Reviews 53a, 53b
In-Process Reviews 54a, 54b
Prototypes 55a, 55b, 55c, 55d
Subcontracts 56a, 56b
Purchase Orders 57a, 57b
Production/Manufacturing 58a, 58b, 58c, 58d
Unit Test 59a, 59b, 59c, 59d
System Test 60a, 60b, 60c, 60d, 60e, 60f


If the ¬rst time you know the Speci¬cation is not being properly performed
is when it misses or fails a major milestone, you are not on top of your project.
Every requirement in the RTM should have a monitor, and every major mile-
stone should have inch stones leading up to it.
As soon as you recover from the immediate problem, go back and establish
the requisite monitor for each requirement still to be performed and establish
inch stones for each milestone yet to be accomplished.

3 POLICIES, PLANS, AND PROCESSES

3a (NO) There is not a clear trail between standard policies and
plans and the Project/Program Plan and Technical Plan.
The Project/Program Plan and Technical Plan must link to standard policies
and plans through two avenues. One of those is through enterprise policies
RECOVERING F ROM PROGRAMMATIC PROBLEMS 75


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 an STM similar to Table 4-8 shown below. The STM is
explained in Attachment 13.

RECOVERY

Create an STM similar to Table 4-8 with your data inserted.

Ta b l e 4 - 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

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




Table 4-8 is a multipurpose table in that the industry, customer, and enter-
prise standards documents are all included in one chart. You can use this tech-
nique, or you can separate the documents into three separate charts. The advan-
tage of using three charts is that industry and enterprise charts will probably
remain constant for most, if not all, projects, and only the customer chart needs
to be researched. The advantage of using the multipurpose chart is that the
relationships between all elements”and there will be many”are clearly pre-
sented.
You must start with the requirement and not the appearance. Starting with
the appearance will give you a false sense of accomplishment.
Refer to Attachment 13 for more detail.

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

The Project/Program Plan and Technical Plan must link to customer policies
and plans through two avenues. One of those is through enterprise policies
and processes; the other is through the requirements document (contract). The
BLUEPRINT FOR PROJECT RECOVERY
76


requirements document (contract) references those standards through the
Statement Of Work (SOW) and the Speci¬cation.
You should have an STM similar to Table 4-9. The STM is explained in
Attachment 13.

RECOVERY

Create an STM similar to Table 4-9 with your data inserted.

Ta b l e 4 - 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

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




Table 4-9 is a multipurpose table in that the industry, customer, and enter-
prise standards documents are all included in one chart. You can use this tech-
nique or separate them into three separate charts. The advantage of using three
charts is that industry and enterprise charts will probably remain constant for
most, if not all, projects and only the customer chart needs to be researched.
The advantage of using the multipurpose chart is that the relationships between
all elements, and there will be many, are clearly presented.
You must start with the requirement and not the appearance. Starting with
the appearance will give you a false sense of accomplishment.
Refer to Attachment 13 for more detail.

3c (NO) There is no clear trail between enterprise policies and plans
and the Project/Program Plan and Technical Plan.

The Project/Program Plan and Technical Plan must link to enterprise policies
and plans through two avenues. One of those 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.
RECOVERING F ROM PROGRAMMATIC PROBLEMS 77


You should have an STM similar to Table 4-10. The STM is explained in
Attachment 13.

RECOVERY

Create an STM similar to Table 4-10 with your data inserted.

Ta b l e 4 - 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




Table 4-10 is a multipurpose table in that the industry, customer, and enter-
prise standards documents are all included in one chart. You can use this tech-
nique or divide them into three separate charts. The advantage of using three
charts is that industry and enterprise charts will probably remain constant for
most, if not all, projects and only the customer chart needs to be researched.
The advantage of using the multipurpose chart is that the relationships between
all elements, and there will be many, are clearly presented.
Refer to Attachment 13 for more detail.

4 ORGANIZATION

4a (NO) The numbers of personnel assigned to each task are not
correct.

The numbers of personnel must be contributing to a problem or you proba-
bly would not be looking at this particular issue at this time. It could be that
you simply reviewed the organization chart and found that there were more or
fewer people than called for by the organization chart and manpower table. A
big part of your job is to constantly optimize the organization.
You must constantly ask yourself: ˜˜Is the job getting done?™™ Then, follow up
with the questions: ˜˜Is the job getting done without working overtime?™™ and
˜˜Is the morale of the team high?™™ If the answer to all those questions is YES,
BLUEPRINT FOR PROJECT RECOVERY
78


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 over-
time, and morale is high, but you have too many people. Do you have too many
people or too few?

RECOVERY

If the manpower numbers do not match the organization chart, one of two
things is wrong: The number of people is wrong or the organization chart is
wrong. What a keen grasp of the obvious!
If you don™t have enough people, even if you are getting the job done, you
need to review the tasks and task distribution. If you are running under the
manpower projected, you could be saving money. Conversely, you could be
driving the people to the point where major mistakes will be made. You are the
best judge of the answer to that question. Don™t just let this situation ride.
Evaluate it carefully and be certain of your decision. How do you get more
people? That™s a question that will be unique to your organization. No matter
the ¬nal answer, you will need to perform a workload analysis and show that
you need more people. You may be able to simply request more people or go
out and hire more people or you may simply be shut off from increasing your
manpower. The answer depends on your organization and the organization and
task type (i.e., government versus commercial, ¬xed price contract versus cost
plus contract, not-for-pro¬t, volunteer, etc.). Each will have a different answer.
More people will cost more money and, if you have P&L responsibility, it will
be a large part of your cost equation.
If you have too many people, it is likely that you are headed for an overrun.
If not, it possibly means that the people are not the same level as those that
were bid. If this is the case, the project manpower must be reevaluated. Don™t
limit your investigation to numbers alone. Refer to Cause Descriptions 4b (NO),
7a (NO), 7b (NO), and 7c (NO).

4b (NO) The mix of personnel to accomplish the task is not
appropriate.

The mix of personnel to accomplish the task is not appropriate if the job is
not getting done or the mix of personnel does not match the mix shown on the
organization chart. The ¬rst is much more important than the second.
If the mix of personnel is not appropriate, it means there is a disconnect
between what was bid and how the program is manned. It is possible that the
RECOVERING F ROM PROGRAMMATIC PROBLEMS 79


job is getting done just ¬ne with an improper mix of personnel; however, if that
is the case, the staf¬ng plan is incorrect, which means you probably bid incor-
rectly. If the mix, on average, is lower than what was bid, you will probably save
some money. In this case, it makes sense to change the staf¬ng mix. If the mix
is higher than what was bid, it will probably cost you money. In this case, you
need to change the real mix to what was bid. There is a ¬ne line between mix
and numbers. For instance, you could have fewer people of higher levels who
are getting the job done, and the end result is the same dollars as were bid. The
opposite is true as well. The bottom line is to match the dollars being spent to
the task being done.

RECOVERY

The primary task is to get the job done on or ahead of time, within or under
budget, and with technical compliance.
When the task is kicked off, you may be in a personnel situation that is
different now from what it was at the time the program was bid. There are a
number of situations that can occur and that require different action.
Following are sets of budget and schedule situations and the particular action
required for each one:

On Budget/On Schedule. Stay the course!
On Budget/Ahead of Schedule. Build a reasonable schedule reserve for use
later on, particularly during integration and test.
Over Budget/On Schedule. Reassess the organization mix and personnel quali-
¬cations. Can they be changed and still get the job done? Can you reduce the
staf¬ng to get back on budget? Change mix or numbers of personnel.
Over Budget/Ahead of Schedule. Reduce the staf¬ng on the project.
Over Budget/Behind Schedule. Problem. First, don™t let it get any worse. Re-
evaluate the staf¬ng mix. Can you get by with fewer people who are more ef¬-
cient? If you can™t ¬x this problem as soon as it occurs, it is the beginning of a
˜˜death spiral.™™ If all attempts fail, try to get the scope, schedule, or cost changed.
Reassess the organization mix and personnel quali¬cations. Is this a tempo-
rary condition or re¬‚ective of the program in the long-term? If short-term, and
you have a cost type contract, increase personnel (with the customer™s concur-
rence). If you have a ¬xed price type contract, consider replanning and/or
bringing on temporary personnel or change the mix to get you back on sched-
ule. If long-term, and you have a cost type contract, replan and increase person-
BLUEPRINT FOR PROJECT RECOVERY
80

nel or increase schedule (with the customer™s concurrence). If you have a ¬xed
price type contract, replan.
Here we are talking about the organization mix which means personnel. Our
options are to leave alone, add, decrease, or change the mix. There are also
other options, such as ˜˜fast-tracking™™ and conducting parallel activities, that
may well need to be considered.
There is a price to pay for each change made. If your mix is different from
the organization chart, and if the job is getting done but the people are being
overworked, even if the job were on budget, you could change the mix so the
work balance is proper. Now, as Project Manager, you may like the short-term
results (on schedule, under budget) but the long-term rami¬cations may bite
you. Just when you need your people the most, at the end of the program, they
will be exhausted and you may lose everything you have gained and then some.
If your mix is different from the organization chart and the job is not getting
done regardless of whether or not the job is on budget, change the mix of
personnel to be the same as the organization chart.
Many times there are simply not enough people available in an organization
to go around. There are three ways to get around this problem. The ¬rst is the
most obvious”hire more people. This may or may not be the right answer. If
you hire more people, it will cost more money. Can you afford it and will
management allow it? Even though that may solve your problem, management
may take a dim view of hiring more people because, when your project ends,
the company is stuck with these additional people. Even if you are projectized
(meaning all necessary personnel are assigned directly to the project), employees
are hired by the enterprise and allocated to the program so they are company
employees (i.e., not program employees). There is an approach to management
that says: ˜˜If you hold down the number of people on a project, the people
already assigned to the project will rise to do the work required.™™ This may or
may not work. Sometimes it does work and the result on a ¬xed price contract
is more pro¬t. However, if it continues for more than a short time, the usual
result is a loss of morale and employee turnover. The second way is to work
overtime (meaning paid overtime as opposed to the above technique of forced
and unpaid overtime). This is the right technique if you need to increase man-
power by less than about 30 percent (the actual amount depends on your ac-
counting procedures) or need to increase manpower for a short period of time.
Overtime costs only the direct time worked and, perhaps, a premium. It carries
higher loadings (based on a percentage system) but not additional loadings of
G&A (General and Administrative) and overhead. The third way is to increase
the ef¬ciency of the people available. There are three ways to do this. One is to
˜˜swap out™™ one person for another. Sometimes, even swapping out for a higher-




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

paid person is more ef¬cient than hiring another person, assuming the higher-
paid person is more ef¬cient than the lower-paid person. Next, you can train,
and thus upgrade, the person whose ef¬ciency you need to improve. That, of
course, assumes training will do it. Finally, you can outsource some of the effort
or use contract employees. These are all popular options. Use care here if you
have a union contract. You need to do the math as it applies to your program
to decide which of these techniques to use.
There is another factor that must be considered with regard to personnel and
organization if you use the matrix form of management and personnel alloca-
tion. If you proposed enough personnel and time for those personnel in the
proposal and now ¬nd that there is not enough time being applied to your
program, it may be the fault of the matrix method rather than of the personnel.
What happens is that there is a loss of ef¬ciency when changing from program
to program and even in transit from program to program. If you are lucky, you
may get 80 percent of the time bid by a functional manager for a person™s time.
Someone has to pay for the inef¬ciency of the changeovers and the transit time.
The result? The program pays for it! You might try to negotiate the ˜˜lost 20
percent™™ from the Functional Manager as a part of his overhead. Before you
laugh your head off, this has worked. It depends on the importance of the
project to the company and/or the foresight of the Functional Manager. Care
must be taken here because under some conditions (federal contracts, for in-
stance) this could be an unacceptable and even illegal practice.
Under Budget/On Schedule. Nice position to be in. So long as you are not
stressing your people, you could continue and build a budget reserve.
However, you should reassess the organization mix and personnel quali¬ca-
tions. If you have a cost type contract, reduce personnel (with the customer™s
concurrence). If you have a ¬xed price type contract, consider building a sched-
ule by keeping the people and getting ahead of schedule or create a budget
reserve by reducing the personnel. Extreme care and caution need to be exer-
cised here. If you have complete budget control, this is a good move. However,
if you start to build a reserve, and management consumes that reserve as current
pro¬t, you could be in trouble downstream if you have any problems. Once it
is declared as pro¬t it is not available to you as ˜˜free™™ money.
Under Budget/Ahead of Schedule. Congratulations. This is great for a Project
Manager, but be sure you are not riding a wave that will crash soon. Project
your present staf¬ng and schedule and ensure that there is not a ˜˜black hole™™
somewhere.
Under Budget/Behind Schedule. This is typically a staf¬ng issue. That is, you
have not staffed up to get the job done. The ¬rst thing to do is to get back on
schedule, then worry about cost.




.......................... 9758$$ $CH4 12-09-02 08:30:00 PS
BLUEPRINT FOR PROJECT RECOVERY
82


Additional Resources:

˜˜Program Management”Turning Many Projects into Few Priorities with
TOC.™™ This article was originally presented at the National Project Manage-
ment Institute Symposium (Philadelphia, October, 1999) by Francis S. ˜˜Frank™™
Patrick.

4c (NO) The personnel are not acting and reacting as 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 responses to team
goals are greater than the responses to individual goals.
If the individuals are not acting and reacting as a team, it could be caused by
one or several reasons: First, there may be individuals in the group that decline
(refuse) to be a part of the team. Second, team training was not thorough or
was inappropriate. Third, there was no team training at all.

RECOVERY

If there are individuals in the group that decline (refuse) to be a part of the
team, it is likely an individual rather than a team problem. Refer to Cause
Description ˜˜7d (NO) Interpersonal con¬‚icts do exist.™™ If the responsible per-
son is replaced, you may need to recap that part of the team training package
that has to do with interfaces and responsibilities of individuals. The balance
could change by changing individuals on the team.
If team training was not thorough or was inappropriate, the actions or reac-
tions may be subtle or profound. Recovery is a matter of degree and team train-
ing needs to be changed by some amount. If the response is subtle, chances are
that the team training package can be changed slightly. In this case, identify the
shortfall and have the training coordinator rework that part of the package.
That change can then be given by you or by the training department, depending
on the size and nature of the change. If the change is profound, it is clear the
training department must revise and re-present the package. Re-presenting the
package will be subject to the same timing constraints as in the following para-
graph.
If there was no training presented before the project was started, you are
confronted with a real problem. Now, the value of preproject training becomes
obvious. A training package must be developed or purchased and presented to
the group. These are the problems of those responsible for training. Your prob-
RECOVERING F ROM PROGRAMMATIC PROBLEMS 83


lem will be how to stop work long enough to have your people attend the
training course. Most team training courses are presented in one- to three-day
sessions. You may be able to divide the course into segments to be given after
hours, or you could have the course given in a long weekend or two weekends.
These options could be impacted by the work schedule already in progress (i.e.,
the people are already overworked) or union rules that may prohibit such ac-
tion. Finally, you could stop the project and conduct the training course. Before
you start laughing, consider just how bad the situation is. This could be the
most cost-effective approach. You must be the judge.

5 TEAMS, ALLIANCES, AND SUBCONTRACTS

5a (NO) The subcontracts were not properly de¬ned.

The tasks of subcontractors, which includes team members and alliances,
are not properly de¬ned unless they have a clear trail between the subcontract
Y
Statement Of Work and the requirements document (contract) through the
FL
Requirements Flow-down Matrix (RFM), and a clear trail between the subcon-
tract Speci¬cation and the requirements document (contract) Speci¬cation
through the Requirements Traceability Matrix (RTM).
AM


RECOVERY
TE




Begin with your customer™s requirement that de¬nes your Statement Of
Work (SOW) and the Speci¬cation (Spec) for the product that you are to pro-
duce. Decompose the SOW and the Spec using the Work Breakdown Structure
(WBS), the RTM, and the RFM. Establish a clear link between the requirement
and how and by whom it will be accomplished. The best way to accomplish this
task is to establish an RTM that re¬‚ects the requirement from your customer
through your organization. At that point, part of the requirement will be allo-
cated to one or more subcontractors. The best way to keep up with this trail is
by using a Subcontract Requirement Flow-down Matrix (SRFM). Require your
subcontractor(s) to provide a Subcontract Requirement Traceability Matrix
(SRTM) to complete the link through his processes.
If you do not have an RFM or SFRM, you can use Table 4-11 as a start.
Additional information can be found in Attachment 8.
If you do not have an RTM or SRTM, you can use Table 4-12 as a start.
Additional information can be found in Attachment 7.
BLUEPRINT FOR PROJECT RECOVERY
84


Ta b l e 4 - 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 4 - 1 2 ” 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 ( 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




Additional Resources:

US Army Field Manual (FM) 770-78

5b (NO) The subcontract tasks are not within the capabilities of each
team member, partner, or subcontractor.

The subcontract tasks are not within the capabilities of each team member,
partner, or subcontractor if each has not performed the same or a similar task
before. The method by which this decision is reached is to construct a matrix
with the tasks along the side and a place for project entries across the top. The
RECOVERING F ROM PROGRAMMATIC PROBLEMS 85


potential subcontractor then identi¬es the project where the same or a similar
task has been performed. Where there are no intersects of tasks and projects,
the subcontractor has no proven ability to perform this task. Hopefully, this
exercise is being performed before the subcontract is awarded. The answer here
is simple: Do not award this subcontract to this subcontractor.

RECOVERY

If the subcontract has already been awarded to a subcontractor who cannot
perform the task, you have two options. The ¬rst is to terminate the subcontrac-
tor for cause and recompete the subcontract. The second is to attempt to assist
the subcontractor to recover. Once again, the initial steps are to create a matrix
and evaluate the subcontractor™s weaknesses. Create a matrix with the tasks
along the side and a place for project entries across the top. The subcontractor
then identi¬es the project where the same or a similar task has been performed.
Where there are no intersects of tasks and projects, the subcontractor has no
proven ability to perform this task. For each intersect that is not marked (identi-
¬ed as having that ability) a recovery plan must be created.
If a subcontract is beyond the capabilities of your subcontractor, the selection
should not have been made in the ¬rst place. Please refer to Cause Description
2d (NO), above for more ideas of how to resolve this event.
It is not unusual to assume that a partner ˜˜knows what he is doing™™ and
doesn™t need a detailed Statement Of Work, etc., to do his job. . . . Wrong! That
may work for a few months but, I assure you, in the long run it is the wrong
answer. You should have a standard, and all-inclusive, program or process for
all subcontracts. That statement applies to team members and alliances as well
as the usual run of subcontractors. If you do not have such a standard, you can
use the format in Table 4-13 as a start.
To try to bring the shortfall within your subcontractor™s capabilities, the ¬rst
action must be to create a Risk Mitigation Plan and determine how the risk
(such as the shortfall shown for Task 6 in Table 4-13) can be neutralized.
To con¬rm your position, it is a good idea to perform the vendor selection
process, at least to the evaluation level, by ¬lling in the Vendor Evaluation
Sheets for each discipline as described in Attachment 14 and shown in Figure
A14-1 there. You may need this con¬rmation later on.
If the Speci¬cation is truly not within your subcontractor™s capabilities, you
have two alternatives depending on whether the task is within the state of the
art:
If it is, you may be able to buy resolution by teaming or creating an alliance
BLUEPRINT FOR PROJECT RECOVERY
86


Ta b l e 4 - 1 3 ” Ta s k Q u a l i f i c a t i o n

Project A Project B Project C Project D Project E
Task 1 X
Task 2 X X
Task 3 X
Task 4 X
Task 5 X X
Task 6



or subcontracting with another company. Sometimes, simply hiring one or sev-
eral individuals with the requisite knowledge will solve the problem. Agreement
with the subcontractor will be necessary to determine whether the subcontrac-
tor buys the ability or you do. Make sure funding follows function. The deter-
mining factor usually is whether or not the task is reasonably separable from
the other tasks.
If it is not, you must immediately sit down with the subcontractor and dis-
cuss the issue in earnest. Is there any recovery possible from this situation? Can
it be parsed and part of it salvaged without destroying the project? Can it be
rede¬ned and accomplish the same ends?
Next, you must sit down with marketing (in the case of a teaming) or man-
agement (in the case of an alliance) or both and lay out the situation. Teaming
and alliances are frequently made for political purposes, and you need to be
very careful before making any major changes. If there are political conditions
involved, it is advisable to get a release of responsibility from management for
the nonperformance of the subcontractor. This may be dif¬cult and even politi-
cal suicide to initiate. Be careful and use your best judgment for your particular
situation
If you have a failure and know you have a failure with either no recourse or
an alternative that is not part of the Speci¬cation, you must notify your cus-
tomer at the earliest possible time. This action is absolutely required under
some contract conditions (federal contracts, for instance) and may or may not
be required under other circumstances, but it™s the ethical thing to do. It will
require sitting down with the customer, laying out the problem and the answers
that have been tried and that failed to work, and reviewing the alternatives that
could be used. All these steps must be undertaken as rapidly as possible.
RECOVERING F ROM PROGRAMMATIC PROBLEMS 87


5c (NO) The subcontracts were not properly negotiated.

Very simply, a poorly negotiated subcontract is one in which there is a mis-
understanding of the task by either party or in which a balance between the
scope of work to be accomplished, the amount of money to be paid, or the time
allowed to complete the task is lacking.

RECOVERY

Determine exactly what the problem is. Was the problem yours? That is, did
you incorrectly state the task to be accomplished, the schedule, or the budget?
Is the problem attributable to the subcontractor? That is, did he incorrectly
interpret the task, the schedule, or the budget?


’ Meet with the subcontractor.
’ Go through each paragraph of the subcontract that is or might be in
question.
’ Come to an understanding with the subcontractor as to exactly what the
baseline is.
’ Determine exactly who is at fault.
’ Come to an understanding with the subcontractor on how recovery can
be made. This includes:
• Schedule Recovery
• Financial Recovery
• Technical Recovery


Based on the answer to the question regarding fault, come to an understand-
ing of exactly how correction will be made.
If the fault is yours, negotiate what you must to get the program back on the
road again. Otherwise, you may be looking at a legal situation.
If the fault is with the subcontractor, instruct them as to what must be done
to get the program back on the road again in a Show Cause letter. Consider the
resulting proposal. If the subcontractor agrees, restructure the subcontract and
reinstitute the metrics to ensure proper monitoring. If the subcontractor does
not agree, you have two choices:
BLUEPRINT FOR PROJECT RECOVERY
88


1. Restructure the subcontract until agreement can be achieved. This can
include subdividing the overall task, changing the numbers, adjusting the
schedule, changing the design, or many other things.
2. Terminate the subcontract for cause and either perform the work yourself
or search for another subcontractor.

Make every attempt to resolve the issues. I don™t advocate ˜˜caving in™™ to a
poorly performing subcontractor, but you must make a judgment that will be
the best solution for the project. Don™t let your ego get in the way. This is a
good time to call for advice.
If this issue turns political, as it sometimes can when teaming or alliances are
involved, make sure you protect yourself by documenting the facts surrounding
the situation. If possible, get relief from that part of the program so that you
will not be held responsible for the shortcomings of a politically selected, non-
performing subcontractor. This is dangerous ground because you just might be
held responsible at that point anyway. This issue is sticky and will change with
the personalities involved.
Going to court is the solution of last resort. Remember, the project schedule
clock is still running!

5d (NO) The subcontracts are not properly monitored.

Simply stated, a subcontract is not properly monitored if an event, positive
or negative, occurs and you are not aware of its happening.

RECOVERY

Implement regular and frequent reviews at strategic points in the process to
ensure that performance is proper. Such reviews include:

’ 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
’ Subcontractor Technical Interchange Meetings (TIMs)”Informal reviews
of technical subjects
’ Subcontractor Design Reviews”Subcontractor presents and defends the
design and its support in a formal environment
RECOVERING F ROM PROGRAMMATIC PROBLEMS 89


’ Subcontractor In-Process Reviews”Informal reviews between milestones
’ Subcontractor Pretest Meetings”Brie¬ngs to establish the basis for a test
’ Subcontractor Posttest Reviews”Review of test data and issuance and
formalization of action items

These reviews must be conducted at frequent and consistent intervals. The
lower in the hierarchy (viz. project is lower in the hierarchy than company, etc.)
the more frequent the review.
Within each of these meetings or reviews, measurements or metrics must be
established and monitored to determine if an event is in tolerance or out-of-
tolerance.

5e (NO) Team members, partners, and subcontractors are not
performing properly.

Team members, partners, and subcontractors are not performing properly
when monitored events are not being performed on schedule, are not within
budget, or are not technically competent. The methods you use in determining
this status is by monitoring established measurements or metrics within the
meetings and reviews discussed in Cause Description 5d (NO).

RECOVERY

Ensure that the metrics supplied and examined at these meetings and reviews
address the critical areas. If ¬scal problems have arisen, reassess the ¬scal met-
rics being presented and select a set of metrics that give the needed visibility
into project progress. If schedule problems have arisen, reassess the scheduled
event or events that are directly and indirectly involved with this problem (i.e.,
predecessor and successor events). If technical problems have surfaced, it is
usually best to convene a Technical Interchange Meeting (TIM).
Monitored events are those events that are typical for a particular review.
Usually, Schedule Reviews, Budget Reviews, and Progress Reviews are elements
of a Project Review except when they are single-subject meetings. Within each
review there must be monitoring values and metrics to determine if the project
is performing in tolerance. Although 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 are,
at a minimum:
RECOVERING F ROM PROGRAMMATIC PROBLEMS 91


<<

. 3
( 9)



>>