5 FAH-5 H-210 MANAGING DEPARTMENT OF STATE PROJECTS

UNCLASSIFIED (U)

5 FAH-5 H-200
PROJECT MANAGEMENT

5 FAH-5 H-210

MANAGING DEPARTMENT OF STATE PROJECTS

(CT:ITS-13; 07-03-2024)
(Office of Origin: DT/BMP/SPB/PMD)

(TL:ITS-1; 02-13-2002)

a. Managing State Projects (MSP) is the preferred methodology in the Department for all IT development projects. Another method can, if needed, be used but it must map to MSP control gates, so that the project team can follow the guidance in this handbook.

b. MSP will be used to follow the outlined life cycle of any system or application developed.

c. This chapter provides detailed guidance on using MSP to manage Department IT development projects.

5 FAH-5 H-212 MANAGING STATE PROJECTS (MSP) CONCEPT

(TL:ITS-1; 02-13-2002)

a. The MSP concept presents a comprehensive life cycle management technique that uses three periods (study period, acquisition period and operations period) to establish a systematic framework with tailoring options and control gates for managing projects with success. This concept must be used to manage IT projects that meet one or more of the following criteria:

(1) Projects with an estimated cost (excluding capital expenditures) of $500,000 or greater;

(2) Projects that exceed one year;

(3) Projects that are considered by executive management to be highly visible or sensitive;

(4) Projects that require a Memorandum of Understanding (MOU) with another bureau or agency; and

(5) Projects that, in the opinion of the project manager, require the formal discipline of a project management tool.

b. Projects that are not centered around the MSP method may be managed based on a comparable method that will yield successful results.

c. Use the MSP concept throughout the life cycle of the project to track performance, measure progress, and yield tangible results.

5 FAH-5 H-213 PROJECT PLAN

(TL:ITS-1; 02-13-2002)

a. The project plan will define which phases of the life cycle are appropriate to the project. Tailor the project plan to reflect the scope and nature of the project, and avoid unnecessary phases. See 5 FAH-5 Exhibit H-213 for a Project Plan Outline (Sample).

b. Include an executive summary to provide management with a brief overlook at the plan in terms of goals and objectives, monitoring techniques, control gates, and expected results.

c. Prepare the project plan to chart the entire project’s course. Include tasks, schedules, and resources (i.e., people and money) outlined in a well-defined framework with a best business practice approach and management support and approval. The best planning results are achieved when all project participants are involved in the planning effort. A project cannot succeed without details of task assignments, activities, start and end dates, budget information, documents, and deliverables in a valid project plan. The major aspects of the project plan will define:

(1) Executive summary—Management takes a brief look at the plan in terms of goals and objectives, monitoring techniques, control gates, and expected results. Begin the project plan with a project title and the name of the project manager.

(2) Introduction—The “introduction” should briefly describe the foundation in terms of sponsor commitment and user needs and/or requirements. State the objectives of the project, displaying a clear understanding of the environment. Show your goals in simple declarative sentences.

(3) Key personnel—Describe the key personnel and organizational roles and responsibilities and how they will contribute to and impact the project. If it is a major effort that may require modification of requirements or change during implementation, indicate the requirements and/or changes in the plan. The project manager assigns all tasks or will designate task leaders to assign some tasks and monitor them to ensure completion. (State the objectives of the project, how they will be accomplished, and by what standards they will be measured. If contractors are involved, provide information on how contractors will be managed in terms of tangible output, quality, and timeliness.)

(4) Objectives and performance measures—State the objectives of the project, and how they will be measured. If contractors are involved, provide information on how contractors will be managed in terms of tangible output, quality, and timeliness.

(5) Work breakdown structure—Identify major work elements and provide task descriptions. Include major activities, products and/or deliverables, scheduling and risks in accomplishing the goals. Outline project management responsibilities, technical assessment, contract services, and activities for each phase of the project cycle.

(6) User requirements phase—The first of the nine phases of the project cycle and the beginning of the study period. This phase starts with the recognition of a need and ends when the project resource request is submitted as a part of the program plan. The user requirement statement and the initial system acquisition plan is prepared during this phase.

(7) Concept definition phase—The second of nine phases of the project cycle and the second phase of the study period. This phase starts with the establishment of system requirements following the user requirements definition phase and ends with a defined system concept approved at a system concept review (SCR). The final versions of the user requirements document, system requirements document, and concept definition document are prepared during this phase.

(8) System specification phase—The third of nine phases of the project cycle and the third phase of the study period. This phase starts after the completion of the concept definition phase with analysis of performance trade-offs and ends with the establishment of design criteria relative to the approved system concept.

(9) Acquisition planning phase—The fourth of nine phases of the project cycle and the fourth phase of the study period. This phase begins after completion of the system specification definition phase, and ends with review and approval of the system acquisition plan at the acquisition plan review (APR). The acquisition planning phase is the last phase of the study period.

(10) Source selection phase—The fifth of the nine phases of the project cycle and the beginning of the acquisition period. This phase begins with solicitation planning and proceeds through a series of reviews that include a government source selection initiation review (SSIR), contractor final proposal review (FPR), and Government source selection authorization review (SSAR). The source selection phase ends with the contract award.

(11) System implementation phase—The sixth of the nine phases of the project cycle and the second of the acquisition period. This phase begins with the award of the contract and proceeds gates, which provide the contractor with the Government’s assessment of the contractors status and progress, formal approval to proceed to the next control point, and a commitment to support the on-going efforts. This phase ends with the system acceptance review (SAR) and Government acceptance of the system. Documents such as the implementation plan, “design-to” specifications, design documentation, system verification plan and test procedures, “build-to” specifications, and operations and maintenance documentation, or equivalent documents, are prepared in this phase. Also known as the implementation phase.

(12) Deployment phase—The seventh of the nine phases of the project cycle and the beginning of the operations period. The Government project manager’s objective is to transfer the system operation to the user. This phase begins with the deployment readiness review (DRR), and ends with satisfactory completion of the user validation readiness review (URR). The Government, with contractor assistance as specified, prepares the system for deployment, deploys the system and performs sufficient operational performance verification to confirm the system is ready for user operation.

(13) Operations & maintenance phase—The eighth of the nine phases of the project cycle and the second phase of the operations period. This phase begins with the completion of the deployment readiness review and turnover of the system to operational personnel. An annual performance report is prepared and reviewed at the annual system certification review to assure the system performance continues to meet the performance requirements.

(14) Deactivation phase—The ninth and last of the nine phases of the project cycle and the third phase of the operations phase. This phase includes the proper handling and disposal of all sensitive and hazardous materials and begins with the decision to deactivate the system at the deactivation approval review and ends after all deactivation procedures and the project completion review has been completed.

5 FAH-5 H-214 TYPES OF PROJECTS

(TL:ITS-1; 02-13-2002)

a. Approach each project with a general understanding of the whole picture and ensure that the project team also understands project types and characteristics. Use the following steps to categorize the project:

(1) Match the characteristics of the specific project against the five models listed in 5 FAH-5 Exhibit H-217.1(4), Summary of Project Types and Characteristics;

(2) Select the model most closely matching the project;

(3) Determine the project’s technical content;

(4) Analyze the project’s cost and schedule parameters; and

(5) Consider if the initial model selected is appropriate by looking at the characteristics and complexity factors.

b. The result will be a better understanding of the nature of your project. Remember, project planning and acquisition should be oriented to the type of project to be performed.

5 FAH-5 H-215 CAPITAL PLANNING REQUIREMENTS

(CT:ITS-13; 07-03-2024)

a. Project managers must use the Department’s Information Technology Capital Planning System (ITCPS) which is a web-based database of information on projects included in the ITCP and investment control process. This database also helps maintain the IT modernization within the Department, whether funding is needed or not.

b. ITCPS will manage the data used by the Management Review Advisory Group (MRAG), Technical Review Advisory Group (TRAG) and IT Program Board (ITPB) to evaluate projects and make recommendations and funding decisions.

c. Because some program offices may consider part of the data in ITCP to be procurement sensitive, users will require an account to access the system. Project managers accounts will be issued to the program office as opposed to the individual(s) office. Contact DT/BMP/OCA/SD for more information.

5 FAH-5 H-216 PROJECT MANAGEMENT LIFE CYCLE MANAGEMENT

(TL:ITS-1; 02-13-2002)

See 5 FAH-5 Exhibit H-216 Sample Project Management Life Cycle Model for a crosswalk between MSP and life cycle management.

5 FAH-5 H-217 THE PLANNING PROCESS

(TL:ITS-1; 02-13-2002)

See 5 FAH-5 Exhibit H-217 for a project planning checklist when initiating the planning phase.

5 FAH-5 H-217.1 Study Period

(CT:ITS-13; 07-03-2024)

a. The study period is the backbone of project planning. The study period, also known as the planning phase, is integrated throughout the life cycle of the project. Planning is not the object of considerable effort at the start of a project and then abandoned. Planning is continuous, whether it is in developing the project management plan or modifying the acquisition strategy based on the emergence of new technology.

b. The study period is a crucial time set aside to closely examine and analyze the critical information flows and requirements to determine the real user and/or customer business related needs. The user and/or customer may have painted a picture of a desired need; but until the requirements are carefully looked at from a sound business practice standpoint, it may not be justifiable until a business analysis is performed (see 5 FAH-5 Exhibit H-217.1(1) Business Process Analysis Checklist (Sample)).

c. Determine what is necessary to fulfill project goals. Look at Commercial off-the shelf (COTS) and Government off-the-shelf (GOTS) products and evaluate them carefully (see 5 FAH-5 Exhibit H-217.1(5) COTS/GOTS Software Evaluation Sample). Decide if the services of a contractor are necessary and carefully plan how to monitor, set the standards and establish control gates. Gather as much information as possible to build the project plan. Determine the level of approval based on cost (apply the benefit cost analysis process, 5 FAH-5 H-600) and prepare the necessary documentation if the project must be approved by one of the review boards.

d. See 5 FAH-5 Table H-217.1 for a summary of the PM activities that must occur during the study period. The control gates are shown in bold italics.

5 FAH-5 Table H-217.1 Project Management Planning Activities in the Study Period

PURPOSE (Study Period)	ACTIVITY (Project Initiation)
Perform a business process analysis	This is an important step in the study period. Develop an information requirements document with clearly defined process and activities and information requirements. See 5 FAH-5 Exhibit H-217.1(1) Business Process Analysis Checklist (Sample). Conduct quality assurance review on the BPA.
Define and document user requirements	An understanding of the user’s mission and business process is of primary importance in defining user requirements. Users requirements must be identified in terms of operational needs, schedule requirements, interface requirements. To fully define user requirements, interests of three types of users must be examined: executive management, system administrator, and system end users. User requirements must be prioritized and weighted to discern “need” versus “wants.” System requirements must be traced to user requirements and must be verifiable. See 5 FAH-5 Exhibit H-217.1(2) for an example of a User Requirements Statement (Sample).
Select project type	Match the characteristics of the specific project against the five project models listed in 5 FAH-5 Exhibit H-217.1(3), Summary of Project Types and Characteristics.
Consider initial system concepts	Initial concepts help trace or map user requirements to system requirements. This helps users and builders visualize the system and “sign-up.”
Prepare benefit and/or cost analysis	See 5 FAH-5 Exhibit H-217.1(4), Benefit and/or Budget Guidelines: Checklist. Conduct quality assurance review using 5 FAH-5 Exhibit H-415(4), Benefit Cost Analysis QA Checklist. The configuration manager will file the original. See 5 FAH-5 H-539 CM Library.
Commercial Off-The-Shelf (COTS) and Government Off-The-Shelf (GOTS) Software	Determine what is necessary to fulfill project goals. Look at COTS and GOTS products and evaluate them carefully (see 5 FAH-5 Exhibit H-217.1(5), COTS and/or GOTS Software Evaluation Sample).
Capital planning requirements	All project managers must input the projects into the ITCPS, whether funding is needed or not. See DT/BMP/OCA/SD for more details.
Prepare requirements verification traceability matrix	Develop a document outlining the requirements. See 5 FAH-5 Exhibit H-217.1(6), Requirements Verification Traceability Matrix (Sample)
Prepare system requirements document	This document is prepared by using the user requirement statement. See 5 FAH-5 Exhibit H-217.1(7), System Requirements Document (Sample). The chapter dealing with data administration will provide input to this document in areas of data sources, business rules, and interfaces and data requirements. See 5 FAH-5 H-300.
Control Gate System requirements review (SRR)	Where senior management reviews and approves the project system requirements document as presented by the project team. It provides a forum for senior management to constructively challenge the project team to verify that they understand what the government wants.
Security accreditation, certification and approval	The project manager must notify the Office of Information Security Technology (DS/CIS), in writing, during the study period to request computer and technical security evaluations and assessments. This action determines the computer and technical security concerns that may affect project development and prevent unnecessary delays.
Information Technology Configuration Control Board (IT CCB)	Submit an Assessment Request, or a Change Request through the Local CCB. See 5 FAH-5 H-500, Configuration Management, for more information.
Prepare and distribute project plan (what, when, who, how much)	See 5 FAH-5 Exhibit H-213 for a Project Plan Outline (Sample). Tailor the project plan to reflect the scope and nature of the project, and avoid unnecessary phases. Chart the entire project’s course. Conduct quality assurance using 5 FAH-5 Exhibit H-415(5), Project Plan QA Checklist. The configuration manager will file the original document to the CM library. See 5 FAH-5 H-539 CM Library.
Prepare configuration management plan	Develop a CMP to define project CM activities, schedules, responsibilities, and resource requirements to ensure that deliverables identified in the project plan and quality assurance plan are subject to the CM effort. See 5 FAH-5 H-515. The configuration manager will file the original document to the CM library. See 5 FAH-5 H-539 CM Library.
Control Gate Project initiation review (PIR)	Where senior management reviews, approves, and commits to the project plan as presented by the project team. Provides a forum for senior management to constructively challenge the readiness of the team.
Concept of operations document	The project cycle can only be effective if the concept of what is to be done is clearly understood and applied accurately to turn ideas into reality (see 5 FAH-5 Exhibit H-217.1(8) Concept Of Operations (Sample)).
Control Gate System concept review (SCR)	Reviews and approves the recommended system concept configured to satisfy the system requirements document and described in the system concept document. This control gate is the decision point to proceed to with the development of the system performance specification.
Develop system specification	The system specification defines the functional, performance, and verification requirements for the system or end item. Each requirement included in the specification must be verifiable. See 5 FAH-5 H-217.1(9), System Specification Outline Sample.
Trace the specification to system requirements	Trace the system requirements into a system specification.
Perform market research and develop source list	Establish feasibility. Document the results in a manner appropriate to the size and complexity of the acquisition. Use the results of the market research in subsequent acquisition documents, such as the requirement analysis, analysis of alternatives, and solicitation document.
Finalize acquisition plan	The method of cycling through the planning process, during the study period, to factor in additional “requirements development” information develops the final acquisition plan. See 5 FAH-5 H-217.2(1), Acquisition Plan Outline (Sample).
Risk management	Identifies probable risk early on, prepares how the project may be impacted, and takes the proper steps to reduce risk by identifying those areas that should be monitored and managed throughout the project life cycle.
Control Gate Acquisition plan review (APR)	The decision point to initiate project and commit funding, manpower and other resources. The APR approves funding for the rest of the project cycle.

5 FAH-5 H-217.2 Acquisition Period

(TL:ITS-1; 02-13-2002)

a. Project acquisition or implementation should not begin until a thorough study period has been completed. The acquisition period begins with thorough, accurate, and effective acquisition planning. This period establishes commitment (contractual), and defines the project team (Government-contractor). It is the second period in the project cycle. It consists of the source selection phase and system implementation phase. Planning flows into a formal acquisition plan that begins the process and an ultimate course of action. See 5 FAH-5 Exhibit H-217.2(1) Acquisition Plan Outline (Sample).

b. Project managers are encouraged to procure Commercial off-the-shelf software (COTS) or Government off-the-shelf (GOTS) products during this period to eliminate or significantly reduce the need for costly and time-consuming development efforts.

c. Quality assurance controls and configuration management of all hardware and software items (including documentation) must be in place. See 5 FAH-5 Exhibit H-217.2(2) Quality Assurance Checklist during the acquisition effort.

d. Consider the following schedule and resource estimates then approach them realistically:

(1) Use sound practices in estimating the resources and time needed to complete a task;

(2) Contractor estimates must be more realistic (less optimistic); and

(3) Past cost experiences must be rationally applied to future work. See 5 FAH-5 Table H-217.2 for a summary of the minimum PM activities during the acquisition period.

5 FAH-5 Table H-217.2 Project Management Planning Activities

Purpose (Acquisition Period)	Activity (Detailed Design)
Prepare a Request For Proposal (RFP) and source selection plan	A well-defined project plan, performance specification, statement of work, and acquisition plan are critical to minimizing implementation risks and developing a well-defined source selection plan (SSP) and request for proposal (RFP). See 5 FAH-5 Exhibit H-217.2(3) Source Selection Plan Outline (Sample)
Establish contracting officer Control of the solicitation process	The source selection initiation review (SSIR) is the decision point for the contracting officer to release the RFP and implement the source selection plan. The project team should also review the source selection process and the source selection plan, to achieve the confidence that the process will provide a fair review of the resulting proposals, and selection of a winning company consistent with all legal requirements.
Follow source selection plan	The source selection plan is the most important product in the source selection as it serves as the project manager’s control document.
Award contract	See 14 FAH-2 H-440 Awarding Contracts
Revised project plan	Revise project plan if scheduling and development will exceed the projected timeframe in original plan.
Control Gate Source selection initiation review (SSIR)	The Government executive control gate, which reviews and approves the Government’s request for proposal (RFP) and source selection plan. The SSIR is the decision point for the contracting officer to release the RFP and implement the source selection plan.
Control Gate Source selection authority review (SSAR)	The Source selection authority review (SSAR) review is a constructive challenge of project readiness to proceed with negotiation and project implementation.

5 FAH-5 H-217.3 Operations Period

(CT:ITS-5; 02-05-2013)

a. The operations period of the life cycle concludes every system creation, maintenance, or modification effort. Every request for maintenance and modification begins the system life cycle again with the study period.

b. When a need for system maintenance or modification is established, notify the sponsor. If the sponsor concurs with the request, a change request (CR) is generated and forwarded to the Configuration Control Board (IT CCB), Control Board (IT CCB) or the local IT Configuration Control Board (CCB) as appropriate.

c. See 5 FAH-5 Table H-217.3 for a summary of the minimum PM activities during the operations period.

5 FAH-5 Table H-217.3 Project Management Planning Activities in the Operations Period

Purpose (Operations Period)	Activity (Deployment)
Install and test the system at the operational site	Period during which hardware and/or software is employed in its operational environment, monitored for satisfactory performance, and modified as necessary to correct problems or to respond to changing requirements
Control Gate Test readiness reviews (TRR)	Government COTR concurs that the test preparation is acceptable, and official testing can begin, the COTR gives written authorization to proceed.
Train operators and users	Provide training to users, operations managers, operations staff, and security officers to ensure that the system is used and operated properly. See 5 FAH-5 Exhibit 217.3(2) Training Plan Outline Sample.
Obtain operational acceptance	Transfer system responsibility for system operation from the Government project manager to the user.
Control Gate Acceptance reviews (AR)	This control gate is where the user determines that the product presented for acceptance complies with its specifications.
Obtain user acceptance	Does the product delivered by the operational system and personnel to the user meet the original user requirements as documented in the system’s requirements document, thus validating the system?
Control Gate User acceptance review (UAR)	The Government user control gate to determine that the project product delivered by the operational system and personnel to the user meets the original user requirements as documented in the system’s requirements document thus validating the system. The UAR is the decision point for the user to accept the system and is also the initial operating capability (IOC) milestones.
Prepare annual system performance report	An annual system performance report is prepared and reviewed at the annual system approval review to assure the system performance continues to meet the performance requirements.
Control Gate Annual system certification review	Determines that the product delivered by the operational system and personnel to the user continues to meet the original user requirements as documented in the system’s requirements document.
Retire system and/or product	Develop a plan for maintenance, deactivation, or retirement of a system. When the need for maintenance or modification is established, notify the sponsor.

5 FAH-5 H-218 AND H-219 UNASSIGNED

5 FAH-5 Exhibit H-213
Project Plan Outline (Sample)

(TL:ITS-1; 02-13-2002)

USE: The project plan presents the start-up proposal for a new project or program of projects.

INTERRELATIONSHIPS: The user requirements statements drives the project plan.

PREPARATION RESPONSIBILITY: Program champion

CONTROL GATE: Program plan review (PPR)

EXECUTIVE SUMMARY

1.0 INTRODUCTION
1.1 Background
1.2 Purpose
1.3 Scope

2.0 KEY PERSONNEL
2.1 Roles and Responsibilities
2.2 Multiple Tasks
2.3 Personnel Risks

3.0 OBJECTIVES AND PERFORMANCE MEASURES
3.1 Goals and Objectives
3.2 Meeting Objectives
3.3 Performance Standards
3.4 Managing Contractors
      3.4.1 Scheduling
      3.4.2 QA Contract Plan
      3.4.3 Control Gates
      3.4.4 CM Contract Plan

4.0 WORK BREAKDOWN STRUCTURE (WBS)
4.1 Major Activities
4.2 Deliverable and/or End Products
4.3 Scheduling and Control Gates
4.4 Risk Assessment
4.5 Projected Costs
4.6 Approval Signatures

5.0 USER REQUIREMENTS PHASE
5.1 Detailed Work Estimate (Staff and Budget)
5.2 Project Tailoring
5.3 Deliverables

6.0 CONCEPT DEFINITION PHASE
6.1 Detailed Work Estimate (Staff and Budget)
6.2 Project Tailoring
6.3 Deliverables

7.0 SYSTEM SPECIFICATION PHASE
7.1 Detailed Work Estimate (Staff and Budget)
7.2 Project Tailoring
7.3 Deliverables

8.0 ACQUISITION PLANNING PHASE
8.1 Detailed Work Estimate (Staff and Budget)
8.2 Project Tailoring
8.3 Deliverables

9.0 SOURCE SELECTION PHASE
9.1 Detailed Work Estimate (Staff and Budget)
9.2 Project Tailoring
9.3 Deliverables

10.0 IMPLEMENTATON PHASE
10.1        Detailed Work Estimate (Staff and Budget)
10.2        Project Tailoring
10.3        Deliverables

11.0 DEPLOYMENT PHASE
11.1        Detailed Work Estimate (Staff and Budget)
11.2        Project Tailoring
      11.3 Deliverables

12.0 OPERATION & MAINTENANCE PHASE
      12.1 Detailed Work Estimate (Staff and Budget)
      12.2 Project Tailoring
      12.3 Deliverables

APPROVALS

Sponsor: ____________________________ Date: _______________
Authorized Signature

Project Manager:_______________________ Date: _______________

Office Symbol: _______________________ Date: _______________

Division Chief: _______________________ Date: _______________

5 FAH-5 Exhibit H-216
Sample Project Management Life-Cycle Model

(TL:ITS-1; 02-13-2002)

MSP/PERIOD	TRADITIONAL SYSTEM LIFE CYCLE PHASE	TASKS
Study Period	Initiation Phase	Receive, review requirements Meet with sponsor Complete development request Process system design review Estimate schedule and resource requirements Direction preparation of required documentation Prepare and distribute project plan
	Requirements Analysis	Establish acceptance criteria Introduce sponsor and/or user and project team Arrange functional requirements review Respond to functional requirements review action items Release functional requirements specs Revise and distribute project plan
	Preliminary Design	Arrange preliminary design review Conduct preliminary design review Respond to preliminary design review action
Acquisition	Detailed Design	Review, accept, and/or regression test plan Arrange and conduct critical design review Respond to critical design review action items Coordinate responses to critical design review action items Release documentation Revise and distribute project plan
Operations	Implementation	Conduct accept and/or regression test Release source code and documentation Update and distribute project plan
	Installation	Request software release Maintain and distribute project plan Confirm target software Distribute software and documentation Review installation test report Formally transfer system to user and operations departments
	Operation and/or Maintenance	Respond to problem reports Monitor the environment Change request handling and/or acceptance

5 FAH-5 Exhibit H-217
Project Planning Checklist

(TL:ITS-1; 02-13-2002)

INTENDED USE: For a project team and/or project manager to use when initiating the planning phase of a project. The checklist contains items to consider when checking the work of a project team in building a project plan.

Items to Consider	Yes	No	Note
Initiating the Plan
1. Has the project scope been defined?
2. Have user requirements been established (at least at the high level)?
3. Have other systems affected by this project been identified?
4. Has a project manager been identified?
5. Have the project goals been identified and reviewed by appropriate personnel?
6. Have deliverables been identified?
7. Has the project team composition been identified?
8. Are the technologies available to complete the project?
9. Has the appropriate project plan structure and template been identified?
10. Has a project folder of some other type of mechanism been set up to collect project planning and performance information?
Identifying the Life Cycle
11. Have available life cycle models been reviewed with a quality assurance representative?
12. Has the project planning approach and project life cycle model been reviewed with the project team, quality assurance, configuration management, technical writers?
13. Have life cycle activities, work products, and reviews been documented in the project plan?
Establishing the Project Environment
14. Have the selection criteria for methods and tools to support the technology approach been identified and documented?
15. Has a team to select the methods and tools been identified?
16. Has the selection of methods and tools taken place?
17. Have the team communications needs been identified (networking, email, voice)?
18. Has each of the project team member’s needs been examined (training on methods and tools, communications, workspace and other physical facilities?
19. Have the discrepancies of the above-mentioned items been scheduled and corrected?
Creating a Work Breakdown Structure
20. Have work items been drafted?
21. Have the work items been reviewed to identify dependencies and ordering of work?
22. Have effort estimates been assigned to all work items?
23. Have the results of estimating activities been documented in the project plan?
24. Has the work breakdown structure been reviewed with customer Representatives, quality assurance, and senior management to ensure all needed work is included?
Defining Project Measures
25. Have the key issues of the project been identified (from project goals and objectives, environment, risks, and other characteristics)?
26. Have measures been identified for each key issue?
27. Have indicators and reports been identified for all issues?
28. Has it been determined when the measures will be gathered? analyzed? reported?
29. Has a measurement plan been prepared and incorporated into the overall project plan?
30. Has a person been assigned the role of measurement specialist to process the measurement data into a usable form?
31. Has time been allocated to review the results of the measures with quality assurance and senior management?
32. Is the measurement plan reviewed periodically and updated as needed?
Allocating Personnel and Developing a Schedule
33. Have work tasks been discussed with individual team members and skills matched to tasks?
34. Have the individuals agreed to the division of the work?
35. Have individuals provided calendar constraints and other input to help determine the personnel best suited for the work?
36. Have work requirements and personnel been reviewed to determine the need for additional personnel or changes in the assignments?
37 Have support resources been identified? (independent test, quality assurance, configuration management, and technical writing)
38. Have all needed personnel been assigned to the project? Has management confirmed this?
39. Have the task lists from the WBS, effort, and personnel assignments all been input to a project-planning tool?
40. Have initial schedules been generated with the planning tool and results been reviewed to see that they meet project goals?
41. Have adjustments been made to order work assignments, or WBS to meet project goals?
42. Have changes been negotiated as needed to modify project requirements to meet the project goals, given any resource constraints?
43. Have changes been negotiated to modify personnel commitments to meet the project goals, given any requirements constraints?
44. Has the complete initial schedule been reviewed with Senior Management and all affected parties?
45. Has the resulting schedule been documented in the project plan?
46. Has a quality assurance plan been written?
47. Has a configuration management plan been written?
48. Has the project team completed a technical review of the plans?
49. Other?

5 FAH-5 Exhibit H-217.1(1)
Business Process Analysis Checklist (Sample)

(TL:ITS-1; 02-13-2002)

Business Process Analysis Checklist	Yes	No	Note
1. What is the process called?
2. How does this process contribute to the organization’s mission?
3. Identify business drivers, e.g. laws and regulatory guidance, event statutes and other constraint guides, and controls.
4. What types, when, and how often the information and other input are used and transformed by the process to produce one or more products or services?
5. What types of resources, including technologies, data, applications, people, and facilities are used to perform the process?
6. What activities are included in this process?
7. Define each activity.
8. How is each activity performed and provide order of sequence?
9. What triggers each activity performed?
10. What output does each activity produce? Who uses it? How?
11. What types and sources of data are used to perform activity?
12. Develop target or “to-be” process based on the process improvement method.
13. Consider technology re-use, sharing and standardization to minimize your requirements.
14. Perform gap analysis to support new process requirements.
15. Develop requirement document for inclusion in our project plan.

Perform a business process analysis to determine the requirements:

· Identify stakeholders and their roles.

· Identify mission-connected activities that development effort will support.

· Prepare a requirement analysis report that includes “current” business process.

· Prepare “to-be” business process.

· Perform a market survey of COTS and GOTS based on requirements.

· Determine compatibility among your organization architectural IT assets.

5 FAH-5 Exhibit H-217.1(2)
User Requirements Statement (Sample)

(TL:ITS-1; 02-13-2002)

INTENDED USE: This document defines the user’s needs for the functional requirements and operational concepts for any resulting system or product. User-imposed constraints are also identified in this document.

INTERRELATIONSHIPS: The user’s requirement document is the basis for developing the system requirements document and system concept of operations.

PREPARATION RESPONSIBILITY: User and project office

CONTROL GATE: Final—Project Plans Review (PPR)

This document is compiled from letters, memoranda, studies, and any papers documenting user requirements. At a minimum, the document should include operational needs, current capability description, interface requirements, scheduled requirements, projected mission life, and user constraints.

5 FAH-5 Exhibit H-217.1(3)
Summary of Project Types and Characteristics

(TL:ITS-1; 02-13-2002)

Project Type	Project Deliverables	Project Technology	Project Risks
System Development	System with a high percentage of new product design and varying degrees of hardware and software content.	Developed using state-of-the art and/or leading edge technology and design techniques.	Because of high risks, may require extensive Government-contractor interaction.
Product Integration	Commercial off-the-shelf (COTS) system integrated to meet a special or specific need	Integrated and built to meet a unique needs using proven or standard off-the-shelf products and materials.	Risk is lower then systems development because of off-the-shelf product use.
System Operations and Maintenance	Existing system supported to meet operational and mission needs	Operated and maintained using accepted practices and procedures defined in existing system documentation	Low risk if product is well documented
Research and Development	New technology applied to meet a new or specified need	Based on investigation and application of new science and/or technology	High risk in science and/or technology maturity
Production	Proven design produced in quantity to meet an existing functional need	Produced using current manufacturing, assembly and testing techniques	Moderate risk for first production; low risk for follow-on production

5 FAH-5 Exhibit H-217.1(4)
Benefit and Budget's Guideline: Checklist

(TL:ITS-1; 02-13-2002)

INTENDED USE: For a project team and/or project manager to evaluate the effectiveness of the benefit and cost analysis process. The checklist contains items to consider when a project begins, when a major phase is completed, or at a post-implementation review after the project results have been in use for some time, to ensure that the benefit cost analysis was appropriate to the project.

Items to Consider			Yes	No	Note
1. Does descriptions of benefits relate to organizational goals, objectives, missions, functions, and operating environment?
2. Have benefits been identified for each solution alternative?
3. Have both quantitative and non-quantitative benefits been identified? (see following checklist)
4. Have benefits been identified in monetary terms? For those that have not, has justification been documented?
5. Has cost avoidance been counted only once, i.e. as either a reduction in costs or an increase in benefits?
6. Have benefits been rank-ordered using either weighted or un-weighted scoring?
7. Has the method used to estimate benefits been documented?
Benefits—Update (Review Initial Development for Applicability)
8. Have changes to project objectives, benefits and reviews caused any changes to the proposed benefits?
9. Have all benefit categories been re-examined?
10. Has the rank ordering of benefits been updated to reflect any changes?
Benefits—Post-Implementation Review
11. Have the expected benefits of the solution been attained?
12. For any benefits not attained, is there a documented explanation of why not?
13. If another solution originally proposed would have been better, is there a way to improve the process of performing the benefits analysis to ensure a more appropriate analysis in the future?
14. Other?
ID	Response	Possible Quantitative Benefits
1.		Reduced resource requirements —Personnel —Lease, rental, maintenance —Support services —Training —Supplies and utilities —Security
2.		Improved data entry —Reduced staff time —Reduced error rates
3.		Improved information technology utilization —Reduced error rates —Improved timeliness
4.		Improved operational effectiveness —Reduced error rates —Improved timeliness —Better quality products —Increased productivity —Expanded capacity of capability
5.		Cost avoidance —Eliminate future staff growth —Eliminate additional equipment requirements —Minimize penalties for delays
ID	Response	Possible Non-Quantitative Benefits
1.		Fulfillment of operating requirements
2.		Better management information
3.		Improved decision-making
4.		Greater versatility or flexibility
5.		Better presentation of information
6.		Improved report generation (timeliness)
7.		Improved staff morale

5 FAH-5 Exhibit H-217.1(5)
COTS and/or GOTS Software Evaluation (Sample)

(TL:ITS-1; 02-13-2002)

1.0 INTRODUCTION

1.1 Purpose

Describe the purpose of the evaluation. Define “what” is to be accomplished.

1.2 Scope

Describe the scope of the evaluation. Put limits around what is to be accomplished. Describe "why" this effort should be done.

1.3 Project Background

Briefly, describe the current situation and the events in recent history leading up to the current situation. Provide the information needed to get the reader up to date on past significant events and to identify the significant players. Specify the impetus for this evaluation. Identify the specific program or projects for which this software is intended. Indicate how the work is currently being performed. State how the software is intended to enhance performance of the program and/or project.

1.4 Project Evaluation Team

Briefly describe the project team and their level of participation in the evaluation.

1.5 Project Evaluation Time Frame

Indicate the actual time frame for the evaluation.

2.0 REQUIREMENTS DEFINITION

2.1 User Requirements

Provide a list of user requirements for this software. List the program or business needs in this section. Some narrative explanation of each item on the list is acceptable.

2.2 Technical Requirements

Provide a list of the requirements relating to the technical aspects of the software. Does the software fit into our automation environment (hardware, software, operating systems, etc.)? Is this the right hardware platform considering file sharing requirements, etc? Consider whether the software will interact with our corporate databases, if needed, or other existing systems. Address the ongoing technical support and training issues.

3.0 EVALUATION RESULTS

Indicate how the product evaluations were conducted and reference the testing procedure.

Provide detailed information on how each product evaluated compared against the original user and technical requirements. List products from highest to lowest score following the example below.

Product 1 Score: 999

Summary of evaluation results for Product 1.

Product 2 Score: 999

4.0 ANALYSIS AND/OR SUMMARY

Provide the analysis that pulls the evaluation together. Discuss major strengths and weaknesses of the software products evaluated, including approximate costs (acquisition, development, maintenance, support, etc.), time to implement, and potential implementation problems. The analysis should also include comments on how well the requirements were met.

5.0 RECOMMENDATIONS

Provide the recommendations based on the analysis and evaluation. If the evaluation and analysis is documented sufficiently, the reader should already have reached the same conclusion.

5 FAH-5 Exhibit H-217.1(6)
Requirements Verification Traceability Matrix (Sample)

(TL:ITS-1; 02-13-2002)

Req. No.	Description	Ref. No	Sec.No.	Page No.
1.	Provide a method to log onto the application using a combination user name (identification code) and password	SOW/D	2.4	5

5 FAH-5 Exhibit H-217.1(7)
System Requirements Document (Sample)

(TL:ITS-1; 02-13-2002)

INTENDED USE: The systems requirements document defines the operational, technical and logistical requirements for the system or end item. Each requirement included in the specification must be verifiable.

INTERRELATIONSHIP: The system requirements document is driven by user requirement. It establishes top-level requirements and is used to flow down these requirements to the design. The system performance specification and interface specification are derived from the system requirements document and system concept of operations.

PREPARATION RESPONSIBILITY: Buyer and/or customer

CONTROL GATE: Final—System Requirements Review (SRR).

1.0 SCOPE

This section states the purpose, scope and structure of the document.

2.0 APPLICABLE DOCUMENTS

This section lists all applicable documents leading to the development of the user requirements for the mission.

3.0 SYSTEM REQUIREMENTS

This section describes the technical or operational requirements. The source, significance, priority, existing capability and deficiencies should be stated for each requirement. Section 3 should contain the following subsections.

Section 3.1—system operation requirements including mission definition, deployment location, schedule, utilization rate, operational life expectancy and existing capability for each requirement.

Section 3.2—system technical requirements including key and important performance requirements, and system effectiveness requirements.

5 FAH-5 Exhibit H-217.1(8)
Concept of Operations (Sample)

(TL:ITS-1; 02-13-2002)

INTENDED USE: The concept of operations document describes the end product and defines what it will consist of in terms of physical building blocks.

INTERRELATIONSHIP: This document is based on system requirements identified in the system requirements document.

CONTROL GATE: SCR—System Concept Review

1.0 Mission Description and System Identification

1.1 System Name and Identification

1.2 System Description

1.3 Functional Description

1.3.1 System Capabilities

2.0 Environment Description

2.1 Operating Environment

2.2 Software and/or Hardware Development and
Maintenance Environment

2.3 Threat Description

3.0 System Architectural Description

3.1 Background, Objectives, and Scope of the Current System
or Situation

3.2 Operational Policies and Constraints for the Current System
or Situation

3.3 Description of the Current System or Situation

3.4 Modes of Operation for the Current System

3.5 User Classes for the Current System

3.5.1 Organizational Structure
3.5.2 Profiles of User Classes
3.5.3 Interactions Among User Classes

3.6 Other Involved Personnel

3.7 Support Environment for the Current System

4.0 Justification for and Nature of Proposed Changes and/or New Features

4.1 Justification for Changes and New Features

4.2 Description of Needed Changes and New Features

4.3 Priorities Among Changes and New Features

4.4 Changes and New Features Considered but Not Included

4.5 Assumptions and Constraints

5.0 Concepts of Operations for the Proposed System

5.1 Background, Objectives, and Scope for the New
or Modified System

5.2 Operational Policies and Constraints

5.3 Description of the Proposed System

5.4 Modes of Operation for the Proposed System

5.5 User Classes for the Proposed System

5.5.1 Organizational Structure
5.5.2 Profiles of User Classes
5.5.3 Interactions Among User Classes

5.6 Other Involved Personnel

5.7 Support Environment for the Proposed System

6.0 Operational Scenarios for the Proposed System

7.0 Summary of Impacts

7.1 Operational Impacts
7.2 Organizational Impacts
7.3 Impacts During Development

8.0 Analysis of the Proposed System

8.1 Summary of Improvements
8.2 Disadvantages and Limitations
8.3 Alternatives and Trade-off Considered

9.0 Notes

Appendices

Glossary

5 FAH-5 Exhibit H-217.1(9)
System Specification Outline (Sample)

(TL:ITS-1; 02-13-2002)

INTENDED USE: The system specification defines the functional, performance and verification requirements for the system or end item. Each requirement included in the specification must be verifiable.

INTERRELATIONSHIP: The system specification defines the functional, performance and verification requirements for the system or end item. Each requirement included in the specification must be verifiable.

PREPARATION RESPONSIBILITY: Buyer

CONTROL GATE: Final—Project specification review (PSR)

PREPARATION INFORMATION:

1. Introduction

A. Scope and purpose of document

B. Overview

1. Objectives

2. Constraints

2. Functional and data descriptions

A. System architecture

1. Architecture context diagram

2. ACD description

3. Subsystem descriptions

A. Architecture diagram specification for subsystem

1. Architecture flow diagram

2. System module narrative

3. Performance issues

4. Design constraints

5. Allocation of system components

B. Architecture dictionary

C. Architecture interconnect diagrams and description

4. System Modeling and simulation results

A. System model used for simulation

B. Simulation results

C. Special performance issues

5. Project Issues

A. Projected development costs

B. Projected schedule

6. Appendices

5 FAH-5 Exhibit H-217.2(1)
Acquisition Plan Outline (Sample)

(TL:ITS-1; 02-13-2002)

INTENDED USE: The acquisition plan defines the buyer’s approach for developing and deploying the system. The Buyer Planning Office prepares the plan after completion of the system performance definition phase.

INTERRELATIONSHIP: The system acquisition plan is derived from user requirements statement, concept definition document, system requirements document and system performance specification. If the system is be procured, the plan drives the source selection plan. If the system is to be developed and deployed by the buyer resources, the plan drives the project plan.

PREPARATION RESPONSIBILITY: Buyer

CONTROL GATE: Initial—Project Plans Review (PPR);
Final—Acquisition Plan Review (APR)

PREPARATION INFORMATION:

1. Scope

1.1 Purpose of system acquisition plan

1.2 Scope of system acquisition plan

1.3 Background of system acquisition plan

2. Applicable Documents

3. System Definition

3.1 System requirements document

3.2 Concept definition document

3.3 System performance specification

4. Scope of Effort in Fiscal Year

These tasks must be identified to the tasks scheduled in Section 7.0

5. Interfaces and Responsibilities

5.1 Technical interfaces and responsibilities

5.2 Organization interfaces and responsibilities

6. Deliverables Provided During FY Delivery Schedule

6.1 Studies

6.2 Documents

6.3 Models

6.4 Hardware

6.5 Software

6.6 Handling Equipment

6.7 Spares, etc.

7. Schedule

7.1 Provide the schedule and the funds required

7.1.1 Source selection phase

7.1.2 Implementation phase

7.1.3 Deployment phase

7.1.4 Operations phase

7.2 The schedule shows CY, FY, month and interim events

7.2.1 RFP preparations

7.2.2 Source selection criteria

7.2.3 RFP release

7.2.4 Proposals receipt

7.2.5 Source selection

8. Personnel Resources Required

Provide a time phased manpower plan required managing the system acquisition in accordance with the system acquisition plan.

9. Funding Required During Fiscal Year

5 FAH-5 Exhibit H-217.2(2)
Quality Assurance Checklist

(TL:ITS-1; 02-13-2002)

INTENDED USE: For a project team and/or an acquisition manager to use when planning or reviewing the quality assurance activities for an acquisition effort. The checklist helps ensure that the appropriate items have been included for effective quality assurance (QA).

Items to Consider	Yes	No	Note
1. Are adequate resources and funding provided for performing the activities?
2. Are members of the QA group trained to perform their QA activities?
3. Are members of the project oriented to the roles, responsibility, authority, and value of the QA group?
4. Is the project performing QA activities according to the plan?
5. Are deviations from the project’s plan being communicated to the project?
6. Is management being notified of deviations that are not being addressed?
7. Are periodic reports of QA activities provided to the project?
8. Are measures of QA status gathered and reported?

5 FAH-5 Exhibit H-217.2(3)
Source Selection Plan Outline (Sample)

(TL:ITS-1; 02-13-2002)

INTENDED USE: The source selection plan (SSP) defines the proposal evaluation and award process used by the buyer procuring organization to procure the O&M support. The SSP describes the source evaluation organization, source evaluation schedule, evaluation criteria and the evaluation process and procedures.

INTERRELATIONSHIP: the system acquisition plan and request drive the SSP for proposal. Evaluation criteria are derived from requirements identified in the system requirements document, proposal specifications and system performance specification.

PREPARATION RESPONSIBILITY: Buyer

CONTROL GATE: Source Selection Initiation Review (SSIR)

PREPARATION INFORMATION:

1. Scope

This section states the purpose, scope, background and structure of the plan.

2. Applicable Documents

This section lists all applicable documents leading to development of the plan.

3. Executive Summary

This section describes the source evaluation and selection organization, evaluation schedule and objectives and approach for the source selection process. It should also describe proposal handling procedures, evaluation team conduct, and use of consultants and the procurement budget. A summary of the evaluation criteria should be provided within this section.

4. Technical Evaluation Team Procedures

This section defines the objectives for evaluating the technical proposal, the evaluation and scoring process and the resulting reports. Topics to be covered include point score ratings, strong, weak and deficient areas, clarifications, final proposal evaluation and identifying technically qualified offerors.

5. Management Evaluation Team Procedures

This section defines the objectives for evaluating the management section of the proposal, the evaluation and scoring process and the resulting reports and recommendations. Topics to be covered include point score ratings, strong, weak and deficient areas, clarifications, final proposal evaluation and identifying qualified offerors in the management area.

6. Cost Proposal Evaluation Team Procedures

This section defines the objectives for evaluating cost proposals, the evaluation and scoring process and the resulting reports and recommendations. Topics to be covered include cost realism analyses, deficiencies, clarifications, final proposal evaluation and identification of qualified offerors in the area of cost.

7. Security Evaluation Team Procedures

This section defines the objectives for evaluating offeror’s security compliance and the resulting reports and recommendations. Topics to be covered include deficiencies, clarifications and identification of offerors not qualified in the area of security.

8. Source Evaluation Board Procedures

This section defines the objectives of the Source Evaluation Board (SEB), the evaluation and selection responsibilities of the Board, offeror discussions, preliminary negotiations and preparation for the Source Selection Authorization Review. The report formats for presenting SEB recommendations should also be included in this section.

Appendices

5 FAH-5 Exhibit H-217.3(1)
Configuration Management Checklist

(CT:ITS-5; 02-05-2013)

INTENDED USE: For a project team, project manager and/or configuration manager to use when planning or reviewing the configuration management activities for a project. The checklist helps ensure that the appropriate items have been included for effective configuration management.

Items to Consider	Yes	No	Note
1. Is there a configuration management (CM) plan for the development effort? Does it include the following: —Roles and responsibilities for CM —Configuration identification activities —Software build activities —Change control activities —Status accounting activities —Audit activities —Reporting and reviews activities —How to integrate changes to items outside the control of the project that affect the items in this project, and vice versa
2. Has someone performed the configuration management activities?
3. Are all configuration items identified and documented?
4. Is there a CM library of baselines?
5. Are changes to baselines controlled?
6. Are baseline audits planned and conducted?
7. Is a documented change control process being followed that supports the following: —Documenting a requested change —Reviewing a requested change by a Configuration Control Board —Examining impact to the project if a change is approved —Modifying project plans to incorporate any approved changes —Tracking a change request from submission to completion
8. Is there a functioning Configuration Control Board, with joint representation of supplier, acquirer, and customer (as appropriate)?
9. Are CM activities reviewed with the project manager?
10. Do quality assurance personnel review CM activities and results?
11. Are measures made to determine status of CM activities?
12. Are issues of interface control between components and outside components being identified and addressed?
13. Other?

5 FAH-5 Exhibit H-217.3(2)
Training Plan Outline (Sample)

(TL:ITS-1; 02-13-2002)

INTENDED USE: The training plan defines the training program required to support the system or end item being delivered.

The concept of operations and maintenance manuals are the driving documents for this plan.

Control Gate: Preliminary—CDR, Final—SAR

1.0 INTRODUCTION

2.0 COURSE DESCRIPTIONS

3.0 COURSE OUTLINE

4.0 STANDARDS AND MEASURES

5.0 TRAINING MATERIAL AND EQUIPMENT

6.0 CERTIFICATION

7.0 SCHEDULE

8.0 APPENDICES

5 FAH-5 Exhibit H-217.3(3)
Change or Configuration Management Checklist

(CT:ITS-5; 02-05-2013)

INTENDED USE: For a project team and/or project manager to evaluate the effectiveness of the projects change management process and how to revise the specific plans. The checklist contains items to consider for documenting change requests, handling them with a configuration or change process, and ensuring approved changes are included in the project deliverables.

Items to Consider	Yes	No	Note
1. Has a request been filed by a member of the project team or by a stakeholder (requirement, change, problem, defect, or other change)?
2. Has the change request been documented?
3. Has the change request been prioritized?
4. Has an approach been identified to handle the change?
5. Has a workaround been identified if the change is not implemented?
6. Has it been acknowledged that the change applies to this project?
7. Has an independent team or member (not the originator) reviewed the change request to determine whether or not it is worth evaluation for action?
8. Has an estimate been developed for the project effort, cost, schedule, and resources?
9. Have the estimates been evaluated and authorized by a Configuration or Change Control Board or other authority?
10. Have the results of the above evaluation been communicated to the requestor?
11. If the change is denied has the requester been notified?
The following steps are to be considered only if authorization for the consideration of the change was given.
12. Has the change been incorporated into the project work plan?
13. Does the incorporation of the change require an adjustment of resources?
14. Does the incorporation of the change require an adjustment to the schedule?
15. Have the changes in the plan been communicated and commitments established?
16. Has the work been performed to address the change?
17. Has the work been reviewed with all effected parties?
18. Have the associated verification activities been performed to ensure correctness?
19. Have revisions been placed under configuration control?
20. Have the change request records been updated to document the changes made?
21. Has the Configuration Control Board been notified that the change has been completed?
22. Have the change request records been updated to reflect completion status?
23. Has the requestor been informed of the final status?
24. Other?

5 FAH-5 Exhibit H-217.3(4)
Project Management Terminology and Control Gates

(TL:ITS-1; 02-13-2002)

CONTROL GATES	PERIOD	DOCUMENTS	RESPONSIBILITY
System Requirements Review (SRR)	Study	User Requirements Statement	Project Manager, Systems Engineer, Project Team, User
System Concept Review (SCR)	Study	Concept of Operations	Project Manager, System Engineer, Project Team, User
Acquisition Plan Review (APR)	Acquisition	Acquisition Plan Work Breakdown Structure (WBS)	Project Manager, System Engineer, Project Team
Source Selection Initiation Review (SSIR)	Acquisition	Request for Proposal, Statement of Work, System Performance Specifications, Source Selection Plan	Project Manager, Project Team, Contracting Officer
Project Initiation Review (PIR)	Acquisition	Implementation Plan, Project Requirements, WBS	Project Manager, Project Team
Test Readiness Review (TRR)	Operations	Test Procedures, Quality Assurance, Security, Verification Plans	COTR, Project Manager, Project Team
Acceptance Review (AR)	Operations	Verification Requirements, Test Results	Project Team
User Acceptance Review (UAR)	Operations	System Validation Report, System Performance	Project Manager

UNCLASSIFIED (U)