<<

. 8
( 9)



>>



Additional Resources:

MIL-STD-245
AT TAC H M E N T 5




CONFIGURATION
MANAGEMENT PLAN
OUTLINE


1. INTRODUCTION

Purpose, scope, and a brief description of the system at top level, a description
of the plan™s major features and objectives, and a concise summary of your
approach to CM (Con¬guration Management).

2. REFERENCE DOCUMENTS

Refers to speci¬cations, standards, manuals, and other documents.

3. ORGANIZATION

The organization with emphasis on the CM activities including responsibility
and authority for CM of all groups and organizations including their role in
234




.......................... 9758$$ ATT5 12-09-02 08:31:02 PS
CONFIGURAT ION MANAGEMENT PLAN OUTLINE 235


con¬guration control boards and the interfaces between the CM organization
and outside organizations.

4. CONFIGURATION MANAGEMENT PHASING AND
MIL ESTONES

The sequence of events and milestones for implementation of CM in phase
with major program milestones and events. The establishment of con¬guration
control boards and the conduct of con¬guration audits.

5. DATA MANAGEMENT

The methods for meeting the CM technical data requirements.

6 . C O N F I G U R ATI O N I D E N T I F I C ATI O N
Y
The identi¬cation of the Hardware Con¬guration Items (HWCIs) and Com-
puter Software Con¬guration Item (CSCIs).
FL
AM


7. INTERFACE M ANAG EMENT

The procedures for the establishment of interface agreements.
TE




8. CONFIGURATION CONTROL

The responsibilities and authority of your con¬guration control board, the clas-
si¬cation of changes, and the level of authority for change approval/concur-
rence.

9. CONFIGURATION STATUS ACCOUNTING

The procedures for collecting, recording, processing, and maintaining CM data.

10. CONFIGURATION AUDITS

The approach to plans, procedures, documentation, and schedules for func-
tional and physical con¬guration audits and the format for reporting results of
in-process con¬guration audits.
BLUEPRINT FOR PROJECT RECOVERY
236


11. SUBCONTRACTOR/VENDOR CONTROL

The methods you will use to ensure subcontractor/vendor compliance with con-
¬guration management requirements.
The above outline is a condensed version of the table of contents advocated
in MIL-STD-973. Source: www.edms.redstone.army.mil/edrd/973appa.html

Additional References:

MIL-STD-973
MIL-HDBK-61
EIA 649
ISO-10007

See: www.cmiiug.com/Standards.htm for additional information.
AT TAC H M E N T 6




QUALITY ASSURANCE PLAN
OUTLINE




PROGRAM


Q U A LI T Y A S S U R A N C E PLA N

1. QUALITY MANAGEMENT

1.1 Q UAL I T Y P O L I C Y

The purpose of this Quality Assurance Plan is to detail the quality assurance
principles and to establish the structure of the Program quality assurance
237




.......................... 9758$$ ATT6 12-09-02 08:31:05 PS
BLUEPRINT FOR PROJECT RECOVERY
238


program consistent with Company Quality Assurance Policies and the
Company Quality Assurance Plan.

1.2 QUALITY OBJECTIVES

The following quality principles are intended to be consistent with Com-
pany quality policies and plans.

’ All measurements will include quantitative determinations.
’ Methods will be consistent.
’ Measurements will be linked to a standard value.

1.3 RESPONSIBILITIES AND AUTHORITY.

The Program Quality Assurance Representative is responsible for the
day-to-day implementation of the Program Quality Assurance Program, in-
cluding documenting all data and identifying out-of-tolerance situations.

2. STRUCTURE OF QUALITY SYSTEMS

2.1 QUALITY ORGANIZATIONAL STRUCTURE

The Company Quality Assurance Director reports directly to the Vice
President/General Manager.
The Program Quality Assurance Representative reports operationally to
the Program Program Manager and functionally to the Company Qual-
ity Assurance Director.

2.2 RESOURCES AND PERSONNEL

Each participant in Company shares responsibility for achieving the
quality objectives. Therefore, portions of the program™s budget are allocated to
the quality assurance function as it relates to and supports the Program .

2.3 OPERATIONAL PROCEDURES

The Program Quality Assurance Plan will include a Program Quality
Control Plan that outlines the speci¬cs of controlling product quality on the
Program .
QUALITY ASSURANCE PLAN OUTLINE 239


2.4 QUALITY MANUAL AND RECORD KEEPING

The Quality Assurance Representative is responsible for maintaining quality
assurance records during the conduct of all phases of the Program .

2.5 THE PROGRAM QUALITY ASSURANCE PLAN WILL
BE UPDATED AS REQUIRED

Each update will be treated as an original plan and shall follow the same
authorization path. The Program Quality Assurance Plan shall be updated
as necessary to incorporate any new or updated changes found necessary to the
Company Quality Assurance Policies, Plans, or Procedures.




QUALITY CONTROL PLAN


The Quality Control Plan, in conjunction with Company Policy ( M-M
Policy 07000 Series), provides direction, control, and authorization for the
overall quality control of equipment and data on the Program Program.




SUGGESTED OUTL INE


1. Introduction
2. Scope
3. Applicable Documents
4. Management Organization
5. Quality System Planning
6. Contract Review
7. Design Control
8. Document Control
9. Purchasing
BLUEPRINT FOR PROJECT RECOVERY
240


A. Purchaser Supplied Products
B. Product Identi¬cation and Traceability
10. Process Control
A. Inspection and Testing
B. Inspection, Measuring, and Test Equipment
C. Inspection and Test Status
D. Control of Non-Conforming Product
E. Corrective Action
11. Handling, Storage, Packing, and Delivery
12. Quality Records
13. Quality Audits
14. Training
15. Servicing
16. Statistical Techniques
17. Quality System Effectiveness Factors

Additional Notes:

’ There is usually considerable overlap between Con¬guration Manage-
ment (CM) plans, Data Management (DM) plans, and Quality plans of
all levels (i.e., Quality Assurance and Quality Control).
’ The above Quality Assurance Plan and Quality Control Plan are excerpts
from the Modern-Management Policies, Plans, and Processes presented
in the Strategy for Success workshops. To that end, words that appear in
angle brackets ( ) are part of a ˜˜global™™ update (i.e., ˜˜Find and Re-
place™™) process that allows the users to enter their speci¬c data through-
out the plans.

Additional references that may contribute to developing your plan are:

Data Item Description: DI-QCIC-81379
ANSI/ASQC Quality Standards Q91 and Q92
ISO 9001 and 9002
MIL-Q-9858 and MIL-I-45208 (both for reference only)
MIL-STD-2167 AND 2168
AT TAC H M E N T 7




REQUIREMENTS
TRACEABILITY MATRIX


One of the best methods of generating entries for the Requirements Traceability
Matrix (RTM) is to conduct a ˜˜shalls™™ review and use those results as require-
ment entries in the RTM. If you have not accomplished this task before, don™t
worry. It is rather simple nowadays with the ˜˜¬nd™™ function on most word
processing programs. There are, of course, applications dedicated to pulling
˜˜shalls™™ and ˜˜wills™™ from requirements documents and creating an RTM for
you. If you use one of these programs, don™t trust it completely. Although they
are quite good, they do make mistakes in judgment. It™s up to you to ensure
that the RTM is complete and accurate.
The U.S. Army de¬nes traceability as:

The capability to track system requirements from a system
function to all elements of the system which, collectively or in-
241




.......................... 9758$$ ATT7 12-09-02 08:31:08 PS
BLUEPRINT FOR PROJECT RECOVERY
242


dividually, perform the function; an element of the system to
all functions which it performs; a speci¬c requirement of the
source analysis or contractual constraint which originated the
requirement. Traceability includes tracking allocation design
(and technical program) requirements through the work break-
down structure between the system level and the lowest level of
assembly.*

Most requirements documents, including SOWs and speci¬cations, contain
statements that follow the general convention of ˜˜The system shall . . . . . .™™
These are referred to as ˜˜shalls™™ and, in some cases, ˜˜musts™™ that constitute the
core requirements of the system. Care must be taken to evaluate the use of the
words ˜˜will™™ and ˜˜should™™ by the document creator. In some cases, ˜˜wills™™ or
even ˜˜shoulds™™ are treated the same as ˜˜shalls™™ while in other cases ˜˜shalls™™ are
mandatory and ˜˜wills™™ are optional. If the word ˜˜goal™™ shows up, try to get it
quanti¬ed. I assure you that your interpretation of a goal will be different than
the customer™s interpretation of it.
To ensure that your system or product is exactly what the customer has
speci¬ed, conduct a ˜˜shalls™™ and ˜˜wills™™ search, and place the results in an
RTM. The usual convention is to place the reference paragraph on the far left
and the requirement in the next column. Further columns trace the requirement
through your system following the way your company does business and the
nature of the output product. The concept, however, is the same regardless of
methodology or product.
You can create and print forms for this purpose or you can use a spreadsheet
application such as Excel or Lotus to accomplish the same purpose. To start the
process, use your word processing program such as MS Word or MS Works or
MacWrite or a similar program to search for the ˜˜shalls™™ and ˜˜wills.™™ When
you ¬nd one, simply copy and paste and include the paragraph number. If your
programs are compatible, such as MS Of¬ce, it is a simple matter to transfer
the entries from the word processing program to the spreadsheet program.
Be cautious in the construction of your RTM. Don™t necessarily limit it to
˜˜shalls™™ and ˜˜wills.™™ If you customer has some other way of stating mandatory
and lesser requirements, that is certainly the convention to follow.
The point and purpose of an RTM is to trace a requirement from its begin-

*U.S. Army Field Manual (FM), 770“778.
REQUIREMENTS TRACEABILITY MATRIX 243


ning in the requirements document (contract) to its ¬nal proof, such as the
System Test. There must be enough detail in the RTM to point immediately to
the place, paragraph, table, etc., where the requirement is allocated.
You should assign each requirement to a monitor. The monitor should be
listed in a column in the RTM. You may assign more than one requirement to
a person but don™t simply assign all requirements to the chief engineer. Show
the actual person responsible for that requirement.
In general, your RTM should look similar to Table A7-1.

Ta b l e A 7 - 1 ” 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




The same concept and organization can be applied to a Subcontract Require-
ments Traceability Matrix (SRTM) and used by your subcontractor.
For a small project, you can use a spreadsheet program. For a larger program
you can use a spreadsheet ˜˜workbook™™ with requirements in one sheet, WBS
information on the second sheet, etc. You can then link the cells together with
hyperlinks from a master sheet to form a thread of information for each re-
quirement.
You can also do the same thing with a Relational Data Base (RDB). The RDB
will require more up-front time but will result in a more cohesive product.
The current industry standard is a family of products titled DOORS (for
large and enterprise wide projects) and DOORSrequireIT (for smaller projects).
Both are commonly referred to as ˜˜Doors.™™ Doors is available from:

Telelogic DOORS North America
400 Valley Road, Suite 200
BLUEPRINT FOR PROJECT RECOVERY
244


Mt. Arlington, NJ 07856
Phone: 949-830-8022
Fax: 949-830-8023
To order: 877-275-4777
E-mail: doorssupport.us@telelogic.com
Web site: www.telelogic.com/doors
AT TAC H M E N T 8




Y
REQUIREMENTS FLOW-
FL
DOWN MATRIX
AM
TE




You can look at a Requirements Traceability Matrix (RTM) as a horizontal
function and a Requirements Flow-Down Matrix (RFM) as a vertical function.
The RTM traces where a requirement appears in the overall process while the
RFM shows where a requirement has been allocated. Both apply to both prime
and subcontractors. The subcontractor versions are usually preceded with an
˜˜S™™ for differentiating between the two.
If you do not have a Requirements Flow-Down Matrix (or Plan), you can
use Table A8-1 as a start. Modify the table for your own needs. Just be sure to
not change the concepts of content and ¬‚ow.
In the case of the RFM, there are two levels or sets of requirements to be
¬‚owed down. The ¬rst is the requirement from the customer as contained in
245




.......................... 9758$$ ATT8 12-09-02 08:31:09 PS
BLUEPRINT FOR PROJECT RECOVERY
246


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




the SOW or speci¬cation. The second is a requirement demanded by enterprise
policy.
In some cases, a requirement may be ¬‚owed down to one subcontractor and
not another. Observe Spec Para Requirement 1.3.3 in the table cross-referenced
to Subcontractor B. Such requirements could be those that are product-speci¬c;
perhaps Subcontractor A provides that kind of product but Subcontractor B
does not.
AT TAC H M E N T 9




DATA DELIVERY MATRIX



Some tool is necessary to compile data delivery requirements from the require-
ments document (contract), put them in a common place, and assign word
dates and delivery dates and responsibilities. The Data Delivery Matrix is a sim-
ple and effective tool for accomplishing this overall purpose and providing a
central location of past activities as well. A Data Delivery Matrix can be created
by using a spreadsheet such as the one shown in Table A9-1. The columns can
be extended to the right for multiple deliveries or the right column can be
updated periodically as necessary.
If your data manager is so inclined and so talented, a Relational Data Base
(RDB) such as Access can be used to do the same thing as the matrix in Table
A9-1. The RDB takes more time to set up in the beginning but will save time
and possibly mistakes in the long run. If the RDB is used, set the report format
so that at least the ˜˜Data™™ column, the ˜˜Frequency™™ column, the ˜˜Next Due™™
247




.......................... 9758$$ ATT9 12-09-02 08:31:17 PS
BLUEPRINT FOR PROJECT RECOVERY
248


Ta b l e A 9 - 1 ” D a t a D e l i v e r y M a t r i x

Doc No Title Resp. Format First Del Frequency
A-0001 Monthly Progress Jones DID 1234 30 days Monthly
Report ARO1
T-0001 System Test Smith DID 2345 System Test minus One time
Package 30 days
T-0002 System Test Harris DID 4567 System Test plus One time
Results 30 days
ARO: After Receipt of Order.
1




column, and the ˜˜Responsibility™™ column are shown in the report format. Usu-
ally, the Data Delivery Matrix is routed frequently to all responsible individuals
as well as being posted in a central location in a ˜˜paper™™ program. On a ˜˜paper-
less™™ program the Data Delivery Matrix is provided on the Program Web site.
It is also useful to identify a cognizant individual (project manager, chief
engineer, engineer, etc.) associated with each ˜˜X.™™ These people can act as inter-
nal experts (consultants) during the execution of your project.
AT TAC H M E N T 10




CAPABILITY MATRIX



The purpose of the Capability Matrix is to evaluate your past experience against
current requirements and thus reveal the level of capability you have to perform
the current requirement. By default, the Capability Matrix will reveal those areas
of requirements (tasks) where you do not have capability and must either buy
the capability (includes hiring knowledgeable personnel), develop the capability,
no-bid the task or requirement, or take a risk in performing the task or require-
ment.
The Capability Matrix either feeds or is fed by the Experience Window (see
Attachment 12) and/or the Risk List (see Attachment 3).
Create a matrix similar to the one shown in Table A10-1 and list all the
requirements or tasks (this includes the contents of referenced documents as
well as explicitly included documents) along the side and the programs (includ-
ing IR&D programs) that the enterprise has performed across the top. Every

249




.......................... 9758$$ AT10 12-09-02 08:31:17 PS
BLUEPRINT FOR PROJECT RECOVERY
250


Ta b l e A 1 0 - 1 ” C a p a b i l i t y M a t r i x

Project A Project B Project C Project D Project E Project F
Task 1 X
Task 2 X X X
Task 3
Task 4 X
Task 5 X X
Task 6 X
Task 7 X
Task 8 X X
Task 9



requirement or task should have an ˜˜X™™ at the intersect with at least one pro-
gram. If not, continue with the process to try to bring the requirement to within
your capabilities.
AT TAC H M E N T 11




POLICY-TO-PLAN TRAIL



A Policy-to-Plan trail is necessary to ensure that the policies required by the
enterprise are incorporated into the Project Plan and the Technical Plan. After
the ¬rst use, this document can be set aside if you create your own Project Plans
and Technical Plans. Incorporate the required policies into the respective plans,
together with a reference back to the policy. Mark, in your own way, those
paragraphs as standard and use them for all subsequent projects and programs.
If you do not have a Policy-to-Plan Process, you can use Table A11-1 to start
your process.
Once developed, the Policy-to-Plan Table can be used as an input document
to the Standards Traceability Matrix (STM) (see Attachment 13).
The numbers appearing in the policy column re¬‚ect the enterprise policy
number. The numbers appearing in the plan columns re¬‚ect the paragraph
number of the plan where the policy is invoked.
251




.......................... 9758$$ AT11 12-09-02 08:31:18 PS
BLUEPRINT FOR PROJECT RECOVERY
252


Ta b l e A 1 1 - 1 ” P o l i c y - t o - P l a n Ta b l e

Policy Project/Program Plan Technical Plan
11011-Startup 4.1.1 2.1.1
11013-Funding 5.1.2
11024-PWA 6.2.2 4.3.2
11025-Work Packages 6.2.3 4.3.3
11027-Performance Measurement 7.4.4 5.4.3
11041-Program Reviews 8.2.2 6.2.3
11044-Action Items 9.1.1 7.2.2
15012-In-Process Reviews 6.2.4
15026-Engineering Drawings 8.1.1
15033-Speci¬cations 9.2.2
AT TAC H M E N T 12




EXPERIENCE WINDOW



The purpose of the Experience Window is to provide a quick check of your
experience and evaluate that experience against your capability to perform a
particular task. This is particularly important if you are in the process of bidding
a task. It can also be used as the ¬rst step in determining whether you should
seek additional capability in order to perform a task you already have. Table
A12-1 shows the inputs for the Experience Window.
If you determine you do not have the experience, the next step is to use the
Capability Matrix to re¬ne your needs. A sample Capability Matrix is shown in
Table A12-2 and described in Attachment 10 with further information provided
in Cause Description 1b and 1b (NO).




253




.......................... 9758$$ AT12 12-09-02 08:31:26 PS
BLUEPRINT FOR PROJECT RECOVERY
254


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




Ta b l e A 1 2 - 2 ” C a p a b i l i t y M a t r i x

Project A Project B Project C Project D Project E Project F
Task 1 X
Task 2 X X X
Task 3
Task 4 X
Task 5 X X
Task 6 X
Task 7 X
Task 8 X X
Task 9
AT TAC H M E N T 13




STANDARDS TRACEABILITY Y
FL
MATRIX
AM
TE




The ¬rst question you may ask is: ˜˜What is the relationship between a Require-
ments Traceability Matrix (RTM) and the Standards Traceability Matrix
(STM)?™™ The fact is that they both accomplish the same purpose but for differ-
ent kinds of requirements. The STM traces standards that are common to the
industry, the customer, and the enterprise. The RTM tracks SOW and speci¬-
cation requirements that are unique (although some may be common) to this
task.
The purpose of the STM is to ˜˜track™™ a standard that is common to the
industry or required by the customer or the enterprise into the Program Plan
and/or the Technical Plan. The matrix shown below is a typical and easy way of
conducting this exercise. To develop this matrix, you can use a spreadsheet or a
Relational Data Base (RDB). The spreadsheet method is easy and quick but can
lead to some confusion because of duplication or overlap. The RDB is more

255




.......................... 9758$$ AT13 12-09-02 08:31:26 PS
BLUEPRINT FOR PROJECT RECOVERY
256


dif¬cult to create but always maintains the same relationships to other require-
ments.
The matrix in Table A13-1 is a multipurpose matrix in that the Industry,
Customer, and Enterprise Standards Documents are all included in one chart.
You can use this technique or separate them into three different charts. The
advantage of using three charts is that Industry and Enterprise charts will proba-
bly 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 in one place.
Before the project starts, you should have a Standards Appearance Matrix
already established for all the known standards and enterprise documents that
drive the Project and Technical Plans. This is frequently a staff function and
might appear in one of your enterprise policies. If it does not, build your own.
There should be plenty of blank rows in the standard to work with. Use the
blank rows to enter the requirements speci¬c to your task. Your requirements
document (contract) will drive the entries in the customer column. Ensure that
every necessary standard is covered. In the sample matrix above, notice that, in
the second entry, a customer document and an enterprise document are side-
by-side. That™s because they are the same requirement. It is common for a com-
pany to absorb standard requirements for their areas of operation as standard
policies within the company. If you use a multipurpose matrix and the stan-
dards are common, include them both on the same row. If any requirement
exists in any column, ensure that it is covered.
You can clearly see the relationship between the Enterprise Policies, Plans,
and Processes and the various paragraphs of the Program/Project Plan in Figure
A13-1. Further, the ¬gure shows the relationship between Attachments and Ap-
pendices to the Program/Project Plan and the paragraphs of the Program/Proj-
ect Plan as well as the Enterprise Policies, Plans, and Processes.

Ta b l e A 1 3 - 1 ” 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
STANDAR DS TR ACEABILITY MATR IX 257


Figure A13-1 ” Policy-to-Program Plan to Support Document Flow


Enterprise Policies, Attachs &
Plans, & Processes Program Plan Appeds
1 Introduction
2 Scope
2.1 Program Description
C
2.2 Deliverables
18
2.3 Schedule
27
M-M 04018 2.4 Sell-off Criteria
3 Reference Documents
3.1 Contract
3.2 Customer Documents
4 Unusual Contract Clauses
5 Responsibilities
5.1 Organization, Staffing, and Responsibilities
5.1.1 General
M-M 05000 5.1.2 System Management
20
M-M 06000 5.1.3 Subcontracts and Materials
4
M-M 04050 5.1.4 Data Management
3
M-M 04030 5.1.5 Configuration Management
14
M-M 07000 5.1.6 Quality Assurance
15
M-M 10050 5.1.7 Team Members and Alliances
23
M-M 11000 5.1.8 Training




This matrix should be built for the entirety of the Program/Project Plan and
another should be constructed for the Technical Plan.
The symbol M-M refers to my company Modern-Management and is a part
of the ¬le database for all writings, workshops, and seminars. You need to enter
your company policies, processes, etc., in this column.
I sincerely hope you are reading this Cause Description before your program
starts rather than trying to recover from a problem. This is a time-consuming
process, but is necessary for a smooth-running program.
If you have built your Project or Program plan according to the recommen-
dations of this book, all but the left-most column will be apparent. It should
then be a simple matter to insert your company plans into the left-most column.
If you have your own outline for a Project or Program Plan, you will need
to start from scratch. The mechanics, however, are the same.
Once you receive your contract, you can begin referencing the elements of
the contract to the outline of the Project Plan and the Technical Plan.
AT TAC H M E N T 14




VENDOR EVALUATION
PROCESS



Several things need to be said about vendors. First, they are very important to
a lot of businesses. Perhaps they are important to your business as well. Second,
you should have a broad and deep supply of vendors you can rely upon to
provide products for your projects. Third, a central ¬le should be kept on all
vendors who deal with your company. The central ¬le should contain perform-
ance histories of each vendor and, hopefully, a quality process to quantify the
vendor™s performance. Fourth, you should have an evaluation process to evalu-
ate and reevaluate each vendor for each procurement for each project. It is the
fourth item that this process is all about.
For each procurement, establish an evaluation scheme before the Request for
Proposal (RFP) or Request for Quotation (RFQ) is released. Decide on what is
most important: cost, schedule, technical, etc. Then weight the evaluation
scheme so that it will evaluate each vendor™s response fairly and equally. Create

258




.......................... 9758$$ AT14 12-09-02 08:31:26 PS
VENDOR EVALUAT ION PROCESS 259


an evaluation team with specialists in each of the areas to be evaluated (manage-
ment, engineering, materials, quality, etc.). When the vendor™s proposals are
received, begin the evaluation process.
Each specialty area”management, engineering, materials, quality, etc.”
should have a sheet for each similar to the Vendor Evaluation Sheet shown in
Figure A14-1 on page 260. The factors in each sheet will change with the spe-
cialty area and will be consistent with the overall evaluation scheme devised
before the RFP/RFQ was issued and documented by the materials or subcon-
tracts manager in a cover letter to all evaluators.
The materials or subcontracts manager will order and stack the Vendor Eval-
uation Forms as they come in and enter the results for each vendor in the
Vendor Evaluation Summary Form as shown in Figure A14-2 on page 261.
Finally, the results from the Vendor Evaluation Summary Form will be trans-
ferred to the appropriate lines on the Vendor Selection Summary Score Sheet
as in Figure A14-3 on page 262. The winner is determined from the Vendor
Selection Summary Score Sheet.
BLUEPRINT FOR PROJECT RECOVERY
260


Figure A14-1 ” Vendor Evaluation Sheet

VENDOR EVALUATION

4-Jul-02
Date

High-Flyer
Program

National Software
Subcontractor/Vendor

Analog Selction Algorithm
Equipment/Software

G. Smith
Evaluator

0-5
Scale Factor


Item Consideration Rating*


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


M-M Form
VENDOR EVALUAT ION PROCESS 261


Figure A14-2 ” Vendor Evaluation Summary

VENDOR EVALUATION SUMMARY

Date

Program

Subcontractor/Vendor

Equipment/Software


Item Consideration Scale Rating*


1 Technical 0“25 10
2 Management 0“5 2
3 Quality 0“15 7
4 Procurement 0“5 3
5 Financial 0“10 5
6 Delivery 0“20 10
7 Cost 0“20 10
8
9
10
Subtotal 47
No. of items rated 7
Average of ratings (Subtotal/No of items) 6.7


Current Quality Vendor survey on ¬le? Yes
D&B on ¬le? Yes

*From Vendor Evaluation Sheets
BLUEPRINT FOR PROJECT RECOVERY
262


Figure A14-3 ” Vendor Selection Summary Score Sheet

VENDOR SELECTION SUMMARY SCORE SHEET

SCORE SHEET FOR: *

Date Item




EVALUATION CONSIDERATIONS (POINT ALLOCATION 100)

Vendor Name Score
1.
2.
3.
4.
5.

Total (Sum of Points Given)

Score (Total/No. of Entries)

Comments:

Comments:


You should have a Vendor Evaluation Summary Score Sheet for each of the operating elements of the team
(Engineering, Management, QA, etc.) and each of the factors of the procurement (cost, delivery, etc.). This
form is the summary, by evaluator, of all the previous forms.


This form can be modi¬ed and used to evaluate subcontractor and vendor proposals. In that case, establish
a ˜˜weighting™™ for each of the factors based on your program (e.g., Is technical more important than cost?)


*Operating element or factor, such as: Technical, Management, QA, Procurement, Cost, Delivery, etc.




M-M Form F-06013A
AT TAC H M E N T 15




DESIGN REVIEW APPROVAL
FORM



The Design Review Approval Form in Figure A15-1 is used to document the
completion of all the elements of a design review. While you may have docu-
mented each of the elements (i.e., Design Review Package, Design Review, etc.)
individually, it is a good idea to have one form where all the elements are
recognized and approved. This will come in handy when you are assembling all
the data for sell-off.




263




.......................... 9758$$ AT15 12-09-02 08:31:35 PS
BLUEPRINT FOR PROJECT RECOVERY
264


Figure A15-1 ” Design Review Approval Form
DESIGN REVIEW APPROVAL


The ________(1)_____________ Design Review Minutes

containing the ______(1)_________Design Review Package

labeled _______(2)____________

and dated _____(3)________

and

The _________(1)___________Design Review

conducted on _____(3)__________ together with the Design Review Action Items are

hereby approved

therefore

__________(4)____________________ is hereby directed to proceed to the next stage

of the program.

Signed _____(5)________ of __________(6)______________ Date _______________




Where:


(1) The Design Review”PDR, CDR, etc.
(2) Modi¬cation or issue
(3) Date of package or event
(4) The Contractor
(5) The Customer™s Representative
(6) The Contracting Authority
AT TAC H M E N T 16




Y
IN-PROCESS REVIEW
FL
APPROVAL FORM
AM
TE




The In-Process Review Form shown in Figure A16-1 can be used by you to
document the In-Process Reviews you have conducted in-house, or it can be
initiated by you and signed by your customer, or it can be initiated by your
subcontractor or team mate (probably by you) and acknowledged by you for
the purpose of documentation. The point is: Document the activity!




265




.......................... 9758$$ AT16 12-09-02 08:31:34 PS
BLUEPRINT FOR PROJECT RECOVERY
266


Figure A16-1 ” In-Process Review Approval Form
IN-PROCESS REVIEW APPROVAL FORM

The ___(1)____ In-Process Review Minutes containing

the __(1)_____In-Process Review Package

labeled ___(2)_______ and

dated ____(3)_______

and

The __(1)___In-Process Review

conducted on ___(3)_______ together with the In-Process Review Action Items are

hereby approved

therefore

____(4)____ is hereby directed to proceed to the next stage of the program.


Signed ___(5)_____ of ______(6)________ Date _______________




Where:

(1) The In-Process Review (Step 1, Step 2, etc.)
(2) Modi¬cation or issue
(3) Date of package or event
(4) The contractor or lead engineer
(5) The appropriate authority
(6) The organization of the appropriate authority
AT TAC H M E N T 17




NEGOTIATION CHECKLIST



Before entering any negotiation, you should outline your needs and wants and
then seriously consider the list. Ensure that needs are indeed needs and wants
are indeed wants and that they are not intermixed. Wants and needs include all
items except price.
The next element to de¬ne is the price you are willing to pay or be paid
(depending on which side of the table you are sitting on). Usually, this price is
not necessarily a single number but a range of numbers. Because of the com-
plexity of most negotiations, you need to outline what this number or range of
numbers represents. This is your basic ˜˜Negotiation Envelope.™™ In other words,
if you get the scope you want or need within the price you are willing to accept
or pay, everything is okay. Usually, your Negotiation Envelope must be ap-
proved by someone with contractual and Pro¬t and Loss (P&L) responsibility.
If, during negotiations, the Negotiation Envelope is about to be exceeded or

267




.......................... 9758$$ AT17 12-09-02 08:31:36 PS
BLUEPRINT FOR PROJECT RECOVERY
268


is not being achieved, you must either ask for”or declare”a recess and return
to the approval authority to get additional authority, or you must conclude the
negotiations as being unsuccessful.
The basic Negotiation Envelope is frequently modi¬ed by additional scope/
price arguments sometimes referred to as ˜˜Bubbles.™™ Bubbles are single-issue
items that contain their own price. Usually, Bubbles are not stand-alone but are
dependent on a basic contract scope and price in order to be incorporated. Each
Bubble should clearly state its precedence requirements or conditions such as:
This element may be included only if such-and-such is included in the basic
contract. You must be very careful with Bubbles. A smart negotiator may try to
get your Bubbles included without including the necessary precedents/condi-
tions or cost.
Your Negotiation Checklist should containing headings like:

’ Program
’ Scope
’ Objective Price
’ Acceptable Price Range
’ Negotiator
’ Authority

Each Bubble should have its own Negotiation Checklist that contains head-
ings like:

’ Program
’ Addition
’ Scope
’ Precedence/Conditions
’ Objective Price
’ Acceptable Price Range
’ Negotiator
’ Authority
AT TAC H M E N T 18




CRITICAL SUCCESS FACTOR
(CSF) MATRIX



It is necessary to track each Critical Success Factor (CSF) from requirement to
implementation. The tracking of CSFs is a little more complex in that each CSF
must be tracked into each unit to which it should be applied. Further, proof
must be supplied along the way and in the ¬nal system test that each CSF is
being met.
If you do not have such a checklist, an outline follows that you can employ.
Modify Table A18-1 for your own needs.




269




.......................... 9758$$ AT18 12-09-02 08:31:40 PS
BLUEPRINT FOR PROJECT RECOVERY
270


Ta b l e A 1 8 - 1 ” C r i t i c a l S u c c e s s F a c t o r ( C S F ) M a t r i x

CSF Unit A Unit B Unit C Unit D Final Proof
MTTR 0.5 hrs 0.5 hrs 0.5 hrs 0.5 hrs RMA Analysis
0.5 hrs Para 3.2.1
MTBF 30,000 hrs 30,000 hrs 30,000 hrs 30,000 hrs RMA Analysis
30,000 hrs Para 3.2.2
BIBLIOGRAPHY

Books

Blanchard, Kenneth and Spencer Johnson. The One Minute Manager. New
York: William Morrow and Co., Inc., 1982.

de Bono, Edward. Serious Creativity. New York: Harper Business, 1992.

Fishman, George S. Monte Carlo: Concepts, Algorithms, and Applications. New
York: Springer-Verlag, 1996.

Guffey, Mary Ellen. Business Communication: Process and Product. 2nd ed. Cin-
cinnati: South-Western College Publishing, 1997.

McDermott, Robin E., et al. The Basics of FMEA. Portland, Ore.: Productivity
Press, Inc., 1996.

271




.......................... 9758$$ BIBL 12-09-02 08:31:41 PS
BIBLIOGRAPHY
272


Rothenberg, Robert. The Plain-Language Law Dictionary. New York: Penguin,
1996.
Rubenstein, Reuven Y. Simulation and the Monte Carlo Method. New York:
John Wiley, 1981.
Senge, Peter. The Fifth Discipline: The Art and Practice of the Learning Organi-
zation. New York: Doubleday, 1990.
Sobol, Ilya M. A Primer for the Monte Carlo Method. Boca Raton, Fla.: CRC
Press, LLC, 1994.
Stamatis, Dean H. Failure Mode and Effect Analysis: FMEA from Theory to
Execution. Milwaukee, Wis.: ASQ Quality Press, 1995.
U.S. Army Field Manual (FM) 770-78. Available from the Superintendent of
Documents, Government Printing Of¬ce (GPO), Washington, D.C., or
the Consumer Information Center, Pueblo, Colo., and in digital form,
online at: www.incose.org/stc/fm77078.htm.


Articles

Barnes, Brenda J., and James W. Van Wormer, Ph.D. ˜˜Process Thinking and
the 85:15 Rule Applied to Education.™™ Source: www.grandblancommu
nityschools.com/qip/processthinking.htm (last accessed Aug. 5, 2002).
Chen, P. ˜˜The Entity-Relationship Model: Toward a Uni¬ed View of Data.™™
ACM Transactions on Database Systems, 1, no. 1 (1976): 9“36.
Luttman, Robert & Associates Online Articles, ˜˜Cause and Effect.™™ Source:
www.robertluttman.com/cause-effect.html (last accessed Aug. 5, 2002).
Patrick, Francis S. ˜˜Program Management”Turning Many Projects into Few
Priorities with TOC.™™ Newtown Square, Pa.: Project Management Insti-
tute, 1999. (Project Management Institute Seminar/Symposium [30th :
1999 : Philadelphia, Pa.], PMI 1999 Annual Seminars & Symposium Pro-
ceedings.)
Plsek, P.E. ˜˜Management and Planning Tools of TQM.™™ Quality Management
in Health Care 1, no. 3 (Spring 1993): 59“72.
BIBLIOGRAPHY 273


Private Documents

Early, John F., ed. ˜˜Cause-Effect Diagrams.™™ Quality Improvement Tools. Wil-
ton, Conn.: Juran Institute, 1989. The training kit entitled Quality Im-
provement Tools is produced by the Juran Institute, and is a part of their
inventoried items.
Systems Application Architecture”Common User Access Guide to User Interface
Design. IBM Corporation, 1991. IBM Document Number SC34-4289.
Available through IBM ¬eld of¬ces.
The Windows Interface Guidelines for Software Design. Redmond, Wash.: Mi-
crosoft Press, 1995. ISBN 1556156790. Available from Best Buy Books.

TRADEMARKS

Brainstorming is a trademark of In¬nite Innovations, Ltd.
DOORSrequireIT is a trademark of Telelogic DOORS, North America
EDGE Diagrammer and EDGE Programmer are trademarks of Pacestar
Software
Flowcharting Cause & Effect Module for Six Sigma Software Suite is a trade-
mark of Quality America, Inc.
MacWrite is a trademark of Apple Corporation
MBTI is a trademark of Consulting Psychologists, Inc.
Microsoft , Microsoft Word , MS Word , Microsoft Excel , MS Excel ,
Microsoft Access , MS Access , Microsoft Of¬ce , MS Of¬ce , Mi-
crosoft Works , MS Works are trademarks of Microsoft Corporation
PathMaker is a trademark of SkyMark
PMBN is a trademark of Best Practices, LLC.
Post-it is a trademark of 3M Company
REASON 4 is a trademark of DECISION Systems, Inc.
Root Cause Analysis (RCA) is a trademark of Root Cause Analyst
Six Sigma for Excel is a trademark of BaRaN Systems LLC.
SmartDraw is a trademark of SmartDraw.com
This Page Intentionally Left Blank
Y
INDEX
FL
AM


Af¬nity Diagrams, 166, 171“176, 201 Architecture, 39, 41“42
conceptual unity, 42, 117
purpose of, 171“172
TE




Critical Success Factors (CSF) under-
Relationship Diagrams, 173“176, 201
stood, 41, 112“113
software to support, 173, 175“176
design issues in, 43“44, 122
Alliances, 11, 26“30, see also Subcontracts;
key functions covered, 42, 114“115
Teaming, Alliances, and Subcontracts
major elements described and justi¬ed,
analysis of Causes for Action, 177“186,
42, 115“116
201
modules/subsystems well de¬ned, 41,
eliminating holes and overlaps, 186“187
113“114
Failure Mode Effect Analysis (FMEA),
recovery issues, 74, 110, 112“117
121, 166, 170, 182“184, 201
user interfaces well de¬ned, 42, 116“117
Force Field Analysis, 180“182, 201
Arthur, Jay, 179“180, 187n
Monte Carlo Simulation, 184“186, 192,
201
Pareto Analysis, 170, 178“180, 192, 193, back tracing, 140“141
201 BaRaN Systems, LLC, 173


275




.......................... 9758$$ INDX 12-09-02 08:31:43 PS
INDEX
276


Barnes, Brenda J., 166“167, 176n, 180 Technical Performance Checklist
(TPC), 41“55
benchmark research
Technical Recovery Checklist (TRC),
on Cause Descriptions, 157, 158, 160“
112“155
161, 201
Change Control Process, 47“48, 133
sharing benchmarks, 160“161
changes
Best Practices, LLC, 161
con¬guration, 54
Blanchard, Kenneth, 158, 164n
Prototype, 47“48
Blue Slipping, 178
charter, updating, 7
brainstorming
Chen, P., 173“175, 176n
of Cause Descriptions, 157, 158“160,
Christensen, David S., 90
201
company
software for, 159“160
company data and, 196
Brassboard, 133
Policies, Plans, and Processes and,
Breadboard, 133
24“25
Budget Reviews, 16, 30, 66, 89, 90, 94, 96
competence
budgets
of personnel, 33“34, 95“97, 102
allocations for, 115
of vendors, 31, 91“92
mix of personnel and, 79“81
Con¬guration Management, 40, 53“54
salaries and wages of personnel, 34, 98
Con¬guration Management Plan
Business Process Improvement (BPI), 192
(CMP) in, 40, 53“54, 150“152,
Business Process Redesign (BPR), 192
234“236
buying-in, 15
recovery issues, 111, 148, 150“154
Review Board approval of change re-
Capability Matrix, 249“250 quests, 54, 152“153
Capability Maturity Model (CMM), 152 version controls and, 54, 153“154
Cause and Effect Diagrams, 166, 167“171, Con¬guration Management (Control)
201 Board (CCB), 151
development of, 167“170 Consensus Gram, 178
software to support, 170“171 Contact Line Item Numbers (CLINs), 10,
Cause Descriptions 14, 63
analysis of, 177“186 Contract Data Requirements List (CDRL),
eliminating holes and overlaps in, 10, 14, 35“36

<<

. 8
( 9)



>>