![[NASA Logo]](../Images/nasaball.gif) |
NASA Procedures and Guidelines |
||||
This Document is Obsolete and Is No Longer Used.
|
|||||
|
|
|||||
|
|
||||
| | TOC | Preface | Chapter1 | Chapter2 | Chapter3 | Chapter4 | Chapter5 | Chapter6 | AppendixA | AppendixB | AppendixC | AppendixD | AppendixE | AppendixF | AppendixG | ALL | | |||||
The project plan is an agreement between the project manager, program manager, and the Mission Directorate or Mission Support Office. It defines, at a high level, the scope of the project, the implementation approach, the environment within which the project operates, and the baseline commitments of the program and project. The project plan is used by the project Governing Body in the review process and during independent assessments to determine if the project is fulfilling its agreement. The project plan is consistent with the program plan. The project plan is updated and approved during the project life cycle in response to changes in project-level requirements or the baseline commitments.
In this project plan template, all subordinate plans, collectively called control plans, are required. They are based on requirements in NASA NPDs and NPRs that affect program/project planning. The control plans can either be part of the project plan or separate stand-alone documents referenced in the appropriate part of the project plan. In the case of the latter, the project plan contains a summary of and reference to the stand-alone document and the approval authority for the stand-alone control plan is the project manager.
Each section of the project plan is required for all projects. If a section is not applicable to a particular project, indicate by stating so in the appropriate section and provide a rationale. If a section is applicable but the project desires to omit the section or parts of a section, then a waiver must be obtained in accordance with the waiver process for this NPR.
Figure F-1: Project Plan Title Page
F.3 Project Plan Template
[PROJECT NAME] PROJECT PLAN
1.0 PROJECT OVERVIEW
1.1 INTRODUCTION
Briefly describe the background of the project and its current status, including results of formulation activities, decisions, and documentation.
1.2 OBJECTIVES
State the specific project objectives, high-level performance goals, and their relationship to the program objectives. Include performance, schedule, cost, and technology development objectives, as applicable.
1.3 PROJECT DESCRIPTION AND TECHNICAL APPROACH
Describe briefly the project and the project design. Include key characteristics of the project and the key phases and events on the project timeline. Use drawings, figures, charts, etc., for clarification. Describe planned project results, assessment, and reporting. For IT projects, describe the system's relationship to the NASA Enterprise Architecture.
Provide a brief description of the technical approach. Describe the systems to be developed (hardware and software systems, constraints, system interfaces, and facilities). Identify major constraints affecting system development (e.g., cost, schedules, agreements, etc.).
1.4 PROJECT AUTHORITY, GOVERNANCE STRUCTURE, MANAGEMENT STRUCTURE AND IMPLEMENTATION APPROACH
Identify the organization where the project manager resides. Describe the governance structure. Identify the governing body responsible for oversight of the project (e.g., SMC, OMC, PMC, other committee). Describe Centers' responsibilities, if any. Identify the project's Decision Authority. Describe the chain of accountability and decision path that outlines the roles and responsibilities of the project manager, program manager, and other authorities.
Define the relationships among various elements and organizations within the project structure, including all stakeholders, team members, and supporting organizations. Describe the project's approach for fostering effective upward and downward communication of critical management, technical, risk, and safety information. Describe the process that the project will follow to communicate with the program manager, Governing Body, and Decision Authority. Describe briefly the process for problem reporting and subsequent decision making, clearly describing the roles and responsibilities of all organizations. Describe any use of special boards and committees.
Describe the project management structure consistent with the project WBS, including organization and responsibilities, its integration with the parent program management structure, and NASA Center(s) participation. Describe clear lines of authority within the project team and between the project, the program office, the Mission Directorate or Mission Support Office, participating Centers, and other participating organizations. Illustrate the organization graphically.
Describe briefly the implementation approach of the project, including the acquisition strategy (e.g., in-house, NASA Centers, contractor primes), partners, and partner contributions, if appropriate. Describe briefly other program/project dependences with NASA and other agencies, international activities, studies, and agreements. Include make-or-buy plan and trade studies.
1.5 CUSTOMER AND STAKEHOLDER DEFINITION
Describe the customers and stakeholders of the project (e.g., business community, science community, technology community, public, education community, parent program, and Mission Directorate or Mission Support Office sponsor) and the process to be used to ensure customer advocacy within the project.
2.0 PROJECT BASELINE
2.1 REQUIREMENTS BASELINE
Link the objectives described in the previous section to the project-level requirements.
2.2 WBS BASELINE
Provide the project's WBS and WBS dictionary to the Level 2 elements. In developing the WBS, meet the requirements of NID-9250, Identifying Capital Assets and Capturing Their Cost and, for projects which include internal use software, the requirements of NASA's FMR Volume 6, Chapter 4, 041206, Accounting, Property Plant and Equipment, Software Policies and Procedures - Capitalization.
2.3 SCHEDULE BASELINE
Present a summary schedule of the project's integrated master schedule, including all critical milestones, major events, and Agency and project-level reviews throughout the project life cycle. The summary schedule should include the logical relationships (interdependencies) for the critical milestones, major events, project reviews, and critical paths, as appropriate.
2.4 RESOURCE BASELINE
Present the project funding requirements by fiscal year. State the funding in full-cost, real-year dollars for the prior, current, and remaining years. The funding requirements are to be consistent with the project WBS and include funding for all cost elements required by the Agency's full-cost accounting procedures. The funding baseline provides separate funding requirements for each WBS Level 2 element.
Present the project's workforce requirements by fiscal year, consistent with the project funding requirements and WBS. The estimate encompasses all work required to achieve project objectives. Include full accounting of civil service workforce requirements on the providing organizations for the prior (e.g., actuals), current, and remaining years of the project life cycle. Identify, if possible, the elements of work that may be done by contractors and the Centers that perform the work.
Describe the project infrastructure requirements (acquisition, renovations, and/or use of real property/facilities, aircraft, personal property, information technology). Identify means of meeting infrastructure requirements through synergy with other existing and planned programs and projects to avoid duplication of facilities and capabilities. Identify necessary upgrades or new developments, including those needed for environmental compliance.
3.0 PROJECT CONTROL PLANS
3.1 TECHNICAL, SCHEDULE, AND COST CONTROL PLAN
Document how the project plans to control project requirements, technical design, schedule, and cost to achieve its project-level requirements. This control plan will include the following:
a. Describe the plan to monitor the requirements, technical design, schedule, and cost of the project.
b. Describe the project's performance metrics in objective, quantifiable, and measurable terms, and document how the metrics are traced from the project-level requirements. Establish goal and threshold values for the performance metrics to be achieved at each KDP, as appropriate. Establish the thresholds for the difference between the development cost EAC or a schedule milestone listed on the project life cycle chart in Figure 2-4 of this NPR that will trigger a written notice and a recovery plan to the program manager. In addition, document the minimum project success criteria associated with the project-level requirements that, if not met, trigger consideration of a Termination Review.
c. Describe the plan to control the requirements, technical design, schedule, and cost of the project to project-level requirements.
d. Describe how the project will address safety issues, if any, associated with project execution and implementation.
e. Describe the project's implementation of Earned Value Management (EVM). The following requirements apply:
(1) The project's EVM approach is consistent with the participating Center's best practices.
(2) The project's EVM approach is in-place by KDP C and implemented in Phase C through KDP E.
(3) Project EVM reporting begins within 60 days after the start of Phase C.
(4) As a minimum, EVM principles, as defined by ANSI/EIA-748, Earned Value Management Systems, apply from KDP C through KDP E, if the project's life-cycle cost is at or greater than $20M.
(5) If the project's primary NASA Center has a fully validated Earned Value Management System (EVMS), the project uses that system rather than EVM principles.
(6) For contracts and subcontracts, application of an EVMS is required as follows:
(i) For development or production (including flight and ground support) contracts and subcontracts valued at $20M or more, the contractor EVMS must comply with the guidelines in ANSI/EIA-748.
(ii) For development or production (including flight and ground support) contracts and subcontracts valued at $50M or more, the contractor EVMS has been formally determined compliant with ANSI/EIA-748 by the cognizant Federal contract management agency.
(iii) EVM is not required for grants, nondevelopmental level-of-effort engineering support services, steady-state operations, basic and applied research, and routine services such as janitorial services or grounds maintenance services; however, application is at the discretion of the program/project manager.
(iv) A Contract Performance Report (CPR), Integrated Master Schedule (IMS), WBS, and WBS dictionary are required whenever EVM is required on contracts and subcontracts.
(v) In accordance with NFS Part 1834, require IBRs through Phase D for contracts requiring EVM. Schedule such reviews not later than 180 calendar days after contract award or the exercise of significant contract options, or not later than 60 calendar days after a significant funding or work scope realignment.
f. Describe any additional specific tools the project will use to implement the project control processes, e.g., the requirements management system, the project scheduling system, the project information management systems, and the budgeting and cost accounting system.
g. Describe how the project will monitor and control the integrated master schedule.
h. Describe how the project will utilize its technical, schedule, and cost reserves to control the baseline.
i. Describe how the project plans to report technical, schedule, and cost status to the program manager, including frequency and the level of detail.
j. Describe how the project will address technical waivers and how dissenting opinions will be handled.
3.2 RISK MANAGEMENT PLAN
Summarize how the project will implement a continuous risk management process in accordance with NPR 8000.4. Include the initial Significant Risk List and appropriate actions to mitigate each risk. Include hazard analysis to identify safety risks. Projects with international contributions plan for, assess, and report on risks due to international partners and plan for contingencies.
3.3 ACQUISITION PLAN
The Project Acquisition Plan is developed by the project manager and supported by the Center's Office of Procurement. It documents an integrated acquisition strategy that enables the project to meet its objectives, provides the best value to NASA, and complies with the FAR and the NASA FAR Supplement. The Acquisition Plan should:
a. Identify all major proposed acquisitions (such as design studies, hardware and software development, and operations support) in relation to the project WBS. Provide summary information on each such proposed acquisition, including a Contract WBS; major deliverable items; type of procurement (competitive, sole source); type of contract (cost-reimbursable, fixed-price); source (institutional, contractor, other Government organizations); procuring activity; and surveillance approach.
b. Describe completed or planned studies supporting make-or-buy decisions, considering NASA's in-house capabilities and the maintenance of NASA's core competencies.
c. If systems contain software, describe the project's approach for complying with NPR 7150.2.
d. Describe all agreements, memoranda of understanding, barters, in-kind contributions, and other arrangements for collaborative and/or cooperative relationships. List all such agreements (the configuration control numbers and the date signed or projected dates of approval) necessary for project success. Include or reference all agreements concluded with the authority of the project manager and reference agreements concluded with the authority of the program manager and above.
3.4 TECHNOLOGY DEVELOPMENT PLAN
Describe the technology assessment, development, management, and acquisition strategies needed to achieve the project's objectives. In the Technology Development Plan:
a. Describe how the project will assess its technology development requirements, including how the project will evaluate the feasibility, availability, readiness, cost, risk, and benefits of the new technologies.
b. Describe how the project will identify opportunities for leveraging ongoing technology efforts.
c. Describe the project's alternative development strategies for technologies that do not mature as expected.
d. Describe how the project will remove technology gaps, including maturation, validation, and insertion plans, quantifiable milestones, decision gates, and resources required.
e. Describe briefly how the project will ensure that all planned technology exchanges, contracts, and partnership agreements comply with all laws and regulations regarding export control and the transfer of sensitive and proprietary information.
3.5 REVIEW PLAN
Summarize the project's approach for conducting a continuum of reviews for the project life cycle, including peer reviews. Explain the reporting requirements for project reviews. Provide the management, technical, schedule, cost, and other criteria, which will be utilized in the consideration of a termination review.
For IT projects, use Appendix G of this document for guidance to provide the names, purposes, content, and timing of the critical milestone project reviews.
3.6 INFORMATION AND CONFIGURATION MANAGEMENT PLAN
Describe the configuration management approach that the project team will implement. Describe the structure of the configuration management organization and tools to be used. Describe the methods and procedures to be used for configuration identification, configuration control, interface management, configuration traceability, and configuration status accounting and communications.
Describe the project's approach to knowledge capture, as well as the methods for contributing knowledge to other entities and systems. This includes the development and maintenance of an electronic project library.
Describe the program's approach to capturing lessons learned in accordance with NPR 7120.6.
3.7 IT SECURITY PLAN
Describe the project's plans for ensuring security and address the following elements:
a. IT Security Requirements: Document the project's approach to implementing IT security requirements in accordance with NPR 2810.1.
3.8 DATA CONVERSION PLAN
Describe the plan that the project will execute to ensure that required data from existing electronic and/or manual systems are included in the new information system, including at a minimum the following elements:
a. Emergency Response Requirements: Describe the project's emergency response plan in accordance with NPR 1040.1, NASA Continuity of Operations (COOP) Planning Procedural Requirements, which defines the range and scope of potential crises and specific response actions, timing, of notifications and actions, and responsibilities of key individuals.
b. The scope of the data conversion plan as it relates to the project.
c. An overview of security considerations associated with the data conversion, including the IT security categorizations of the data to be converted.
d. A description of the data, including its IT security categorization that will be converted from existing systems (electronic and manual) to the new systems.
e. A description of data cleansing or other operations that will be conducted on the data prior to its conversion.
f. A description of the data, including its IT security categorization, that will not be moved from existing systems (electronic and manual) to the new system, with rationale for not moving the data to the new system
g. A description of how the data that will not be moved to the new system will be dispositioned in accordance with the requirements of NPR 1441.1 and other Agency requirements.
h. A description of the tools, facilities, and approaches that will be used for converting data from existing systems to the new systems.
i. Roles and responsibilities of organizations that will perform data conversion.
j. A description of how the project will determine that the data have been converted successfully, including the role of the data owner in ensuring successful conversion.
k. The timeframes for when data conversion will begin and when it will be completed, following the life-cycle designations of this document and integrated with the overall project schedule.
l. Methods (e.g., meetings and communications) for keeping all organizations informed about the status of the data conversion plan.
3.9 EXPORT CONTROL PLAN
Describe how the project will comply with U.S. export control laws and regulations and NASA's Export Control Program as documented in NPR 2190.1. It should describe the partners' (international, contractors, universities) roles and responsibilities, show the schedule of anticipated transfers, describe a plan to comply with NASA export-control transfer requirements (identification and classification of controlled data/articles, exemptions/exceptions, licensing, documentation, recordkeeping, and reporting). Project managers must consult with the NASA Export Administrator/Center Export Administrator during plan development.
4.0 WAIVERS LOG
Identify those requirements for which a waiver has been requested and approved consistent with project characteristics such as scope, complexity, visibility, cost, safety, and acceptable risk and provide rationale and approvals.
5.0 CHANGE LOG
Track and document changes to the project plan.
6.0 APPENDICES
Appendix A - Acronyms
Appendix B - Definitions
| TOC | Preface | Chapter1 | Chapter2 | Chapter3 | Chapter4 | Chapter5 | Chapter6 | AppendixA | AppendixB | AppendixC | AppendixD | AppendixE | AppendixF | AppendixG | ALL | |
| | NODIS Library | Program Formulation(7000s) | Search | |