A T T A C H M E N T 1 3

К оглавлению
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 
17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 
34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 
51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 
68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 
85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 
102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 
119 120 121 122 123 



The first question you may ask is: ‘‘What is the relationship between a Requirements

Traceability Matrix (RTM) and the Standards Traceability Matrix

(STM)?’’ The fact is that they both accomplish the same purpose but for different

kinds of requirements. The STM traces standards that are common to the

industry, the customer, and the enterprise. The RTM tracks SOW and specification

requirements that are unique (although some may be common) to this


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

difficult to create but always maintains the same relationships to other requirements.

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 probably

remain constant for most, if not all, projects and only the Customer Chart

needs to be researched. The advantage of using the multipurpose chart is that

the relationships between all elements—and there will be many—are clearly

presented 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 specific 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 sideby-

side. That’s because they are the same requirement. It is common for a company

to absorb standard requirements for their areas of operation as standard

policies within the company. If you use a multipurpose matrix and the standards

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 figure shows the relationship between Attachments and Appendices

to the Program/Project Plan and the paragraphs of the Program/Project

Plan as well as the Enterprise Policies, Plans, and Processes.

T a b l e A 1 3 - 1 — S t a n d a r d s T r a c e a b i l i t y M a t r i x


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

S TA N D A R D S T R A C E A B I L I T Y MAT R I X 257

F i g u r e A 1 3 - 1 — P o l i c y - t o - P r o g r a m P l a n t o S u p p o r t D o c u m e n t F l o w

Enterprise Policies,

Plans, & Processes Program Plan

Attachs &


1 Introduction

2 Scope

2.1 Program Description

2.2 Deliverables C

2.3 Schedule 18

M-M 04018 2.4 Sell-off Criteria 27

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

M-M 06000 5.1.3 Subcontracts and Materials 20

M-M 04050 5.1.4 Data Management 4

M-M 04030 5.1.5 Configuration Management 3

M-M 07000 5.1.6 Quality Assurance 14

M-M 10050 5.1.7 Team Members and Alliances 15

M-M 11000 5.1.8 Training 23

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 file 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 recommendations

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.