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

S T A N D A R D T E C H N I C A L P L A N O U T L I N E		225
Part III—Specialty Engineering Plans
Plan	Title
1.0*	Concept of Operation
2.0*	Configuration Management Plan

3.0Contamination and Corrosion Control Plan

4.0 EMI/EMC Plan

5.0* Engineering Plan

6.0 Environmental Engineering Plan

7.0† Hardware Development Plan

8.0Human Engineering Plan

9.0Logistic Support Analysis (LSA)

10.0	Mantainability Plan					Y
11.0					L
	Manufacturing Management Plan
12.0	Mass Properties Control Plan
13.0				M
	Packaging, Handling, Storage, and Transportation Plan
			A
14.0	Parts, Materials, and Process ControlFPlan
15.0		E
	Producibility Plan
16.0		T
	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.

226	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
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.

A T T A C H M E N T 3

RISK MITIGATION PLAN

The Risk Mitigation Plan provides direction and control for the identification, documentation, correction methodology, and closure of risks on the program.

Risk Management is an organized, systematic decision-making process designed 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 product.

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 Identification. Potential risks must be identified and managed. Once identified, risks are entered into a Risk Mitigation Form as in Figure A3-1

227

228			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
		F i g u r e A 3 - 1 — R i s k M i t i g a t i o n F o r m
		<PROGRAM> 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 identification 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 (probability) of its occurrence (Po) and the severity of the potential consequences (So). When the assessments are made, the characteristics of the risk are documented 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 difficult to accomplish.

R I S K M I T I G A T I O N P L A N							229
		T a 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 approaches 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 final 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 arrangements, and profit 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 simply 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 assumed, the issue of mitigation becomes your full responsibility. This statement means that the intensity of mitigation will increase significantly. The assumption of the entire risk will require a full plan to approach and neutralize or at least mitigate the risk.

4.Risk Tracking. Once a risk has been identified, 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-

230	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

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:

SECNAVINST 4105.1

DoD Directive Dir 5000.2R, paragraph 3.3.3.

A T T A C H M E N T 4

CONTRACT/SUBCONTRACT OUTLINE

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 Requirements List or CDRL)

•Period of Performance

231

232	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

•Schedule

•Reference Documents

•Modifying Factors (for instance, the number of labor hours of specific disciplines that must be provided)

Specification containing:

•Scope of the Document

•Applicable Documents

•Requirements

•Item Definition

•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 compatible

•Qualification Requirements (for software) or Quality Assurance Provisions (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 Certifications

Attachments

Contract/Subcontract Data Requirements List (CDRL or SDRL)

Special Attachments

A properly defined SOW will contain (either incorporated or appended) the findings of the requirements discussions (negotiations). These findings 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

C O N T R A C T / S U B C O N T R A C T O U T L I N E

233

SOW and find all the requirements and the modifiers and group them together for your own purposes.

There are several types of specifications. MIL-STD-490 has established and defined five major specification (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 specification type. The specification types are shown in Table A4-1.

	T a b l e A 4 - 1 — S p e c i f i c a t i o n T y p e s
Type	Specification
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

Additional Resources:

MIL-STD-245

A T T A C 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 (Configuration Management).

2. REFERENCE DOCUMENTS

Refers to specifications, 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