ImageVerifierCode 换一换
格式:PDF , 页数:233 ,大小:9.41MB ,
资源ID:1017440      下载积分:10000 积分
快捷下载
登录下载
邮箱/手机:
温馨提示:
如需开发票,请勿充值!快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。
如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝扫码支付 微信扫码支付   
注意:如需开发票,请勿充值!
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【http://www.mydoc123.com/d-1017440.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(REG MSFC-HDBK-3684-2013 PROJECT PLANNING AND CONTROL HANDBOOK.pdf)为本站会员(ideacase155)主动上传,麦多课文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知麦多课文库(发送邮件至master@mydoc123.com或直接QQ联系客服),我们立即给予删除!

REG MSFC-HDBK-3684-2013 PROJECT PLANNING AND CONTROL HANDBOOK.pdf

1、National Aeronautics and MSFC-HDBK-3684Space Administration BASELINE EFFECTIVE DATE: February 26, 2013George C. Marshall Space Flight CenterMarshall Space Flight Center, Alabama 35812CS40PROJECT PLANNING AND CONTROLHANDBOOKApproved for Public Release; Distribution UnlimitedCHECK THE MASTER LIST VERI

2、FY THAT THIS IS THE CORRECT VERSION BEFORE USE at https:/repository.msfc.nasa.gov/docs/multiprogram/MSFC-SPEC-3684Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-MSFC Technical StandardCS40Title: Project Planning and Control HandbookDocument No.: MSF

3、C-HDBK-3684 Revision: BaselineEffective Date: February 26, 2013 Page 2 of 233DOCUMENT HISTORY LOGStatus (Baseline/Revision/Cancelled)Document RevisionEffective DateDescriptionBaseline 2/26/2013 Baseline Release. Document is authorized through MPDMS.CHECK THE MASTER LIST VERIFY THAT THIS IS THE CORRE

4、CT VERSION BEFORE USE at https:/repository.msfc.nasa.gov/docs/multiprogram/MSFC-SPEC-3684 Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-MSFC Technical StandardCS40Title: Project Planning and Control HandbookDocument No.: MSFC-HDBK-3684 Revision: Ba

5、selineEffective Date: February 26, 2013 Page 3 of 233TABLE OF CONTENTS1. INTRODUCTION 101.1 BACKGROUND AND PURPOSE 101.2 SCOPE. 111.3 REFERENCE DOCUMENTS . 132. RELATIONSHIP OF PP and in the case of projected over-runs, determine the amount of technical content that should be removed from the projec

6、t, or the amount of reserves that should be utilized, to meet budget, schedule, and minimum success criteria. Mission support analysis and strategic planning is critical to ensure that MSFC is providing the optimum workforce, facilities, and infrastructure required for current and future Center proj

7、ects, and to identify and mitigate cross-cutting risks to mission success.Managing the development and operations of the Centers missions with limited resources is one of the most significant challenges facing MSFC today. The result of effective project management and mission support execution is th

8、e delivery and successful completion of the program / project /activity within the specified limits of cost, schedule, technical, and risk management. The manager for the given area is responsible for the outcome, and is closely supported by a deputy manager, and possibly a technical manager (or chi

9、ef engineer, lead systems engineer, etc.), a Chief Safety Officer, and a project business manager (or Project Control manager, PP proposed and agreed to project scope changes; proposed or agreed to risks and associated actions; etc. MSFC-HDBK 3173, Project Management and Systems Engineering Handbook

10、, was developed to provide guidance and best practices for the project management and systems engineering disciplines. This companion handbook provides PP however, the emphasis of this handbook is to describe the processes necessary for project and mission support business management. The MSFC Assoc

11、iate Director for Management is the executive sponsor for the PP financial accountability; Earned Value Management (EVM); workforce assessment; programmatic analysis and reporting; and the technical, quality, risk, and configuration change aspects affecting PP however, all have a life-cycle that beg

12、ins by maturing a concept into a specific scope and set of requirements that define a project deliverable. These requirements drive a design phase that leads to product fabrication, integration, and testing. Many project products culminate into space flight and operation. NASA Headquarters is organi

13、zed into major mission and support directorates that manage portfolios of programs and supporting projects. MSFC work ranges from very large projects to much smaller activities, which are referred to and managed as projects by Center personnel and follow the same project life-cycle.The project life-

14、cycle management process receives oversight from a Governing Project Management Council (GPMC). Depending on the project size and complexity, the GPMC may be the MSFC Center Management Council (CMC), a MSFC project directorate, an Agency Mission Directorate, or the Agency Program Management Council.

15、 After initial project authorization approval is granted, projects formalize their life-cycle phases, life-cycle gates, and major events such as key project reviews. Single-project programs and MSFC projects follow the project life-cycle and its associated decision gates and major events as shown in

16、 Figure 2. Each type will follow the associated requirements as specified in Marshall Procedural Requirements (MPR) 7120.1, MSFC Engineering and Program/Project Management Requirements.A Key Decision Point (KDP) is the event where the Decision Authority (DA) determines the readiness of a project to

17、progress to the next phase of the life-cycle. KDPs for projects are labeled with capital letters (e.g., KDP A). Transition to a following phase occurs immediately following KDP approval except for transition from Phase D to E where transition occurs following on orbit checkout and initial operations

18、.2.1.1 Project FormulationDuring project formulation (Pre-Phase A, Phase A, and Phase B), PP approved risk list with an evaluation of cost and schedule impacts associated with approved risk mitigation; and cost, schedule, and risk assessment of any approved project design changes as a result of the

19、PDR that is conducted during this phase) for the KDP C review that are required to demonstrate that the technical challenges, major risks, and the cost and schedule are sufficiently understood, and stakeholder expectations and formulation requirements have been met. By approving the project, the DA

20、commits the budget resources necessary to continue into implementation. 2.1.6 Project ImplementationThe role of PP CHECK THE MASTER LIST VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE at https:/repository.msfc.nasa.gov/docs/multiprogram/MSFC-SPEC-3684 Provided by IHSNot for ResaleNo reproduction

21、 or networking permitted without license from IHS-,-,-MSFC Technical StandardCS40Title: Project Planning and Control HandbookDocument No.: MSFC-HDBK-3684 Revision: BaselineEffective Date: February 26, 2013 Page 18 of 233assessment and decisions associated with identified risks; and reporting of resu

22、lts to project stakeholders.2.1.7 Phase C: Final Design and FabricationDuring Phase C, the project completes the design that meets the detailed requirements and begins fabrication of test and flight architecture (e.g., flight article components, assemblies, and subsystems). These activities focus on

23、 implementing the project in accordance with the Project Plan, completing the final design, and assuring that the systems engineering activities are performed to determine if the design is mature enough to proceed with full-scale implementation. Phase C is focused toward the Critical Design Review (

24、CDR) and the System Integration Review (SIR). Completion of Phase C culminates in KDP D. Project costs (labor, equipment, test facilities, etc.) peak at the end of Phase C and early into Phase D; therefore, unexpected problems and delays are most costly (and critical to be resolved as quickly as pos

25、sible) during this time. 2.1.8 Phase D: System Assembly, Integration, Test, Launch, and CheckoutDuring Phase D, the project performs system assembly, integration, test, launch, and system checkout activities. These activities focus on preparing for the System Acceptance Review (SAR),Operational Read

26、iness Review (ORR), Flight Readiness Review (FRR) for human space flight projects or the Mission Readiness Review (MRR) for robotic space flight projects. KDP D marks the decision to conduct launch and early on-orbit operations, launch, and the Post-Launch Assessment Review (PLAR). Entrance and succ

27、ess criteria for PLAR and all major project technical reviews are documented in MPR 7123.1, MSFC Systems Engineering Processes and Requirements, Appendix E.The transition to Phase E occurs after on-orbit checkout at the conclusion of the PLAR. PP and 2. Provide recommendations for avoiding a repetit

28、ion (or obtaining a repeat of a success). The recommendations merely provide pointers to subject matter experts on measures that have worked in the past. PP accounting; and economic principles and techniques.b. Understanding of project objectives, content (technical, budget, schedule, and risks), ke

29、y milestones, and interrelationships.c. Ability to maintain status and cost estimates, and assess programmatic trends for project elements at all levels.d. A high degree of analytical ability.e. Ability to integrate, analyze, and understand project elements and how they fit together.f. Ability to id

30、entify high risk areas and their relationship/impact on the technical, budget, and schedule baseline.g. Ability to identify and clearly communicate the issues to management.3.1.3 Characteristics of PP changes to it should be formally approved by the project office.i. Not all top-level WBS elements w

31、ill be subdivided to the same level of detail. As associated element risk, cost, and/or complexity increases, further breakdown may be necessary.3.2.1 WBSThe work content contained in the project scope of work is analyzed and used to develop a WBS by hierarchically decomposing the work. This analysi

32、s and iterative decomposition results in thedevelopment of the WBS, the WBS Dictionary, and the project organization structure to meet the requirements, and identification of the functions and activities required by the scope. The WBS Dictionary and the scope are cross-referenced to ensure that all

33、required work is captured in the WBS Dictionary, and there is no “work” in the dictionary that is not in the approved scope definition.A WBS is developed early in the project development cycle. It identifies the total project work to be performed, which includes not only all MSFC in-house work conte

34、nt, but also all work content to be performed by contractors, international partners, universities, or any other performing entities. Work scope not contained in the project WBS should not be considered part of the project. The WBS divides the work content into manageable elements, with increasing l

35、evels of detail. The WBS is a product-oriented family tree that identifies the hardware, software, services, and all other deliverables required to achieve an end project objective. The purpose of a WBS is to subdivide the projects work content into manageable segments to facilitate planning and con

36、trol of cost, schedule, and technical content. It will serve as the basis for uniform planning, progress and performance reporting, project visibility and communication, and the assignment of responsibility. The WBS will be updated, as required, to reflect changes to the technical content and contra

37、ctual changes.The PM, in conjunction with the PP the trademark software backbone of the NASA Accounting System) to be used as the accounting charge numbers for tracking project funding and costs.CHECK THE MASTER LIST VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE at https:/repository.msfc.nasa.g

38、ov/docs/multiprogram/MSFC-SPEC-3684 Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-MSFC Technical StandardCS40Title: Project Planning and Control HandbookDocument No.: MSFC-HDBK-3684 Revision: BaselineEffective Date: February 26, 2013 Page 26 of 233

39、3.2.2 WBS Coding: NSM SystemThe NSM System is the internal coding schema used by the Agency to define and organize project work content. The WBS with its NSM nomenclature provides a common management framework for project management decisions and communication, the definition and authorization of wo

40、rk, the development of project schedules, and the planning and allocation of resources. This same coding system is also used to account for all financial activities associated with funds appropriated by Congress to accomplish project work. When developing a project WBS, the management team,assisted

41、by PP RS40 for CMO functions). Additional information regarding the MdM system may also be obtained by contacting the MdM Help Desk (mdmhelpdeskhq.nasa.gov). All modifications made to existing WBS element codes contained in Agency management systems listed above should also first be initiated and ap

42、proved through the MdM System. A WBS code that has been approved and officially entered into the MdM System cannot be removed. This restriction enhances a projects ability to maintain accurate historical project data. MdM interfaces with the Budget and Funds Allocation System (BFAS) for management o

43、f authorized Center projects and WBSs.3.2.3 Preparing WBS Element Tree DiagramsWBS tree diagrams are routinely developed to provide a visual display of a WBS. A pictorial view of the overall WBS aids all project staff in understanding how lower-level project components support and contribute to high

44、er-level components. This type of diagram is often called a “product tree” diagram.An example of a WBS tree diagram is shown in Figure 5, which reflects a portion of a Flight Project WBS structure with several key recommended development practices noted.The degree to which WBS elements are decompose

45、d or extended is governed by the following:a. Sponsors reporting requirements.b. Level where elements of work are managed and performed by one line organization.c. Subcontractor work.d. Risk, complexity, and criticality of elements of work to meet project requirements.e. Cost of the elements of work

46、.f. Visibility needed by management for controlling the element of work.g. Limitations of the NASA Accounting System and the NSM coding structure.Note: For additional information, see NASA/SP-2010-3404, NASA Work Breakdown Structure (WBS) Handbook, http:/evm.nasa.gov/handbooks.html, (refer to paragr

47、aph 3.4.3, Preparing Element Tree Diagrams.)CHECK THE MASTER LIST VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE at https:/repository.msfc.nasa.gov/docs/multiprogram/MSFC-SPEC-3684 Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-MSFC Technical St

48、andardCS40Title: Project Planning and Control HandbookDocument No.: MSFC-HDBK-3684 Revision: BaselineEffective Date: February 26, 2013 Page 28 of 233FIGURE 5. Partial Project WBS Element TreeNote: Recommended WBS development practices shown in red.3.2.4 WBS DictionaryThe PM, EMs, and responsible Man

49、agement Leads develop the WBS Dictionary that is maintained by the business management team or PP&C. The WBS dictionary provides a description of work and identifies each Control Account (CA). The WBS Dictionary (see Figure 6) does not replace the scope contained in the Project Plan, Space Act Agreements (SAA), or Intra-Agency/Center Work Agreements, but provides a logical cross-reference and traceability between th

copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
备案/许可证编号:苏ICP备17064731号-1