. 7
( 9)


program of ˜˜continuous improvement,™™ but give it the resources that it will
return to you. In other words, make your Continuing Improvement Process a
series of Quantum Improvements. Above all, don™t try to do it all at once.
Whatever process you choose, use a facilitator. Someone who is trained in
facilitating and someone without ˜˜a dog in the ¬ght.™™ That is, someone who is
independent and objective.
Back to the 85:15 Rule again. It says that 85 percent of the problems come
from the processes (meaning documentation) and only 15 percent of the prob-
lems come from people. That rather suggests that you attack your documenta-
tion system ¬rst, doesn™t it? Not only does that follow the 85:15 Rule but you
can do it of¬‚ine without involving the operating troops and thereby reducing


Your documentation drives the actions of all the people in your corporation,
company, enterprise, and project or program. If your documentation is incor-
rect, your process and actions are going to be incorrect. If your people are
operating outside the established, documented policies, processes, and proce-
dures, you™ve got a real problem.
If you are a medium or large company, you probably have a number of
documents that drive your processes. In fact, the number of policies, processes,
and procedures that exist in a company are usually a function of the size of the
company. It follows then that if you are a small company, you have few, if any,
policies, processes, and procedures. All that is understandable.
If you are part of an enterprise that deals in projects or programs, you must

have more than just a few people in your company. To ¬t that pro¬le, you
must have executives, staff, and operations and that means you need centralized
documentation, and that usually means a library. A library can take several
forms. It can be a box of books, an organized place for ¬ling documents, or a
computer. The documents can be your own or they can be imported from
other sources. Additionally, the documents can be hard”meaning books”or
soft”meaning in a computer somewhere. Most likely, they are a combination
of both.
When considering a library, consider the order of the documents shown in
Figure 10-1. The order is important, particularly on the high end. If you are a
very small company, you will have your own priorities. You will probably start
at the Processes level or even the Reference Documents Level. The Policy level
isn™t particularly important because the guy who establishes policy is standing
next to you. Normally, however, in a medium or large company, you need
policies before you need processes, plans, and procedures. Reference documents
and speci¬cations will be a matter of doing business.
Let™s assume that you are a medium or large company and already have a
traditional library. It will be a huge step in the right direction to have all (or at
least part) of that documentation in digital form. That form allows easy updat-
ing and follows the ¬rst rule of modern documentation: ˜˜Don™t create, cut and
paste.™™ It allows the supervisor on the ¬‚oor to have a copy of ¬nancial policies
as well as copies of current work orders stored in the computer. It also allows
you to control the documentation by ensuring a single master copy that is refer-
enced by all users.
Figure 10-2 presents a schematic of an electronic library. The cylinder in the
center is the central computer of the database that contains all the digitized
documentation data. As you can see, that data is available to all personnel with
computer access. In today™s world, that usually means everybody. Further, all

F i g u r e 1 0 - 1 ” A Ty p i c a l Tr a d i t i o n a l L i b r a r y

Ref. Docs



Figure 10-2 ” Schematic of an Electronic Library

Senior Advisory Council



Internet E-mail


the employees could now have e-mail capability and Internet connectivity for
communication. At the top of the diagram, you will see some terms that may
or may not be familiar. Certainly, nearly everyone understands who the Admin-

istrator is. That™s the person responsible for inputting and maintaining and
controlling the database, as directed. The Senior Advisory Council is the author-
ity for database content. The ˜˜Council™™ can indeed be a council, or it can be
one person. Your company will decide on how large it should be and who
should be a part of it. With the simple diagram shown in Figure 10-2, you can
see the concept of the Electronic Library. I go into a considerable amount of
detail in my Strategy for Success workshops regarding how to set up and control
an electronic library for your scheme.

10.3 Data Trail

It is imperative that you have a data trail from the policy level to the implemen-
tation level and from the requirements to the sell-off test. In other words,
throughout the system. To simply have a ˜˜bunch of books™™ is not a documenta-
tion system. In fact, it™s not even a library. I spent a lot of time in this book

encouraging a data trail from the requirement through the programmatics and
the technical aspects of your project. The same is true of your administrative
link. In my Strategy for Success workshops, I spend a lot of time going through
the documentation to performance links and back again. Believe me, it™s worth
the effort.

10.4 Modifying Methods

Well, just how do you modify the information in (and not yet in) your database?
The techniques will vary according to who is responsible for the data in the ¬rst
Project data as it applies to your project, there should be no problem at all.
After all, it is you who are responsible for this data, and you have control of
your Program and Technical Plans and all the other data generated by your
project. As Nike says: ˜˜Just do it!™™
Project data that will be applicable to other projects should be a part of the
enterprise database. That data should be routed through the ˜˜Senior Advisory
Council™™ or whoever else is responsible for commonizing and approving data
to be used by all projects and incorporated into the database.
Corporate, company, or enterprise data that will be applicable to the entire
enterprise should be a part of the enterprise database. That data should be
routed through the ˜˜Senior Advisory Council™™ or whoever else is responsible
for commonizing and approving data to be used by all projects. It should be
clear at this point why an enterprise needs a ˜˜Senior Advisory Council.™™
Customer data takes a different route. Either the contracts manager or a
senior enterprise executive should draft correspondence to the customer sug-
gesting the change to the customer documentation and provide substantiating
documentation as to why this needs to be done. This is a diplomatic issue and
should be handled by someone in the organization capable of handling diplo-
matic correspondence. Incorrect handling of this issue could end up with a
situation that could create far more harm than good.
Standard documentation, such at that written by a standards group, must be
handled by an expert quali¬ed to speak on the subject. After all, the standards
group had a committee of experts that created that standards data”after much
research and argument”in the ¬rst place. Be sure to substantiate your position
clearly and thoroughly. Be absolutely certain that you are correct and have your
correspondence drafted by an expert and cosigned by a senior enterprise execu-
tive. When everyone is satis¬ed, send your correspondence to the standards


11.1 General

The data on the Compact Disk (CD) complement the tables and Cause Descrip-
tions in the book. The presentation, however, is slightly different. The add-on
processes are unique to the book and are not repeated on the CD. It is best to
read the book ¬rst and get a feel for how to use the tables and Cause Descrip-
tions and for the add-on process.
If your project is failing or off-track, you can jump straight into the data on
the CD. You will be guided by simple instructions. When you correct the prob-
lem, please, go back and read the book to preclude your project getting off-
track again.

.......................... 9758$$ CH11 12-09-02 08:30:37 PS

11.2 Loading

Insert the enclosed CD into the CD tray on your computer. The CD should
open automatically but, if it does not, double click on the My Computer icon
and then double click on Blueprint (D:). The CD will open. It is a native pro-
gram and does not need installation.

11.3 Using the Tables

The tables on the CD are similar to the tables in the book except that they are
designed to be continuous and interactive. As you click on each action”
Explain, Yes or No ”you will be taken automatically to the correct detail. Chap-
ter 1 explains this action in more detail.
The tables are designed to allow you to enter your data into spaces provided
and to create your own Cause Descriptions. These speci¬c actions allow you to
enter your own data into the blank spaces provided. However, you cannot
change the existing table entries or existing Cause Descriptions. Chapter 9 ex-
plains this action in more detail.
You are allowed to print anything from the CD but you may not copy the

11.4 Using the Attachments

The Attachments in the book are, by necessity, reduced to book size. The At-
tachment materials contained in the CD, however, are standard (81/2 x 11) size.
This means you can copy them onto your computer and change them to ¬t
your project without a lot of retyping.

At the outset, I introduced the Phoenix”a mythical bird that died and reconsti-
tuted itself and rose from the ashes. That was the theme of the book”to rise
from the ashes created by a failure of the project or program somewhere in its
In Chapter 1, you searched for a cause for the problem by de¬ning the ˜˜Fam-
ily of Causes™™ to which the problem or issue belonged and then using the Search
Tables to ¬nd the Causes that contributed to the problem or issue. When you
found the Cause, you turned to the Cause Description to discover a Recovery
Plan to bring the project back into tolerance again. At the end of Chapter 1, it
was recognized that the Search Tables and Cause Descriptions provided in the
book would not be all-encompassing for every problem or issue that could
possibly exist in any or all projects/programs. You recognized that you needed
a process to expand the Search Tables and Cause Descriptions to tailor them to
your particular situation.
To support Chapter 1 and to continue with the idea of creating new issues

.......................... 9758$$ SUMM 12-09-02 08:30:42 PS

unique (or peculiar, if you prefer) to your product or company, I provided
several techniques in Chapter 6 to broaden the scope of the Search Tables and
the supporting Cause Descriptions. The techniques presented were: Brain-
storming, Benchmarking, Standard Processes, Customer Processes, Enterprise
Processes, and Project/Program Processes.
Now that you had this large amount of data, you needed to organize it. In
Chapter 7, I presented four ordering techniques to quickly order the data. The
techniques were: The 85:15 Rule, Cause and Effect Diagrams, Af¬nity Diagrams,
and Relationship Diagrams.
It is good to have the data ordered, but now the data must be evaluated. In
Chapter 8, I presented four analysis techniques to accomplish this end. Remem-
ber, these analytical techniques were: Pareto Analysis, Force Field Analysis, Fail-
ure Mode Effect Analysis (FMEA), and ¬nally, Monte Carlo Simulation. At the
end of the chapter you were able to select the causes you wanted to include in
your expanded Search Tables and Cause Descriptions and the order in which
you should incorporate them.
To review the overall process, consider Table 12-1. This table is a composi-
tion of the data originally presented as Table 6-1 Expansion Methodologies,
Table 7-1 Ordering Techniques, and Table 8-1 Analysis Techniques.
Consider solving a typical problem. In the Process Table, use all the tech-
niques to generate the largest pile of data you can. Then proceed to the Ordering
Table, and ¬rst use the 85:15 technique to separate your data into a ˜˜process™™
pile and a ˜˜people™™ pile. Then create a Cause and Effect Diagram to organize
your data (perhaps you chose to only use the ˜˜process™™ pile). Finally, go to the
Analysis Table and perform a Pareto Analysis to get the ˜˜biggest bang for the
buck.™™ If you are solving a technical problem, you may want to continue on
(using the dotted lines) to the Failure Mode Effect Analysis to predict the results
before you implement the solution.
This is only one ˜˜data trail™™ you can choose through the tables. That™s why
I provided a number of alternatives to allow you to choose the ones that are
right for you. In Chapter 9, you were confronted with how to incorporate the
new causes into your project and indeed, into the other projects/programs of
the enterprise. I presented three methods for incorporating these new causes.
You will recall that those techniques were called Creating ˜˜On-Ramps,™™ ˜˜Slip-
ping in the Fix,™™ and ˜˜Dumping™™ the Fix. You were then given methods for
selecting your technique based on the needs of the project, the time available,
and your own personality. And, to provide the tools to incorporate these
changes, I left room in the Search Tables for you to ˜˜Slip in the Fixes™™ or to
˜˜Dump the Fixes.™™

Ta b l e 1 2 - 1 ” P r o c e s s F l o w - T h r o u g h Ta b l e s

Process Purpose
Brainstorming To create a large body of related data
Benchmarking To discover/research ˜˜Best Practices™™ or
˜˜Best-in-Class™™ for your industry or product
Standard Processes To discover/research standard processes in
your industry or in support of your industry
Customer Processes To discover/research processes unique to
your customers
Enterprise Processes To discover/research processes characteristic
of your enterprise to serve this (these)
business areas
Project/Program Processes To provide processes speci¬cally for this

Ordering Technique Purpose
85:15 Rule To organize information into ˜˜process™™ or
˜˜people™™ categories.
Cause and Effect Diagrams To show the relationship of reasons to causes
and causes to effects
Af¬nity Diagrams To organize large groups of information into
meaningful categories
Relationship Diagrams To show the relationship(s) between

Analysis Technique Purpose
Pareto Analysis To select the 20 percent of the issues that
provide 80 percent of the results
Force Field Analysis To understand restraining forces and driving
Failure Mode Effect Analysis (FMEA) To predict potential failures
Monte Carlo Simulation To re¬ne estimates

Finally, the whole thing was concluded by recognizing that the ˜˜thing™™ that
had allowed the project to be derailed in the ¬rst place needed to be corrected.
It was suggested that you use Quantum Improvement methods and then update
the documentation and that you provide a complete data trail back to the ˜˜of-
fending™™ direction and the ˜˜how™™ of modifying. The technical aspects of modi-
¬cation as well as the diplomatic efforts were discussed.

Throughout the whole book, I have advocated using the Search Tables as a
checklist and the Cause Descriptions as the detail for planning your project.
Please, don™t let your project get to the point of failure before looking ahead at
what might happen and then building in processes, steps, and metrics to avoid
the issue and determine when a problem is about to occur.
You all know this is what you should do, but for some reason it rarely gets
done completely. When that occurs and a project element goes out-of-tolerance,
you will ¬nd that this book is worth its weight in gold.

After Receipt of Order (ARO) “ A number, usually expressed in days, weeks,
or months, as a point after the of¬cial noti¬cation of the start of the project.
Example: The PDR is due 90 days ARO. This technique allows the elements of
a project schedule to move relative to the award or beginning of a project or

Alliance “ A grouping of two or more companies for one project or program
(a tactical alliance) or for all projects or programs (a strategic alliance) that
require a particular combination of products or services.

Architecture “ The structure established for the system as a whole or the
structure established for a subsystem within the system.

Assertion “ An af¬rmative statement.

Balanced Scorecard “ A complex strategy-based process. The process involves
researching the competitive environment, customers, stakeholders, employees,
and company ¬nancial and growth objectives.

Benchmark “ Also referred to as Best Practices, Exemplary Practices, and
Business Excellence. Usually a series of studies regarding business processes
and practices among businesses in the same or sometimes disparate business
areas. You can use the benchmarks to compare your performance to others.
The benchmarks may or may not be the best ¬gure of excellence.

Best-of-Breed “ A term applied to a system or process that has singular or
limited application but is the best there is for that application. The highest
level of achievement for that element.

Brassboard “ Similar to Breadboard (below) but usually with hard parts that
are soldered or welded together. Not a deliverable.

Breadboard “ A table layout of the article being developed so that parts and
wiring can be changed easily. Breadboards are usually many times the physical
size of the ¬nal product. Not a deliverable.

Budget Review “ A review of the budget associated with all or part of a task
or contract. Usually, but not always, Budget Reviews are conducted concur-
rently with Schedule Reviews and Performance Reviews in Project, Program,
or Division Reviews.

Business Process Improvement “ A generalized term that includes such spe-
ci¬c programs as Total Quality Management (TQM), Business Process Reen-
gineering (BPR), Business Process Redesign (also referred to as BPR), Bench-
marking, and Best Practices as well as other less well-known programs aimed
at improving the process of a business.

Buying In “ The act of bidding a project or program at cost or less than cost
for any number of reasons.

Capability Matrix “ A matrix consisting of tasks along the side and previous
projects across the top. An intersect is acknowledged whenever the project

contained the task and was successfully completed. The purpose of the capabil-
ity matrix is to determine whether or not to bid a program or to identify those
capabilities in inventory and those needed to approach a program or project.

Capability Maturity Model (CMM) “ The Capability Maturity Model for
Software (CMM or SW-CMM) is a model for judging the maturity of the
software processes of an organization and for identifying the key practices that
are required to increase the maturity of these processes. The SW-CMM has
been developed by the software community with stewardship by the SEI.
(From the SEI/Carnegie Mellon Web site.)

Challenge (Tasking) “ A top-down application of budget and/or schedule
and/or manpower that is less than requested. The challenge (tasking) imposed
upon a work package leader by the project of¬ce (project manager).

Change Control Process (part of the Con¬guration Management Process) “
A process to control the technical baseline of a project to ensure the baseline
is always consistent with requirements and all changes are approved and docu-
mented by both parties (customer and contractor).

Change Order (CO) “ A formal change introduced into a project controlled

by a Change Control Process.

Company “ A corporation or partnership.

Con¬guration Management Process “ A process designed to maintain con-
trol of the technical baseline using formalized processes and consisting of a
Control Board, a Chairman of the Control Board, and procedures for receiv-
ing, modifying, documenting, implementing, and verifying changes to the

Contract Data Requirements List (CDRL) “ A list of documents that are
contractually deliverable under the terms of a contract.

Contract Line Item Number (CLIN) “ An ordering or sequencing number
assigned to functional or physical deliverables that are contractually required
on a program.

Corporation “ A legal entity composed of a number of people joined together
for a common purpose. Such legal entities are formed under local, state, or

federal laws. Some corporations are public and some are private; some private
corporations are organized for pro¬t and some are organized for nonpro¬t.
Private corporations often issue stock to their owners in return for the money
they invest. [Modi¬ed from The Plain-Language Law Dictionary by Robert Ro-
thenberg (see bibliography)].

Cost of Quality “ A cost factor added to the basic bid cost by a subcontractor
for labor and materials to bring the subcontractor™s product up to the quality
he should have produced but didn™t. The Cost of Quality is a consideration
when evaluating bids by subcontractors. The amount bid by a subcontractor
plus the quanti¬ed Cost of Quality is the true bid of that subcontractor.

Cost Plus Contract “ A contract that recognizes that pro¬t is a necessary part
of getting a job done. Cost plus contracts allow a pro¬t over and above the
cost involved.

Cost Review “ A review of the cost associated with all or part of a task or
contract. Usually, but not always, cost reviews are conducted concurrently
with Schedule Reviews and Performance Reviews in Project, Program, or Divi-
sion Reviews.

Cost Type Contract “ A contract that includes cost plus provisions. The fee
structure may be a percentage of cost, a ¬xed percentage or original bid cost,
an award amount or an incentive amount. All structures are above the cost of
getting the job done except that some Cost Plus Incentive Fee (CPIF) contracts
have negative fee considerations as well as positive fee considerations.

Customer Meeting “ A meeting with the customer, usually on a formal basis,
where an agenda and minutes are a part of the meeting. May be scheduled and
required by the requirements document (contract) or may be quickly called
by the customer.

Customer Processes “ Those processes established by a customer for use in
performing that customer™s programs or projects. Examples of such processes
are: Mil Standards, DoD Standards, Data Item Descriptions (DIDs), NASA
Standards, FAA Standards, Municipal Government Standards, and so on.

Customer Requirements “ Speci¬c requirements invoked in a requirement
document (contract) to be a part of the task at hand. In this case, the require-
ment may be stated or referenced.

Data Item Description (DID) “ A document consisting of a few sheets that
outlines the format and requirements for a speci¬c data report to be submitted
as part of a contract. DIDs are assigned descriptive alphanumeric sequences.
Originally issued to support federal government contracts but are now more
widely used.

Design Review “ A periodic review of the design and its requirements. Typi-
cally the performer (contractor) presents and defends the design together with
all supporting data. Design Reviews are typically performed on an ever more
detailed basis and frequently will be performed on an incremental basis.

DOD “ The Department of Defense of the United States of America. Most
other countries refer to this agency as the Ministry of Defense or MOD.

EIA “ See Electronic Industries Alliance.

Electronic Industries Alliance (EIA) “ An organization of over 2,300 member
companies that, among other activities, mediates recommended standards by
its members and publishes the results.

Enterprise “ The ˜˜Today™™ term for an economic unit. An enterprise may be a
corporation, a company, a pro¬t center, or a cost center within a company or

Enterprise (Corporate/Company) Processes “ Those policies, plans, proc-
esses, and procedures at the enterprise level that drive the content of project
and technical plans and the conduct of project activities.

Enterprise Requirements “ Speci¬c requirements invoked by an enterprise on
all or speci¬c projects at the judgment of the enterprise.

Experience Window “ A tool to quickly evaluate whether or not you should
bid or can perform a certain task. The principal variables are customer experi-
ence and product experience.

Fast Track “ A method of conducting elements of a project in parallel, rather
than in series, or by deleting a task, or truncating the elements of a task in
terms of time or by taking a risk on one or more elements of the project to
shorten the overall time involved in that element and, ultimately, the project.

Firm Fixed Price (FFP) “ A contract that is bid and awarded as a ¬xed
amount. The customer pays a ¬rm ¬xed price for some amount of work. The
contractor™s fee or pro¬t is contained within that price.

First Article “ The ¬rst article produced by the production process. The First
Article is used not only to validate the design but to validate the production
process as well. Sometimes the First Article is delivered ¬rst but, most often,
its delivery is held in abeyance, and it is used to try out improvements in
design and processes. Frequently, the First Article is delivered last.

Fixed Price Contract “ A contract in which the basic price is ¬xed but the fee
structure can be of several different types such as Fixed Price/Incentive Fee
(FP/IF), Fixed Price/Award Fee (FP/AF), and Firm Fixed Price (FFP).

Force Majeure “ From the French, generally meaning an act of God but now
used as a legal term that allows recovery of costs or limits liability (depending
on how written) when an act of war or superior force, such as a ¬‚ood, ¬re,
etc., impacts the performance of the task.

Functional Manager “ A line manager in charge of a function such as software
engineering, hardware engineering, etc.

General and Administrative (G&A) “ An element of cost that generally in-
cludes the salaries of nonoperating personnel such as corporate management,
human resources, ¬nance, etc., as well as Bid and Proposal (B&P) costs. Some
companies include these costs as overhead or burden. The breakout of costs
into different categories is an accounting function and is usually standardized
within the type of industry in which you operate.

IEEE “ See Institute of Electrical and Electronic Engineers, Inc.

Independent Research and Development (IR&D) “ Usually an in-house Re-
search and Development (R&D) program funded by the company. When the
company funds this research, all results are the property of the company and
are usually patented.

In-Process Review “ A review, frequently informal, that is conducted while a
project is in process and before a major formal review.

Institute of Electrical and Electronic Engineers, Inc. (IEEE) “ A nonpro¬t,
technical professional association of more than 377,000 individual members in
150 countries. The IEEE is a leading authority in establishing and maintaining
consensus-based standards in electrical and electronic industries.

International Standards Organization (ISO) “ The ISO, established in 1947,
is a worldwide federation of national standards bodies from some 140 coun-
tries, one from each country whose mission is to promote the development of
standardization and related activities in the world resulting in international
agreements that are published as International Standards. (Paraphrased from
the ISO Web site.)

Lessons Learned “ A conference, or simply a report, at the end of a project to
review the situations that occurred during the project and their impact on the
project and how the situations could be avoided or cured in the future.

Liquidated Damages “ An amount stated in a contract, which the parties
agree is an estimation of damages owed to one of the parties in the event there
has been a breach by the other. (From the Plain Law Dictionary by Medbook
Publications and Parsons Technology, Inc., 1997.)

Materials “ Items where the Speci¬cation is determined by the vendor. You
are buying to the vendor™s Speci¬cation, not yours.

Milestone Review “ A review of the milestones in the schedule against work

MIL-HDBK “ Military Handbook

MIL-SPEC “ Military Speci¬cation

MIL-STD “ Military Standard

Mission Statement “ A statement of an action for the organization to take
and a positive outcome of that action in one sentence. As an example, Abra-
ham Lincoln™s mission: To preserve the Union.

Myers-Briggs Type Indicator (MBTI) “ A four-character designator derived
from a four-pair, eight-character set resulting in sixteen combinations that
represent a type of person (or later a company). Originated by Isabel Myers

and Katherine Briggs. Example: An ENTJ is an Extrovert (as opposed to an
Introvert), INtuitive (as opposed to Sensing), Thinking (as opposed to Feel-
ing), Judgmental (as opposed to Perceiving) type of person.

NASA “ National Aeronautics and Space Administration.

Negotiating Team “ See Requirements De¬nition Team.

Negotiation Envelope “ Predetermined limits to which the Negotiating Team
can negotiate. Usually includes scope, schedule, cost, and manpower.

On the Job Training (OJT) “ Informal training provided on the job by others
involved in the same category of work.

Out-of-Tolerance “ A measured parameter that is beyond its nominal value,
plus or minus a percentage of that value that is the allowable range in which
that parameter may operate.

PERT “ See Program Evaluation Review Technique.

Pro¬t and Loss (P&L) “ The result of a contract beyond cost. A contract that
returns money beyond all costs is a pro¬t. A contract that costs more than its
income is a loss.

Pro¬t and Loss (P&L) Responsibility “ Responsibility assigned to a program
manager for operating the program and returning a pro¬t to the company.

Program Advisory Council “ A special-purpose management team that ad-
vises, but does not manage, the project or program team. The Program Advi-
sory Council acts as a transparent link between the project team and manage-
ment and the customer.

Program Evaluation Review Technique (PERT) “ A scheduling system char-
acterized by linking together the longest ˜˜string™™ of events to create a critical

Program Manager “ The same as a project manager, except a program man-
ager has P&L responsibility and manages a contract with a customer outside
the parent organization.

Program Of¬ce “ See Project Of¬ce.

Programmatic “ Those issues associated with the management of a project or
program. Such issues include budget, schedule, etc. Programmatic issues are
separate and distinct from technical issues.

Project Manager “ The individual responsible for managing the entire project
internal to the parent company.

Project Meeting “ Same as team meeting.

Project Of¬ce “ The group of people and functions that surround the man-
agement of a project or program. These functions are usually those performed
by the project manager, the administrator, and the scheduler, as well as the
secretarial function. Sometimes the chief engineer is considered as a part of
the Project Of¬ce.

Project Review “ A review of project activities as de¬ned by the Enterprise.
Usually consists of a review of cost, schedule, and technical status at the project
level and with project personnel in attendance. Usually held before a Division
or higher level review to ˜˜iron out™™ issues.

Projectized “ A project or program that essentially stands alone within an
organization. The projectized organization contains all the line functions nec-
essary to meet the requirements of the task or contract. Staff functions such as
¬nance and human resources are usually not included although they may be
in extremely large projects or programs.

Prototype “ A nonproduction build of hardware or software generally used to
test concepts and/or content and/or interfaces. Older terms, still in use in some
places, are Breadboard and Brassboard. This term is sometimes extended to
include the First Article (see above) of a production run. Prototypes should
not be deliverable.

Purchase Order (PO) “ A document used to commit project, program, or
company funds to a certain purchase. The PO must contain the item, the
vendor, the price, and the delivery date. Other contents are at the option of
the company.

Reengineering “ The common form of Business Process Management (BPM)
used to establish standards for process design, deployment, execution, mainte-
nance, and optimization.

Request for Proposal (RFP) “ A request issued by a customer for a full re-
sponse from companies. This usually means the response must include a Tech-
nical Section, a Management Section, and a Cost Section. RFPs are usually
issued for complex requirements.

Request for Quotation (RFQ) “ A request issued by a customer for a limited
response from companies. This usually means a limited Technical Section (if
any at all) and a cost for the item. RFQs sometimes require cost ˜˜back up™™
(the rationale for the cost).

Requirements “ Webster de¬nes requirements as something wanted or needed
or something essential.

Requirements De¬nition Team “ An ad hoc group formed to formalize the
requirements for a project or program. For a project the group is a require-
ments de¬nition team; for a program the group is a negotiating team.

Requirements Flow-Down Matrix (RFM) “ A matrix created to track those
requirements that must be ¬‚owed down and how they are ¬‚owed down to
various Work Packages, subcontracts, and purchases. Example: Buy American
Clause in a contract.

Requirements Traceability Matrix (RTM) “ A matrix formed to track each
requirement through the lifecycle of the project. The horizontal axis of the
matrix begins at project start (program award) and ends with handover. The
vertical axis lists each requirement.

Research and Development (R&D) “ A project or program on the leading
edge of technology. R&D projects can be performed in-house (see Indepen-
dent Research and Development above) or for a customer as a Research and
Development program.

Reverse Contract “ To take a course of contractual action and advise your
customer that you intend to incorporate this change unless otherwise directed.
(Be careful”some customers take a dim view of this action.)

Reverse Engineer “ To make a change in the Speci¬cation or design and advise
the customer that you intend to incorporate this change unless otherwise di-
rected. (Be careful”some customers take a dim view of this action.)

Risk Mitigation Plan “ A plan to recognize, evaluate, and provide an approach
to eliminating, mitigating, or neutralizing a risk, technical or programmatic.

Root Cause “ The essential heart or underlying reason.

Schedule Review “ A review of the schedule associated with all or part of a
task or contract. Usually, but not always, Schedule Reviews are conducted
concurrently with Cost Reviews and Performance Reviews in Project, Pro-
gram, or Division Reviews.

Show Cause (Letter) “ An order for a company (usually a contractor or sub-
contractor) to tell why it thinks the sender (usually the customer) should not
take a certain action such as cancellation of the contract. Should the show
cause not be answered, the letter will outline the next step that will be taken.

Software Engineering Institute (SEI) “ The Software Engineering Institute
(SEI) is a federally funded research and development center sponsored by the
U.S. Department of Defense through the Of¬ce of the Under Secretary of
Defense for Acquisition, Technology, and Logistics [OUSD (AT&L)]. The
SEI™s core purpose is to help others make measured improvements in their
software engineering capabilities. (From the SEI/Carnegie Mellon Home

Speci¬cation (Spec) “ That part of the requirements document (contract) that
establishes how the system as a whole will perform.

Standard Processes “ Those processes established and standardized by such
organizations as IEEE, IATA, ISO, EIA, ASME, ASTM, CCITT, NEMA, UL,
and a host of others. These processes are usually invoked by reference rather
than by being restated.

Standard Requirements “ Reference documents common to your business
area or product such as IEEE Standards, SEI Standards, EIA Standards, etc.,
that are invoked by the requirements document (contract) or the enterprise
policies, plans, processes, or procedures. These standards are usually refer-
enced rather than being reprinted simply to save space.

Statement Of Work (SOW) “ That part of the requirements document (con-
tract) that describes what the task is and when the task will be accomplished.

Subcontract (S/C) “ A contract that delegates work to a third party that con-
tains a Statement Of Work (SOW) and usually a Speci¬cation.

Subcontract Requirements Traceability Matrix (SRTM) “ A Requirements
Traceability Matrix (RTM) used by a subcontractor (see Requirements Trace-
ability Matrix above).

Sub-Program Of¬ce (SPO) “ The SPO has the same responsibilities as the
Program Of¬ce except that the SPO is responsible for only a portion of the
overall system and usually does not have contractual responsibility and may
not have P&L responsibility.

System Engineering Management Plan (SEMP) “ A top-level plan that iden-
ti¬es and controls the overall engineering process. The SEMP is usually sup-
ported by a number of specialty engineering plans that contain much of the
engineering detail.

Task (Challenge) “ See Challenge (Tasking) above.

Team “ A group of people, usually interdisciplinary, brought together to per-
form a task. A team is a casual relationship, as opposed to teaming, which is a
legal relationship

Team Meeting “ A meeting, usually somewhat informal, of the entire team
where project issues are discussed.

Teaming “ The legal association of two or more organizations (companies) to
perform a speci¬c task. Teaming (between companies) is separate and distinct
from a team (individuals).

Technical Interchange Meeting (TIM) “ A meeting wherein technical issues
are discussed. Contractual issues are not discussed.

Tiger Team “ An ad hoc group formed to pursue a speci¬c problem or issue.
Their charter may be to study the issue or to ¬nd a ¬x or to ¬x it.

Total Quality Management (TQM) “ ˜˜A structured system for satisfying in-
ternal and external customers and suppliers by integrating the business envi-
ronment, continuous improvement, and breakthroughs with development,
improvement, and maintenance cycles while changing organizational culture.™™
(From the Web site of Integrated Quality Dynamics, Inc.)

Vendor “ A person or company that provides a product or line of products to
a Speci¬cation that is usually his own.

Version Description Document (VDD) “ A document that references and
describes the changes included in this version of software.

Vision “ The highest view of what a company is and where it wants to go.

Work Breakdown Structure (WBS) “ A WBS is a description of the project/
program in tree form. It is composed of the hardware, software, services, and
data that completely de¬ne a project/program.
Work Package (WP) “ The lowest level of the WBS that is the most ef¬cient
and cost-effective way of controlling schedule, cost, and technical performance
consistent with the requirements of the customer and the performing agency

(the company).
This Page Intentionally Left Blank

Attachment 1”Standard Program Plan Outline
Attachment 2”Standard Technical Plan Outline
Attachment 3”Risk Mitigation Plan
Attachment 4”Contract/Subcontract Outline
Attachment 5”Con¬guration Management Plan Outline
Attachment 6”Quality Assurance Plan Outline
Attachment 7”Requirements Traceability Matrix
Attachment 8”Requirements Flow-Down Matrix
Attachment 9”Data Delivery Matrix
Attachment 10”Capability Matrix
Attachment 11”Policy-to-Plan Trail
Attachment 12”Experience Window
Attachment 13”Standards Traceability Matrix
Attachment 14”Vendor Evaluation Process
Attachment 15”Design Review Approval Form
Attachment 16”In-Process Review Approval Form
Attachment 17”Negotiation Checklist
Attachment 18”Critical Success Factor (CSF) Matrix

This Page Intentionally Left Blank


The Program/Project Plan is one of the most important documents you will
create to manage a project or program. The outline of the plan should be consis-
tent from project to project. Obviously, the content of much of the plan will
vary from project to project, but some of the content will also be consistent.
Which is which should be a part of the enterprise policies that drive such plans.
Following is a suggested outline you can use to generate your ¬rst Project or
Program Plan, even if you don™t have an enterprise policy to drive it. Over time,
you will ¬nd which parts of the plans are constant and which change. By using
a word processing application you can create a new plan very quickly. This is
particularly helpful in bidding new projects or programs. Start with the outline
below and change it to ¬t your needs.

.......................... 9758$$ ATT1 12-09-02 08:30:54 PS




1 Introduction
2 Scope
2.1 Program Description
2.2 Deliverables
2.3 Schedule
2.4 Sell-Off Criteria
3 Applicable Documents
3.1 Contract
3.2 Customer Documents
4 Unusual Contract Clauses
5 Management
5.1 Organization and Responsibilities
5.1.1 General
5.1.2 System Management
5.1.3 Subcontracts and Materials
5.1.4 Data Management
5.1.5 Con¬guration Management
5.1.6 Quality Assurance
5.1.7 Team Members and Alliances
5.1.8 Training
5.2 Make/Buy Decisions
5.3 Safety
5.4 Security
5.5 Facilities
5.6 Standardization

5.7 Program Risks
6 Program Controls
6.1 Cost and Schedule Controls
6.2 Communication Control
6.3 Status Meetings
6.4 Design Reviews
6.5 Speci¬cation Control
6.6 Documentation Control
6.7 Customer Furnished Property Control
6.8 Action Items
6.9 War Room
7 Schedule
8 Requirements Flow-Down
9 Work Breakdown Structure (WBS)
10 Project Work Authorization
11 Technical Approach
12 Training
13 Packing and Shipping
14 Delivery
15 Field Operations
16 Operations and Maintenance
1 Capital Management Plan
2 Communication Control Plan

3 Con¬guration Management Plan
4 Data Management Plan
5 Delivery Plan
6 Facility Plan
7 Field Plan
8 Customer-Furnished Property Plan
9 Make or Buy Plan
10 Subcontract and Material Management Plan
11 Operations and Maintenance Plan
12 Packing and Shipping Plan
13 Project Work Authorizations
14 Quality Control Plan
15 Requirements Flow-Down Plan
16 Risk Mitigation Plan
17 Safety Plan
18 Schedule
19 Security Plan
20 Small Business Plan
21 Standardization Plan
22 Test Plan
23 Training Plan
24 Engineering Plan
25 Transition Plan
26 Manufacturing Plan
27 Sell-Off Plan


Because the purposes of companies vary widely, their Technical Plans will vary
widely as well. Once established within an enterprise however, the outline and
purpose of the Technical Plan will be relatively constant. The content will, of
course, change from project to project.
The basis of the following Technical Plan Outline is MIL-STD-490. It is pur-
posely comprehensive. Start with this outline and modify it to your needs.


.......................... 9758$$ ATT2 12-09-02 08:30:56 PS


Part I”Technical Planning and Control
Paragraph Title
1.0 Organization
1.1 Objectives
1.2 Responsibilities
1.3 Authority
2.0 Decision and Control Process
3.0 Con¬guration Management
3.1 Hardware
3.2 Software
3.3 Documentation
4.0 Review Process
4.1 Design Reviews
4.2 Subcontractor Reviews
4.3 Design Approval and Certi¬cation
5.0 Continuous Acquisition and Logistic Support (CALS)
6.0 System Test Planning
7.0 Technical Performance Management
Part II”System Engineering Process
Paragraph Title
1.0 Technical Strategy
2.0 Functional Analyses
3.0 Requirements Allocation
4.0 Generation of Speci¬cations
5.0 Alternative Designs
6.0 Trade-offs
7.0 Synthesis

Part III”Specialty Engineering Plans
Plan Title
1.0* Concept of Operation
2.0* Con¬guration Management Plan
3.0 Contamination and Corrosion Control Plan
4.0 EMI/EMC Plan
5.0* Engineering Plan
6.0 Environmental Engineering Plan
7.0† Hardware Development Plan
8.0 Human Engineering Plan
9.0 Logistic Support Analysis (LSA)
10.0 Mantainability Plan
11.0 Manufacturing Management Plan
12.0 Mass Properties Control Plan
13.0 Packaging, Handling, Storage, and Transportation Plan
14.0 Parts, Materials, and Process Control Plan

15.0 Producibility Plan
16.0 Production Engineering Plan

17.0* Quality Plan
18.0* RMA Plan
19.0 Requirements Plan
20.0 Safety Plan
21.0 Security Plan
22.0† Software Development Plans and Standards
23.0† Software Quality Plan
24.0 Standardization Plan

*Subplans, in addition to the Program Plan and Technical Plan, that should always
be a part of the proposal or at least be completed at the time of the proposal. Other
plans may also be a part of the proposal based on the nature of the requirement.
†Subplan to be included with the above dependent on the output product.

25.0* System Test Plan
26.0* Technical Data Management Plan
27.0* Technical Performance Measurement Plan
28.0* Technical Risk Management Plan
29.0 Value Engineering Plan
30.0 Vulnerability/Survivability Plan
31.0 Weight Control Plan

*Subplans, in addition to the Program Plan and Technical Plan, that should always
be a part of the proposal or at least be completed at the time of the proposal. Other
plans may also be a part of the proposal based on the nature of the requirement.


The Risk Mitigation Plan provides direction and control for the identi¬cation,
documentation, correction methodology, and closure of risks on the program.
Risk Management is an organized, systematic decision-making process de-
signed to identify, analyze, plan, track, control, and document each and all risks
to increase the probability of achieving project goals. Risks are events that may
or may not impact the cost, schedule, or technical quality of the project and
Risk management is the responsibility of everyone on the team. It implies
control of possible future events and is proactive rather than reactive. There are
four elements of the risk management process.

1. Risk Identi¬cation. Potential risks must be identi¬ed and managed. Once
identi¬ed, risks are entered into a Risk Mitigation Form as in Figure A3-1


.......................... 9758$$ ATT3 12-09-02 08:30:59 PS

Figure A3-1 ” Risk Mitigation Form


Risk Priority Date Date
No. Opened Closed

Risk Description

Source of Risk (i.e., SOW, Para X.X)

Mitigation Plan

Cost Exposure

Cost of Mitigation

Expected Date of Occurrence

Application of Mitigation Funds (dates & amounts)

Closure Authority:
Program Manager System Manager

M-M Form F-04028-1

and then into a Risk List as in Table A3-1. Risk identi¬cation is an element
of the process that continues throughout the lifetime of the project.
2. Risk Assessment. Each risk must be characterized as to the likelihood (proba-
bility) of its occurrence (Po) and the severity of the potential consequences
(So). When the assessments are made, the characteristics of the risk are docu-
mented in the Risk List.
3. Risk Disposition. Each risk must be assigned to an individual designated as
the risk manager for that risk (this will likely involve a number of different
people). Once a risk has been assessed, the project team must consider how
to handle it. Alternatives include:
Avoidance. Avoidance is best accomplished during the bid or negotiation
process. Once the project has started, avoidance is dif¬cult to accomplish.

Ta b l e A 3 - 1 ” R i s k L i s t

Risk No. Risk Resp Po* So* Priority (Po So) Status
P-001 System Weight Smith .6 .8 .48 In Proc
P-002 Deceleration Jones .5 .5 .25 In Proc
P-003 Rxo BER Nacker .3 .4 .12 In Proc

Because this is the best method of risk mitigation, it should not be summarily
dismissed, however. Consider alternative architecture, design, or project ap-
proaches that would avoid the incidence of this risk altogether.
Transfer. It may be possible to transfer a risk to a subcontractor or to a
third party such as an insurance agency. In the ¬nal analysis, however, the
program team is still ultimately responsible for the risk.
Sharing. When the risk cannot be appropriately transferred”and when it
is not in the best interest of the program team to assume the risk”the risk
may be shared with the customer, a subcontractor, or a third party. Such
shared risks require extensive monitoring. Risk sharing with the customer is
quite common in Research and Development (R&D) contracts. Sharing is
implemented through both cost sharing, such as cost plus contracts or ar-
rangements, and pro¬t sharing, such as award fee or incentive fee provisions.
Risk sharing with the subcontractor is accomplished in the same way. Risk
sharing with a third party such as an insurance or bonding company is sim-
ply sharing of the cost outcome. These share situations are rare.
Assumption. When all the other alternatives have not been successful, the
only option left is to assume the risk. Once the risk has been directly as-
sumed, the issue of mitigation becomes your full responsibility. This state-
ment means that the intensity of mitigation will increase signi¬cantly. The
assumption of the entire risk will require a full plan to approach and neutral-
ize or at least mitigate the risk.
4. Risk Tracking. Once a risk has been identi¬ed, as stated in Step 1, it must be
entered into the Risk List. Every risk in the Risk List must be documented in
a Risk Mitigation Form.
The size, content, and intensity of Risk Mitigation will increase as you
progress further down the process steps and as the Priority (Po So) in-

creases. Constant vigilance and status reporting must be maintained on each
risk throughout its lifetime. Some risks will require monthly attention while
others will require daily or even hourly attention.

Additional references that may contribute to developing your plan are:

DoD Directive Dir 5000.2R, paragraph 3.3.3.


Every contract and subcontract should consider the same issues. The contents
of each should be approximately the same. If you do not have an enterprise
policy or procedure to cover this situation, consider the following outline.
Order is not terribly important, but content is.

’ Supplies/Services Prices/Costs
’ Schedule
’ Statement of Work containing:
• Task Description
• Deliverable Documents List (sometimes called Contract Data Require-
ments List or CDRL)
• Period of Performance

.......................... 9758$$ ATT4 12-09-02 08:31:00 PS

• Schedule
• Reference Documents
• Modifying Factors (for instance, the number of labor hours of speci¬c
disciplines that must be provided)
’ Speci¬cation containing:
• Scope of the Document
• Applicable Documents
• Requirements
• Item De¬nition
• Performance Characteristics
• Physical Characteristics
• The major components of the principal item and the primary interfaces
between such major components and other items with which it must be
• Quali¬cation Requirements (for software) or Quality Assurance Provi-
sions (for hardware)
• Process Requirements, if needed
• Materials Requirements, if needed
’ Interface Control Document
’ Packaging and Marking
’ Inspection and Acceptance
’ Delivery or Performance
’ Contract Administration Data
’ Special Contract Requirements
’ Contract Clauses
’ Representations and Certi¬cations
’ Attachments
’ Contract/Subcontract Data Requirements List (CDRL or SDRL)
’ Special Attachments

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.
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.
There are several types of speci¬cations. MIL-STD-490 has established and
de¬ned ¬ve major speci¬cation (Spec) types as well as a number of subtypes.
The standard provides a great deal of good information regarding the content
and purpose of each speci¬cation type. The speci¬cation types are shown in
Table A4-1.

Ta b l e A 4 - 1 ” S p e c i f i c a t i o n Ty p e s

Type Speci¬cation
A System/Subsystem/Segment
B Development
B1 Prime Item
B2 Critical Item
B3 Non-complex Item
B4 Facility of Ship
B5 Software
C Product
C1a Prime Item Function
C1b Prime Item Fabrication
C2a Critical Item Function
C2b Critical Item Fabrication
C3 Non-complex Item fabrication
C4 Inventory Item
C5 Software
D Process
E Material


. 7
( 9)