Cagle R.B. - Blueprint for Project Recovery[c] A Project Management Guide (2003)(en)

configuration control boards and the interfaces between the CM organization and outside organizations.

4.CONFIGURATION MANAGEMENT PHASING AND MILESTONES

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

5. DATA MANAGEMENT

The methods for meeting the CM technical data requirements.

Y 6. CONFIGURATION IDENTIFICATIONL

The identification of the Hardware FConfiguration Items (HWCIs) and Com-

puter Software Configuration Item (CSCIs). M 7. INTERFACE MANAGE ENT

The procedures for the Eestablishment of interface agreements.

8. CONFIGURATION CONTROL

The responsibilities and authority of your configuration control board, the classification of changes, and the level of authority for change approval/concurrence.

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 functional and physical configuration audits and the format for reporting results of in-process configuration audits.

A T T A C H M E N T 6

QUALITY ASSURANCE PLAN OUTLINE

PROGRAM

QUALITY ASSURANCE PLAN

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

238 B L U E P R I N T F O R P R O J E C T R E C O V E R Y

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

1.2QUALITY OBJECTIVES

The following quality principles are intended to be consistent with Company quality policies and plans.

All measurements will include quantitative determinations.

Methods will be consistent.

Measurements will be linked to a standard value.

1.3RESPONSIBILITIES AND AUTHORITY.

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

2.STRUCTURE OF QUALITY SYSTEMS

2.1QUALITY 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 Quality Assurance Director.

2.2RESOURCES 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.3OPERATIONAL PROCEDURES

The Program Quality Assurance Plan will include a Program Quality Control Plan that outlines the specifics of controlling product quality on theProgram .

A T T A C 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 requirement entries in the RTM. If you have not accomplished this task before, don’t worry. It is rather simple nowadays with the ‘‘find’’ 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 defines traceability as:

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

241

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

Most requirements documents, including SOWs and specifications, 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 quantified. 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 specified, 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 find one, simply copy and paste and include the paragraph number. If your programs are compatible, such as MS Office, 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.