第四章 第五章（简单版）合格的项目经理 优秀的项目经理 组织结构对项目的影响(1） 足够的知识。(2） 丰富的项目管理经验(3） 良好的协调和沟通能力(4） 良好的职业道德(5） 一定的领导和管理能力 (l）真正理解项目经理的角色。(2）领导并管理项目团队(3）依据项目进展的阶段，组织制订详细程度适宜的项目计划，监控计划的执行，并根据实际情况、客户要求或其他变更要求对计划的变更进行管理。(4）真正理解“一把手工程”
(5）注重客户和用户参与职能型组织 项目型组织 矩阵型组织
(1） 强大的技术支持，便于知识、技能和经验的交流。(2） 清晰的职业生涯晋升路线。(3） 直线沟通、交流简单、责任和权限很清晰。(4） 有利于重复性工作为主的过程管理。
缺点：职能利益优先于项目，横向之间的联系薄弱、部门间沟通、协调难度大：项目经理极少或缺少权利、权威；项目管理发展方向不明，缺少项目基准等。
1、结构单一，责权分明，利于统一指挥2、目标明确单一3、沟通简洁方便4、决策快
缺点：管理成本过高，如项目的工作量不足则资源配置效率低：项目环境比较封闭，不利于沟通、技术知识等共享；员工缺乏事业上的连续型和保障等。
(1） 项目经理负责制、 有明确的项目目标。(2） 改善了项目经理对整体资源的控制。(3） 及时响应。(4） 获得职能组织更多的支持。(5） 最大限度地利用公司的稀缺资源。(6） 降低了跨职能部门间的协调合作难度。(7） 使质量、 成本、 时间等制约因素得到更好的平衡。(8） 团队成员有归属感， 士气高， 问题少。(9） 出现的冲突较少， 且易处理解决。
缺点：管理成本增加；多头领导：难以监测和控制；资源分配与项目优先的问题产生冲突；权利难以保持平衡等。
PMO 特点（作用）） PMO 职责 瀑布模型(1） 在所有 PMO管理的项目之间共享和协调资源。(2） 明确和制定项目管理方法.(3） 负责制订项目方针、流程、模板和其他共享资料。(4） 为所有项目进行集中的配置管理。(5）对所有项目的集中的共同风险和独特风险存储库加以管理(6） 项目工具（如企业级项目管理软件〉的实施和管理中心。
(7） 项目之间的沟通管理协调中心。(8）对项目经理进行指导的平台。(9）通常对所有PMO 管理的项目的时间基线和预算进行集中监控。(10）在项目经理和任何内部或外部的质量人员或标准化组织之间协调整体项目的质量标准。 1、建立组织内部项目管理的支撑环境2、提高组织项目管理能力3、培养项目管理人员4、提供项目指导和咨询5、项目组合管理 项目需求明确、充分了解拟交付的产品、有厚实的行业实践基础、整批一次性交付产品有利于干系人。特点。(1）从上一项开发活动接受其成果作为本次活动的输入。(2）利用这一输入，实施本次活动应完成的工作内容。(3）给出本次活动的工作成果，作为输出传给下一项开发活动。(4）对本次活动的实施工作成果进行评审。V 模型 项目立项 项目建议书
关键词：延续 膝盖 吉祥 扁担 P209单元——编码集成——接口详细系统——系统验收——用户 项目建议、项目可行性分析项目审批、项目招投标项目合同谈判 项目简介项目建设单位概况项目建设的必要性业务分析总体建设方案本期项目建设方案环保、 消防、 职业安全项目实施进度投资估算和资金筹措效益与风险分析简化版：项目必要性项目的市场预测产品方案或服务市场预测项目建设必要条件
项目可行性分析 项目论证 项目合同内容1、投资必要性2、技术可行性3、财务可行性4、组织可行性5、经济可行性6、社会可行性7、风险因素及对策 1、项目财务评价2、项目技术评价3、项目财务评价4、项目国民经济评价5、项目环境评价6、项目运行环境评价7、项目社会影响评价8、项目不确定性和风险评价9、项目综合评价 1、当事人各自权利和义务2、项目费用及工程款的支付方式3、项目变更约定4、保密约定5、违约责任6、损害赔偿7、当事人的法律资格8、质量验收标准9、验收时间10、技术支持服务
11、合同附件12、法律公正
作为整合者，项目经理必须 项目章程的作用 项目工作说明书关键词：平衡 整合(1） 通过与项目干系人主动、全面的沟通，来了解他们对项目的需求。(2） 在相互竞争的众多干系人之间寻找平衡点。(3） 通过认真、细致的协调工作，来达到各种需求间的平衡，实现整合。 (1） 确定项目经理，规定项目经理的权力。(2） 正式确认项目的存在， 给项目一个合法的地位。(3） 规定项目的总体目标， 包括范围、时间、成本和质量等。(4） 通过叙述启动项目的理由 ，把项目与执行组织的日常经营运作及战略计划等联系起来。 1、业务需求：一个组织的业务需求可能是培训、市场需求、技术进步、法律需求或者政府标准；2、产品范围描述：记录项目所要创建的产品的需求，以及产品或服务的特征；3、战略计划：执行组织要把战略计划作为项目选择的一个要素来考虑；
项目章程内容 项目管理计划作用 项目管理计划制订的步骤口诀：目的目标要概括进度预算要审批项目发起人给项目经理授权(1） 概括性的项目描述和项目产品描述。(2） 项目目的或批准项目的理由， 即为什么要做这个项目。(3） 项目的总体要求， 包括项目的总体范围和总体质量 要求。
(4） 可测量的项目目标和相关的成功标 准。(5） 项目的主要风险， 如项目的主要风险类别。(6） 总体里程碑进度计划。(7） 总体预算。(8） 项目的审批要求， 即在项目的规划 、执行、 监控和收尾过程中， 应该由谁来做出哪种批准.(9） 委派的项目经理及其职责和职权。(10）发起人或其他批准项目章程的人员
的姓名和职位。
(l） 指导项目执行、 监控和收尾。(2） 为项目绩效考核和项目控制提供基准。(3） 记录制订项目计划所依据的假设条件。(4） 记录制订项目计划过程中的有关方案选择。(5） 促进项目干系人之间的沟通。(6） 规定管理层审查项目的时间、 内容和方式 (l）各具体知识领域制订各自的分项计划。(2）整体管理知识领域收集各分项计划，整合成项目管理计划。(3）用项目管理计划指导项目的执行和监控工作，并在执行过程中监控。(4） 对提出的必要的变更请求，报实施整体变更控制过程审批。(5）根据经批准的变更请求，更新项目管理计划。
第六章 整体管理
项目管理计划内容 变更请求可能包括： 变更控制流程背诵思路：项目管理过程-实施程度-工具技术-过程-过程管理-执行完成-监督控制-配置管理计划-绩效基线-干系人-生命周期模型-关键管理评审(l）所使用的项目管理过程。(2）每个特定项目管理过程的实施程度。(3）完成这些过程的工具和技术的描述。(4）项目所选用的生命周期及各阶段将
采用的过程。(5）如何用选定的过程来管理具体的项目。包括过程之间的依赖与交互关系和基本的输入和输出(6）如何执行工作来完成项目目标及对项目目标的描述。(7）如何监督和控制变更， 明确如何对变更进行监控。(8）配置管理计划， 用来明确如何开展配置管理。(9）对维护项目绩效基线的完整性的说
明。(10）与项目干系人进行沟通的要求和技术。(11)为项目选择的生命周期模型。(12）为解决某些遗留问题和未定的决策， 对于其内容、 严重程度和紧迫程度进行的关键管理评审常见问题：
1、计划应组织相关干系人一起制定；2、计划内容不充分；3、 计划没有评审 ， 没有得到干系人的一致认同；4、项目已变更，计划未更新；5、没有处理好内部依赖和制约；6、执行不到位；
(l）纠正措施。为使项目工作绩效重新与项目管理计划致而进行的有目的的活动。(2）预防措施。为确保项目工作的未来绩效符合项目管理计划而进行的有目的的活动。(3）缺陷补救。为了修正不致的产品或产品组件而进行的有目的的活动。(4）更新。对正式受控的项目文件或计划等进行的变更，以反映修改或增加的意见和内
容 1、书面申请；2、PM 和团队评估变更影响（范围，进度， 成本，质量等）并将影响通知干系 人；3、CCB 按流程审批；4、变更审批不通过，则取消变更，纳入监控；变更审批通过则调整和更新项目管理计划和项目文件，并通知干系人；5、根据要求执行变更，记录变更实施情况；6、验证变更，归档；
整体变更控制包括下列变更活动 项目行政收尾结果 行政收尾与合同收尾区别(1）识别可能发生和已经发生的变更。(2）确保只有己批准的变更才能被实施。(3）评审并批准变更申请。(4）变更申请流程来管理己批准的变更。(5）管理基线的完备性(6）评审并审批所有书面的纠正措施和预防措施。(7）根据已批准的变更， 控制并更新
项目的范围、成本、预算、进度和质量需求，进行协调。(8）要记录变更申请的所有影响。(9）验证缺陷修复的正确性。(IO）质量使其符合标准。识别 1 2两评两管 3 4 5 6协调 7记录验证 8 9符合 10 (1） 对项目产品的正式接受。(2） 完整的项目档案。(3） 组织过程资产更新〈经验教训总结〉。(4） 资源释放〈包括人力和非人力资源〉。 ①行政收尾是针对项目和项目各阶段的， 不仅整个项目要进行一次行政收尾， 而且每个项目阶段结束时都要进行相应的行政收尾：而合同收尾是针对合同的， 每 个合同需要而且只需要进行一次合同收尾。②从整个项目说， 合同收尾发生在行政收尾之前；如果是以合同形式进行的项目，在收尾阶段，先要进行采购审计和合同收尾，然后进行行政收尾。③从某一个合同的角度说， 合同收尾中又包括行政收尾工作（合同的行政收尾）。’④行政收尾要由项目发起人或高级管理层给项目经理签发项目阶段结束或项目整 体结束的书面确认， 而合同收尾则要由整体管理常见问题 变更问题与措施 变更应对措施：
1、没有制定项目的整理管理计划；2、没有制定有效的范围和需求管理子计划；3、没有制定合理的整理变更流程及需求变更控制流程；4、对客户的需求获取不充分；5、需求分析工作不充分，缺乏需求定义环节，没有定义出需求规则说明书；6、缺乏需求验证环节，没有请客户代表一起进行需求评审；7、没有求得干系人对需求的一致理解；
8、没有求得干系人对需求的承诺；9、没有有效的管理变更控制；10、范围没有管好，导致不断的范围蔓延；11、未能做好评进度管理，范围变更时没有充分评估对进度等其他方面的影响，导致进度延误；
常见问题：1、未制定标准的变更管理流程；2、未书面记录变更；3、未充分评估变更影响；4、未成立 CCB（CCB 未包括客户）5、未及时更新项目管理计划及文件；6、未及时与干系人沟通；7、未验证和监控变更；8、未纳入变更管理以及配置管理系统中 应对措施：1、建立规范的变更控制流程；2、书面申请和记录变更；3、应充分评估变更影响；4、应建立 CCB，包含客户等干系人；5、及时更新项目计划和文件；6、及时与干系人沟通变更影响和结果；7、变更后要验证和监控变更；8、纳入变更管理以及配置管理系统中
第七章 范围管理范围管理计划要对下列工作的管理过程做出规定： 需求管理计划内容 需求文件的主要内容(1）制定详细项目范围说明书。(2）根据详细项目范围说明书创建WBS.(3）维护和批准工作分解结构（WBS）。(4）正式验收己完成的项目可交付成果。(5）处理对详细项目范围说明书或
WBS 的变更。该工作与实施整体变更控制过程直接相联。 (1） 收集需求过程。(2） 如何规划、跟踪和报告各种需求活动。(3） 配置管理活动(4） 需求优先级排序过程。(5） 用来反映哪些需求属性将被列入跟踪矩阵的跟踪结构。(6） 产品测量指标及使用这些指标的理由。 ①业务需求，包括：可跟踪的业务目标和项目目标、执行组织的业务规则、组织的指导原则。②干系人需求，包括：对组织其他领域的影响、对执行组织内部或外部团体的影响、干系人对沟通和报告的需求。③解决方案需求，包括：功能和非功能需求、技术和标准合规性需求、支持和培训的需求、质量需求、报告需求（可用文本记录或用模型展示解决方案需求，也可两者同时使用）。④项目需求，例如：服务水平、绩效、安全和合规性，以及验收标准。⑤过渡需求。⑥与需求相关的假设条件、依赖关系和制约因素。项目范围说明书 WBS 的作用和意义 WBS 表示形式主要有以下两种
(l）项目目标(2）项目边界(3）项目需求(4）产品范围描述(5）项目的制约因素(6）假设条件(7）项目的可交付成 (l）项目范围分解开来， 使项目相关人员对项目一目了然，能够使项目的概况和组成明确、 清晰、 透明和具体。(2）保证了项目结构的系统性和完整性。(3）通过工作结构分解， 可以建立完整的项目保证体系，(4）明确项目相关各方的工作界面， 便于责任划分和落实。(5）进度计划和控制的工具。(6）为建立项目沟通管理提供依据， 便于把握信息重点。
(7）是项目各分计划和控制措施制定的基础和主要依据。(8）有助于防止需求和范围蔓延。
(1）分级的树型结构树型结构图的 WBS 层次清晰，非常直观，结构性强， 但是不容易修改， 对于大型的、 复杂的项目也很难表示出项目的全景。 由于其直观性，一般在一些小的、适中的应用项目中用得较多。(2）表格形式能够反映出项目所有的工作要素，可是直观性较差。但在一些大型的、复杂的项目中使用还是较多的，内容分类较多、容量较大，这种形式有如下特点：
①每层中的所有要素之和是下一层的工作之和。②每个工作要素应该具体指派一个层次，而不应该指派给多个层次。③工作分解结构需要有投入工作的范围描述，使项目团队成员对要完成的工作有全面了解。
项目工作分解为工作包步骤 工作结构分解应把握如下原则： 分解 WBS 结构的三种方法(l）识别和分析可交付成果及相关工作。(2）确定 WBS 的结构和编排方法。(3）自上而下逐层细化分解。(4）为 WBS 组件制定和分配标识编码。(5）核实可交付成果分解的程度是否恰当。 (1）在层次上保持项目的完整性，避免遗漏必要的组成部分。(2）一个工作单元只能从属于某个上层单元，避免交叉从属。(3）相同层次的工作单元应用相同性质。(4）工作单元应能分开不同的责任者和不同的工作内容。(5）便于项目管理计划和项目控制的需要。(6）最底层工作应该具有可比性，是可管理的，可定量检查的。
(7）应包括项目管理工作，包括分包出去的工作。 1、使用项目生命周期的阶段作为分解的第一层，把项目可交付物安排在第二层；2、把项目重要的可交付物作为分解第一层；3、把子项目安排在第一层，再分解子项目的WBS；确认范围的般步骤： 范围变更控制程序(1） 确定需要进行确认范围的时间。(2） 识别确认范围需要哪些投入。(3） 确定范围正式被接受的标准和要
素。(4） 确定确认范围会议的组织步骤。(5） 组织确认范围会议。
范围管理常见问题 应对措施 范围变更原因1、没有制定范围管理计划或安排不合理；2、没做好需求分析、调研等工作；3、项目范围说明书内容不全或者项目范围定义不充分4、缺少范围确认等环节或项目需求、设计没有得到用户评审5、没有及时评估客户提出的变更要求对项目带来的影响，且未与客户及时沟通；
6、变更没有规范变更流程；7、项目变更实施前没有及时变更合同；8、变更结果没有得到客户的确认；9、范围控制存在问题；10、没有有效的范围管理，造成二次变更； 1、做好范围规划工作；2、组织干系人制定可行的范围管理计划；3、采用多种方式充分收集需求；4、对项目范围清晰定义，并根据定义对工作进行分解，制定 WBS；5、对项目进行合理估算，对工作量有量化的把握；6、做好有效的范围管理工作；7、对范围进行有效控制；8、制定规范的整体变更控制流程，有变更走流程，防止范围蔓延；9、充分与客户沟通； 1、项目外部环境发生变化，例如，政府政策的问题；2、项目范围的计划编制不周密详细，有一定的错误或疏漏；3、市场上出现了或者设计人员提出了新技术、新手段或新方案；4、项目实施组织本身发生变化；5、客户对项目、项目产品或服务的要求发生变化；
第八章 进度管理确定依赖关系 储备分析 关键链法1、强制性依赖关系。强制性依赖关系是法律或合同要求的或工作的内在性质决定 的依赖关系。2、选择性依赖关系。选择性依赖关系有时又称首选逻辑关系、优先逻辑关系或软逻辑关系。3、外部依赖关系。外部依赖关系是项目活动与非项目活动之间的依赖
关系。4、内部依赖关系。内部依赖关系是项目活动之间的紧前关系，通常在项目团队的控制之中。 应急储备：1、包含在成本基准内的一部分预算2、用来应对已经接受的己识别风险 “己知一未知”风险3、应急储备通常是预算的一部分4、可以为某个具体活动建立应急储备，也可以为整个项目建立应急储备5、项目经理有使用权管理储备：1、预留出的项目预算不包含在成本基准内。2、应对项目范围中不可预见的工作。 “未知一未知” 风险3、属于项目总预算和资金需求的一部分4、高层管理者审批5、当动用管理储备时，就要把动用的管理储备增加到成本基准中， 从而导致成本基准变更。 项目缓冲，放置在关键链末端，用来保证项目不因关键链的延误而延误。接驳缓冲，放置在非关键链与关键链的接合点，用来保护关键链不受非关键链延误的影响。关键链法不再管理网络路径的总浮动时间，而是重点管理剩余的缓冲持续时间与剩余的活动链持续时间之间的匹配关系。
资源优化技术 进度压缩 进度控制关注如下内容资源平衡（Resource Leveling）。为了在资源需求与资源供给之间取得平衡，根据资源制约对开始日期和结束日期进行调整的一种技术。资源平衡往往导致关键路径改变，通常是延长。资源平滑（ResourceSmoothing）。 使项目资源需求不超过预定的资源限制的一种技术。
资源平滑不会改变项目关键路径，完工日期也不会延迟。活动只在其自由浮动时间和总浮动时间内延迟。资源平滑技术可能无法实现所有资源的优化。 赶工。 通过增加资源， 以最小的成本增加来压缩进度工期的一种技术。 赶工的例子包括： 批准加班、增加额外资源或支付加急费用， 来加快关键路径上的活动。赶工只适用于那些通过增加资源就能缩短持续时间的， 且位于关键路径上的活动。 赶工并非总是切实可行， 它可能导致风险和／或成本的增加。快速跟进。 种进度压缩技术， 将正常情况下按顺序进行的活动或阶段改为至少是部分并行开展。例如，在大楼的建筑图纸尚未全部完成前就开始建地基。快速跟进可能造成返工和风险增加。 它只适用于能够通过并行活动来缩短项目工期的情况。 Cl）判断项目进度的当前状态；(2）对引起进度变更的因素施加影响，以保证这种变化朝着有利的方向发展：(3）判断项目进度是否已经发生变更；(4）当变更实际发生时严格按照变更控制流程对其进行管理。
进度控制步骤 缩短工期的方法 进度涉及工具与技术(l）分析进度，找出哪些地方需要纠正措施(2）确定采用哪些技术纠正措施(3）修改计划，将纠错列入计划(4）重新估算项目进度，评估纠正结果成本估算不准原因1、在项目范围未确定时就进行了成本估算；
2、过于乐观或保守的估计；3、信息系统需求变化大，目标不明确；4、复杂的信息，需要考虑的因素多；5、缺乏同类项目参考；6、缺乏专业和有经验的人才；7、技术的变化；8、管理层的压力； (l）赶工，投入更多的资源或增加工作时间，以缩短关键活动的工期；(2）快速跟进，并行施工，以缩短关键路径的长度：(3）使用高素质的资源或经验更丰富的人员；(4）减小活动范围或降低活动要求：(5）改进方法或技术，以提高生产效率；(6）加强质量管理，及时发现问题，减少返工，从而缩短工期。 1、估算活动资源工具与技术：专家判断、备选方案分析、发布的估算数据、项目管理软件、自下而上估算；2、估算活动持续时间工具与技术：专家判断、类比估算、参数估算、三点估算、群体决策技术、储备分析；3、制定进度计划工具与技术：进度网络分析、关键路径法、关键链法、资源优化技术、建模技术、提前量与滞后量、进度压缩、进度计划编制工具；4、进度控制工具与技术：绩效审查、项目管理软件、资源优化技术、建模技术、提前量与滞后量、进度压缩、进度计划编制工具进度落后常见问题 进度问题解决办法 进度压缩的方法（案例思路）1、团队成员没有及早参与，需求分
析时间耗时长，要早期参与项目；2、经验不足，进度计划制定不准，没有采取有效的历时估算方法和网络计划技术制定进度计划3、考虑项目期间特定时期会对进度产生影响；4、没有及时让开发部参与项目早期工作，需求分析耗时长；5、项目经理经验不足，进度估算不准确，资源与配置不足；6、没有充分利用分配项目资源；
7、在安排进度时未考虑法定节假日；8、仅仅依靠某项目来估算项目的历时估算根据不充分；9、没有对项目的技术方案、沟通计划进行详细的评审、需求没有经过确认；10、增加人员经验不足，沟通存在问题，加班使得人员的工作效率降低。 进度落后 成本超支：用高效率人员代替低效率人员，赶工或并行施工追赶进度成本超支 进度超前：抽调部分人员，放慢工作进度。采取措施控制成本，必要的时候调整成本基准进度落后 成本正常：增加高效人员投入，赶工或者并行施工追加进度.进度超前 成本正常：抽调部分人员，增加少量骨干人员
进度正常 成本正常：维持现状，加强质量控制
1、与客户一起评估绩效，修订和变更进度计划；2、申请增加资源，或使用经验丰富的员工；3、加强培训，提升资源利用率；4、优化网络图，重新排列活动顺序，快速跟进并行活动，压缩关键路径长度；5、临时加班（赶工），补救耽误的时间；6、将部分工作串行改并行，内部流程优化；7、在允许的情况下，调配非关键路径资源用于关键路径任务；8、加强可交付成果的检查和控制，避免返
工；9、优化外包、采购能环节；10、加强项目干系人沟通；
第九章 成本管理项目成本失控原因 成本的类型 应急储备和管理储备1、组织制度不健全；2、项目经理或团队成员缺乏成本意识，缺乏责任感，随意开支，铺张浪费；3、项目成本估算不合理或估算不准；4、对成本控制的特点认识不足；5、成本控制方法有问题，没有及时纠偏；6、技术的制约；
7、范围控制不足，导致成本增加；8、进度拖延，导致成本增加；9、对质量要求过于苛刻，导致成本增加； 1）可变成本：随着生产量、工作量或时间而变的成本为可变成本。可变成本又称变动成本2）固定成本：不随生产量、工作量或时间的变化而变化的非重复成本为固定成本。(3）直接成本：直接可以归属于项目工作的成本为直接成本。如项目团队差旅费、工资、项目使用的物料及设备使用费等。(4）间接成本：来自一般管理费用科目或几个项目共同担负的项目成本所分摊给本项目的费用，就形成了项目的间接成本，如税金、额外福利和保卫费用等。(5）机会成本： 是利用一定的时间或资源生产一种商品时， 而失去的利用这些资源生产其他最佳替代品的机会就是机会成本，泛指一切在做出选择后其中一个最大的损失。(6）沉没成本： 是指由于过去的决策已经发生了的，而不能由现在或将来的任何决策改变的成本。 沉没成本是一种历史成本， 对现有决策而言是不可控成本， 会很大程度上影响人们的行
为方式与决策， 在投资决策时应排除沉没成本的干扰。
应急储备：6、包含在成本基准内的一部分预算7、用来应对已经接受的己识别风险 “己知一未知”风险8、应急储备通常是预算的一部分9、可以为某个具体活动建立应急储备，也可以为整个项目建立应急储备10、项目经理有使用权管理储备：6、预留出的项目预算不包含在成本基准
内。7、应对项目范围中不可预见的工作。“未知一未知” 风险8、属于项目总预算和资金需求的一部分9、高层管理者审批10、当动用管理储备时， 就要把动用的管理储备增加到成本基准中， 从而导致成本基准变更。
成本估算步骤 成本估算依据 制订项目成本预算步骤1、识别并分析成本的构成科目；2、根据已识别的科目，估算每一科目成本大小；3、分析成本估算结果，找出可以互相替代的成本，协调各种成本之间的比例关系 口诀：三文件，两说明关于估算依据的文件（如估算是如何编制的〉；关于全部假设条件的文件：关于各种己知制约因素的文件：对估算区间的说明（如＂100万元土 10%”就说明了预期成本的所在区间〉：对最终估算的置信水平的说明。 (1）将项目总成本分摊到项目工作分解结构的各个工作包。分解按照自顶向下，根据占用资源数量多少而设置不同的分解权重。(2）将各个工作包成本再分配到该工作包所包含的各项活动上。(3）确定各项成本预算支出的时间计划及项目成本预算计划。 主要根据资源投入时间段形成成本预算计划。项目的成本预算为衡量项目绩效情况提供
了基准。
成本控制主要内容 缩短工期的方法 公式汇总口诀：因素变更要处理管理限额两监督未批超支干系人Cl）对造成成本基准变更的因素施加影响；(2）确保所有变更请求都得到及时处理：(3）当变更实际发生时，管理这些变更；(4）确保成本支出不超过批准的资金限
额，既不超出按时段、按 WBS 组件、按活动分配的限额，也不超出项目总限额：(5）监督成本绩效，找出并分析与成本基准间的偏差：(6）对照资金支出，监督工作绩效；(7）防止在成本或资源使用报告中出现未经批准的变更：(8）向有关干系人报告所有经批准的变更及其相关成本；(9）设法把预期的成本超支控制在可接
受的范围内。
(l）赶工，投入更多的资源或增加工作时间，以缩短关键活动的工期；(2）快速跟进，并行施工，以缩短关键路径的长度：(3）使用高素质的资源或经验更丰富的人员；(4）减小活动范围或降低活动要求：(5）改进方法或技术，以提高生产效率；(6）加强质量管理，及时发现问题，减少返工，从而缩短工期。 PV：计划要花的钱EV：实际完成的工作计划花的钱AC：实际支出的钱CV：成本偏差CV=0：计划和实际花费一致CV>0：：结余CV<0：超支SV：进度偏差SV=0：项目按计划进行
SV>0：进度超前SV<0：：进度落后CPI：成本绩效指数CPI=1：计划和实际花费一致CPD>1：结余CPI1：进度超前
SPI<1：进度落后完工预测：BAC、ETC、EAC、TCP I 的概念：BAC：项目完工总预算ETC：完工尚需估算EAC：完工估算TCPI：完工尚需绩效指数3.默写公式：CV：CV=EV-ACSV：SV=EV-PV
CPI：CPI=EV/ACSPI：SPI=EV/PVETC(非典型) ：ETC=BAC-EVETC(典型) ：ETC=(BAC-EV) /CPI如果题干说按此进度，就是以后还会出现这样的情况，就是典型的。如果题干说不再出现这样的问题或是说已经改过来了，就是非典型的。EAC：EAC=ETC+AC
EAC(SPI 和 CPI 同时影响) ：EAC=AC+ETC /(CPISPI)VAC：VAC=BAC-EACTCPI：非典型：TCPI=(BAC-EV)/(BAC-AC)典型： TCPI=(BAC-EV)/(EAC-AC)
第十章 质量管理质量与等级的区别 质量管理的发展史 质量成本法质量：作为实现的性能或成果， 是一系列内在特性满足要求的程度” 。等级：作为设计意图， 是对用途相同但技术特性不同的可交付成果的级别分类 手工艺人时代质量检验阶段统计质量控制阶段全面质量管理阶段
质量审计审计目标 七种基本质量工具—老七工具 七种基本质量工具—新七工具Cl）识别全部正在实施的良好及最佳实践：(2） 识别全部违规做法、差距及不足；(3） 分享所在组织或行业中类似项目的良好实践；(4） 积极、主动地提供协助， 以改进过程的执行， 从而帮助团队提高生产效率：(5） 强调每次审计都应对组织经验教训的积累做出贡献。 ①因果图： 又称鱼骨图或石川馨图（分析寻找原因）②流程图，也称过程图，用来显示在一个或多个输入转化成一个或多个输出的过程中（分析寻找原因）③核查表，又称计数表，是用于收集数据的查对清单④帕累托图， 用于识别造成大多数问题的少数
重要原因。 （2/8 原则问题）⑤直方图， 条形图， 描述集中趋势、 分散程度和统计分布形状。 不考虑时间对分布内的变化的影响。⑥控制图， 确定过程是否稳定，规范上限和下限，可允许的最大和最小值⑦散点图又称相关图 ①亲和图。亲和图与心智图相似。（强调一切以数据说话）②过程决策程序图（PDPC）：帮助团队预测那些可能破坏目标实现的中间环节。（遇见故居障碍）④ 树形图。它也称系统图⑤ 优先矩阵。用来识别关键事项和合适的备选方案，并通过系列决策，排列出备选方案的优先顺序。
⑥ 活动网络图。过去称为箭头图。活动网
络图连同项目进度计划编制方法起使用，
如计划评审技术（PERT）、关键路径
法（CPM）和紧前关系绘图法（PDM）。
⑦ 矩阵图。种质量管理和控制工具
过程改进计划 QA质量保证人员职责 项目质量控制（QC)）步骤1. 过程边界2 .过程配置2. 过程测量指标3. 绩效改进目标 (1)计划阶段制定质量管理计划和相应的质量标准。(2)按计划实施质量检查，是否按标准过程实施项目工作。注意项目过程中的质量检查，每次进行检查之前准备检查清单，并将质量管理相关情况予以记录。(3)依据检查的情况和记录，分析问题，发现问题，与当事人协商解决。问题解决后要进行验证，如果无法与当事人达成一致，应报告项目
经理或更高层领导，直至问题解决。(4)定期给项目干系人发质量报告。(5)为项目组成员提供质量管理要求方面的培训或指导 (1) 选择控制对象。(2)为控制对象确定标准或目标。(3)制订实施计划，确定保证措施。(4)按计划执行。(5)对项目实施情况进行跟踪监测、检查，并将监测的结果与计划或标准相比较。(6) 发现并分析偏差。(7)根据偏差采取相应对策：如果监测的实际情况与标准或计划相比有明显差异，则应采取相应的对策。质量常见问题 解决措施1、没有制定切实可行的质量管理计划；
2、没有建立质量保证体系、缺乏质量标准和规范；3、质量职责分配不合理，没有QA 或QA 不独立于项目组，或 QA 没有全程参与项目；4、未实施质量保证活动，或质量保证活动实施不到位；5、质量控制缺少必要的评审和测试等环节；6、质量控制方法不合理，效果不佳；7、项目经理在质量管理方面经验不足，
QA 经验不足；8、在质量管理中没有采用合适的工具、技术和方法；9、仅向用户提交测试报告而没有提交全面质量管理进展情况报告。10、未设置需求评审、阶段评审、技术评审等工作11、缺乏有效的沟通
1、应科学制定和实施质量管理计划；2、应建立项目的质量管理体系，包括制定可行的过程规范和质量目标、质量标准；3、应使用有相关行业经验，项目经验和质量管理经验的质量保证人员；4、应重视软件开发过程中的质量保证工作，采用相应的工具和技术，避免将检查、测试作为质量保证的唯一方法；5、应加强需求和设计方案的评审和质量控制工作；6、重视软件项目的测试环节，安排必要的
时间，采用合理方法进行充分测试；7、应加强项目实施过程中的配置管理8、对发现的缺陷进行统计分析，确保软件质量，提出合理有效的质量整改措施；9、为项目组成员提供质量管理要求方面的培训；10、加强与客户在质量管理方面的沟通和交流
第十一章 人力资源项目人力资源计划 虚拟团队 多维决策分析1) 角色和职责的分配2) 项目的组织结构图3) 人员配备管理计划人员配备管理计划：1、人员招募；2、资源日历，表明每种具体资源
的可用工作日和工作班次的日历；3、人员遣散计划，事先确定项目团队成员遣散的时间和方法，对项目和组员都说有好处的；4、培训需求；5、认可与奖励；6、遵守的规定；7、安全性 ①在公司内部建立一个由不同地区员工组成的团队② 为项目团队增加特殊技能的专家， 即使这个专家不在本地。③ 把在家办公的员工纳入虚拟团队， 以协同工作。④ 由不同班组〈早班、中班和夜班〉员工组成⑤ 把行动不便或残疾的员工纳入团队。⑥可以实施那些原本因为差旅费用过高而被忽略的项目缺点， 例如， 可能产生误解、有孤立感、团队成员之间难以分享知识和经验、采用通信技术也要花费成本等。 ①可用性。 团队成员能否在项目所需时段内为项目工作， 在项目期间内是否存在影响可用性的因素。②成本。 聘用团队成员所需的成本是否在规定的预算内。③ 经验。团队成员是否具备项目所需的相关经验。④ 能力。团队成员是否具备项目所需的能力。⑤ 知识。 团队成员是否掌握关于客户、类似项目和项目环境细节的相关知识。⑥ 技能。 团队成员是否具有相关的技能， 来使用项目工具， 开展项目执行或培训。⑦ 态度。 团队成员能否与他人协同工作， 以形成有凝聚力的团队。团队建设目标 成功的项目团队的特点 优秀的团队 5 个阶段
1、提高项目团队的个人技能，以提高他们完成项目活动的能力，与此同时降低成本，缩短工期，改进质量并提高绩效；2、提高项目团队成员之间的信任感和凝聚力，以提高士气，降低冲突，促进团队合作；3、创建动态，团队合作的团队文化，以促进个人与团队的生产率，团队精神和团队协作，鼓励团队成员之间交叉培训和切磋以共享经验和知识； (1） 团队的 目标明确，成员清楚自己的工作对目标的贡献。(2） 团队的组织结构清晰， 岗位明确。(3） 有成文或习惯的工作流程和方法，而且流程 简明有效。(4） 项目经理对团队成员有明确的考核和评价标准，工作结果公正公开、赏罚分明。(5） 共同制订并遵守的组织纪律。(6） 协同工作，也就是一个成员工作需要依赖于另一个成员的结果， 善于总结和学习 (1）形成阶段（Forming）： 一个个独立的个体成员转变为团队成员，开始形成共同目标，对未来团队往往有美好的期待。(2）震荡阶段（Storming）： 团队成员开始执行分配的任务，一般会遇到超出预想的困难，希望被现实打破。个体之间开始争执，互相指责，并且开始怀疑项目经理的能力。(3）规范阶段（Norming）： 经过一定时间的磨合，团队成员之间相互熟悉和了解，矛盾基本解决， 项目经理能够得到团队的
认可。(4）发挥阶段（Performing）： 随着相互之间的配合默契和对项目经理的信任，成员积极工作，努力实现目标(5）结束阶段（Adjourning）： 随着项目的结束，团队也被遣散了。
冲突的特点 产生冲突的原因 冲突管理的 6 种方法①冲突是自然的， 而且要找出一个解决办法。②冲突是一个团队问题，而不是个人问题③应公开地处理冲突。④冲突的解决应聚焦在问题， 而不是人身攻击。⑤冲突的解决应聚焦在现在， 而不是过去。 1、项目的高压环境；2、责任模糊；3、多个上级存在；4、新科技的流行；5、对稀缺资源的争抢6、进度优先级的不同7、每个人不同的工作方式与风格 (1 ） 问 题 解 决 （ ProblemSolving IConfrontation）。冲突各方一起积极地定义问题、收集问题的信息、制定解决方案，选择个最合适的方案来解决冲突，此时为双赢或多赢。(2）合作CCollaborating）。集合多方的观点和意见，得出一个多数人接受和承诺的冲突解决方案。(3）强制（Forcing）。以牺牲其他各方的观点为代价，强制采纳一方的观点。
(4）妥协（Compromising）。冲突的各方协商并且寻找一种能够使冲突各方都有一定程度满意、让步的冲突解决方法。(5）求同存异（Smoothing/Accommodating）。冲突各方都关注他们一致的面，而泼化不一致的一面(6）撤退（Wi 也 drawing/Avoiding）。撤退就是把眼前的或潜在的冲突搁置起来，从冲突中撤退。X 理论 y 理论 团队建设的工具与技术
(1）人天性好逸恶劳，只要有可能就会逃避工作。(2） 人生来就以自我为中心，漠视组织的要求。(3） 人缺乏进取心，逃避责任，甘愿昕从指挥 ，安于现状，没有创造性。4）人们通常容易受骗，易受人煽动。(5）人们天生反对改革。
X 理论的领导：在领导工作中必须对员工采取强制、惩罚和解雇等手段强迫员工努力工作，对员工应当严格监督、控制和 管理。 在领导行为上应当 实行高度控制和集中管理，在领导风格上采用独裁式的领导方式。
(1） 人天生并不是 好逸恶劳，他们热爱工作，从工作得到 满足感和成就感(2） 下属能够自我确定目标， 自我指挥和自我控制(3） 在适当的条件下， 人们愿意主动承担责任。(4） 大多数人具有一定的想象力和创造力。(5）在现代社会中， 人们的智慧和潜能只是部分地得到了发挥。
Y 理论的管理：采取民主型和放任自由型的领导方式， 在领导行为上道循以人为中心的、 宽容的及放权的领导原则， 使下属目标和组织目标很好地结合起来， 为员工的智慧和能力的发挥创造有利的条件。 1、人际关系技能；2、培训；3、团队建设活动；4、基本规则；5、集中办公；6、认可与奖励；7、人事测评工具
人力资源管理 常见问题1、缺乏项目管理能力和经验；2、没有进入管理角色，疏于项目管理；3、兼职过多，时间和精力不够，顾此失彼；4、组建团队出现问题，招募不到合适的项目成员；5、建设团队出现问题，没有及时组织有效的团队建设活动；
6、管理团队出现问题，没有及时发现冲突，或没有进行良好的冲突管理；7、目标不明确，没有制定共同遵守的规则，团队氛围不积极，职责分配不明确；8、缺乏培训，或培训占用太多精力；9、人员流动过于频繁；10、缺乏有效的沟通；
第十二章 沟通和干系人管理沟通渠道计算 沟通管理计划 项目例会主要议题(1）干系人的沟通需求(2） 针对沟通信息的描述，包括格式、内容、详尽程度等。(3） 发布信息的原因。(4） 负责信息沟通工作的具体人员。(5） 负责信息保密工作的具体人员的授权。(6） 信息接收的个人或组织。
(7） 沟通渠道的选择。(8） 信息传递过程中所需的技术或方法。(9） 沟通所必须的各种资源，包括时间和预算。(10）沟通频率，( 11）上报过程，(12）对沟通管理计划更新与细化的方法。(13）通用词语表、术语衰。(14，项目信息流向图、工作流程图、授权顺序、报告清单，会议计划等。(14）沟通过程中可能存在的各种制约因素(15）沟通工作指导以及相关模板。
(16）有利于有效沟通的其他方面，
(1） 项目进展程度调查和汇报；(2） 项目问题的解决：(3） 项目潜在风险的评估；(4） 项目团队人力资源协调。
项目总结会议 干系人分析步骤 干系人权力／利益方格示例(I）了解项目全过程的工作情况以及相关的团队或成员的绩效状况；(2） 了解出现的问题并提出改进措施；(3） 了解项目全过程中出现的值得吸取的经验并进行总结；(4） 对总结过后的文档进行讨论，通过后就存入公司的知识库，从而形成公司的知识积累 (1）识别全部潜在项目干系人及其相关信息(2）识别每个干系人可能产生的影响或提供的支持， 并把他们分类， 以便制定管理策略。①权力／利益方格② 权力／影响方格③影响／作用方格④凸显模型(3） 评估关键干系人对不同情况可能做出的反应或应对，以便策划如何对他们施加影响， 提高他们的支持和减轻他们的潜在负面影响
干系人登记册内容 干系人管理计划(1） 基本信息如干系人的姓名、职位、地点、 项目角色、 联系方式。(2）用于评估的干系人信息如主要需求、 主要期望、 对项目的潜在影响、与生命周期的哪个阶段最密切相关(3）干系人分类如关键干系人／非关键干系人、内部／外部、支持者／中立者／反对者等 (1）关键干系人的所需参与程度和当前参与程度：(2） 干系人变更的范围和影响：(3） 干系人之间的相互关系和潜在交叉；(4） 项目现阶段的干系人沟通需求；(5） 需要分发给干系人的信息，包括语言、格式、内容、详细程度和发送频率：(6） 分发相关信息的理由，以及可能对干系人参与所产生的影响：
(7） 随着项目的进展，更新和优化干系人管理计划的方法。沟通问题答题要点 如何改进沟通答题要点1，和干系人一起制定沟通管理计划2，识别干系人分析沟通需求3，沟通渠道选择4，沟通技术和方法5，沟通的频率
6，沟通情况记录7，控制沟通（面对面会议、问题解决、绩效状况、总结会议）8，对不同干系人的需要分别识别，记录和分析 1、建立沟通管理计划；2、使用项目管理信息系统；3、建立沟通基础设施；4、使用项目沟通模版；5、把握项目沟通的基本原则；6、发展更好的沟通技能；7、把握人际沟通风格；8、进行良好的冲突管理；9、有效的会议；10、集中办公，作战室；
第十四章采购管理采购管理几个过程 采购管理计划 工作说明书(1）编制采购管理计划。决定采购什么，何时采购，如何采购，还要记录项目对于产品、服务或成果的需求，并且寻找潜在的供应商。(2）实施采购。从潜在的供应商处获取适当的信息、报价、投标书或建议书。选择供方，审核所有建议书或报价，在
潜在的供应商中选择，并与选中者谈判最终合同。(3 ）控制采购。管理合同以及买卖双方之间的关系，监控合同的执行情况。审核并记录供应商的绩效以采取必要的纠正措施，并作为将来选择供应商的参考。管理与合同相关的变更。(4 ）结束采购。完结单次项目采购的过程。 (1 ）合同类型：(2 ）风险管理事项：(3 ）评估标准(4 ）项目管理团队本身能采取哪些行动：(5 ）采购文件(6 ）如何管理多个供应商：(7 ）如何协调采购与项目的其他方面(8 ）可能对计划的采购造成影响的约束和假定：(9 ）如何处理提前订货期(10 ）如何进行“自制／外购”决策，(11 ）可交付成果的日期安排(12 ）如何确定履约保证金(13 ）如何为卖方提供指导(14 ）如何确定用于采购或合同工作说明书的形式和格式：(15 ）如何识别卖方：(16 ）如何管理合同 对项目所需要提供的产品、成果或服务的描述。前言、方法假定服务范围、交付资料、完成标准、顾问组人员变更管理服务期限和工作量估计、双方角色和责任、、收费和付款方式、工作说明书是对项目所要提供的产品或服
务的叙述性的描述：项目范围说明书则通过明确项目应该完成的工作来确定项目的范围。采购文件 供方选择标准1、得到卖方报价建议书2、为实施、控制、结束采购提供依据方案邀请书（ RFP ）报价邀请书（ RFQ ）投标邀请书( IFB ）
招标通知洽谈邀请征求供应商意见书（ R F I)承包商初始建议征求书 (1）对于需求的理解(2）生产能力和兴趣(3）业务规模和类型(4）卖方过去的业绩(5 ）技术能力(6 ）技术方案(7 ）管理方案(8 ）财务实力(9 ）证明文件。(10）知识产权。(11 ）风险(12 ）担保(13 ）所有权(14）总成本或者全生命周期成本
第十五章配置管理作用：配置管理是为了系统地控制配置变更，在系统的整个生命周期中维持配置的完整性和可跟踪性配置管理几个过程 建立基线好处（作用）） 配置管理员（CMO）口诀：计识制，状态审计不付制定配置管理计划配置标识配置控制
配置状态报告配置审计发布管理和交付 (1 ）基线为开发工作提供了一个定点和快照。(2 ）新项目可以在基线提供的定点上建立。(3 ）当认为更新不稳定或不可信时，基线为团队提供取消变更方法。(4 ）可以利用基线重新建立基于某个特定发布版本的配置，以重现已报告的错误。 编写配置管理计划：配置项识别版本管理和配置控制；配置状态报告：配置审计；发布管理和交付：建立和维护配置管理系统；建立和维护配置库：建立和管理基线：对项目成员进行配置管理培训。（配置管理 6 个活动）建个系统建个库建个基线做培训配置管理计划的主要内容 配置标识步骤 配置变更流程(1 ）配置管理活动，覆盖的主要活动包
捂配置标识、配置控制、配置状态报告、配置审计、发布管理与交付：(2 ）实施这些活动的规施和流程：(3 ）实施这些活动的进度安排：(4 ）负责实施这些活动的人员或组织。 (1 ）识别需要受控的配置项(2 ）为每个配置项指定唯一性的标识号：(3 ）定义每个配置项的重要特征：(4 ）确定每个配置项的所有者及其责任；(5 ）确定配置项进入配置管理的时间和条件：(6 ）建立和控制基线：(7 ）维护文档和组件的修订与产品版本之间的关系。 1. 变更申请2. 变更评估3. 通告评估结果4. 变更实施5. 变更验证与确认6. 变更的发布7. 基于配置库的变更控制
配置管理的内容 配置管理计划步骤1、 信息文档的规范管理（文档的分类和规范）规范：文档书写规范、图表编号规则、文档目录编写标准、文档管理制度2、 配置项识别3、 配置项状态（草稿、正式、修改）4、 配置项版本号（0.YZ、X.Y 、X.YZ）5、 配置项版本管理6、 配置基线
7、 配置库（开发库/动态库、受控库/主库、产品库/静态库）8、 配置库的权限设置9、 配置控制委员会（CCB 不以人数作为规定，而是以能否代表干系人的利益作为原则）10、配置管理员 CMO 1、 制定配置管理计划2、 配置标识3、 配置控制4、 配置状态报告5、 配置审计6、 发布管理和交付配置管理答题思路 配置解决方法1 、没有制定完善配置管理计划，明确相关的规程、标准。
2 、没有建立合理配置管理流程3 、未能建立配置管理系统4 、没有设置 CMO 岗位进行配置管理5 、未能做好配置识别与建立基线6 、没有做好配置项的版本管理，版本管理混乱错误丢失。7 、未能严格控制配置项的操作权8 、没有做好配置项的变更控制，没有标准统一的配置变更流程。9 、变更后的配置项没有经过评审10 、没有依据配置状态报告和干
系人进行有效的沟通11 、没有做好配置管理过程的配置审计12 、没有做好发布交付和管理
1 、建立标准的信息系统文档管理规范2 、建立和维护配置管理系统3 、制定配置管理计划4 、做好配置项的版本管理5 、对配置库进行有效的管理和分类6 、做好配置库的操作权限分配7 、 设立 CMO 在项目整个生命周期中做好配置管理8 、做好配置标识识别9 、配置控制阶段制定统一的配置管理变更流程10 、有效的记录配置状态报告
11 、 依据配置状态报告与干系人做好配置管理的沟通12 、做好配置管理的功能和物理审计13 、做好配置的发布管理和发布14 、对项目成员做好配置管理的培训15 、建立并和维护配置库16 、对修改的配置基线要做好评审工作
第十八章风险管理风险管理计划 风险识别的原则 识别风险的工具与技术1)方法论2)角色与职责3) 预算4) 时间安排5) 风险类别6)风险概率和影响的定义7) 概率和影响矩阵。
8) 修订的干系人承受力9) 报告格式10)跟踪 (1)由粗及细，由细及粗。(2)严格界定风险内涵并考虑风险因素之间的相关性。(3)先怀疑，后排除。(4)排除与确认并重。对于肯定不能排除但又不能肯定予以确认的风险按确认考虑。(5)必要时，可作实验论证。 1.文档审查：对项目文档进行结构化审查2. 信息收集技术包括：①头脑风暴；②德尔菲技术 ③访谈；④根本原因分析；3. 核对单分析4. 假设分析5.图解技术：①因果图，又称石川图或鱼骨图，用于识别风险的起因；②系统或过程流程图，显示系统各要素之间的相互联系及因果传导机制；③影响图，用图形方式表示变量与结果之间的因果关系、事件时间顺序及其他关系；6. SWOT分析：优势、劣势、机会、威胁7.专家判断实施定性风险的工具与技术 消极影响（威胁）
积极影响（机会） 应对措施 实施定量风险的工具与技术1. 风险概率和影响评估：风险进度、成本、质量或性能潜在影响2. 概率和影响矩阵：风险值=风险发生的概率风险发生后的后果3.风险数据质量评估：4.风险分类5.风险紧迫性评估6.专家判断 项目目标产生消极影响（威胁）：高风险（深灰色）区域：采取优先措施和激进的应对策略 。处于低风险(中度灰色〉区域的威胁：作为观察对象列入风险登记册或增加应急储备，不必采取主动管理措施。项目目标产生积极影响（机会）：高风险（深灰色）区域的机会：最易实现且能够
带来最大利益的，抓住。对于低风险（中度灰色）区域的机会：则应加以监督。 1、 数据收集和展示技术①访谈②概率分布 （贝塔分布、三角分布）2、定量风险分析和建模技术 ①敏感性分析（龙卷风图）②预期货币价值（EVM ）分析，是当某些情况在未来可能发生或不发生时， 计算平均结果的一种统计方法 （不确定性下的分析） 。该技术常在决策树分析中使用。 ③建模和模拟，蒙特卡洛技术3、专家判断
消极风险或威胁的应对策略 积极风险或威胁的应对策略 控制凤险的工具与技术1) 规避：采取行动来消除威胁，保护项目免受风险影响的风险应对策略。通常包括改变项目管理计划，以完全消除威胁。延长进度、改变策略、缩小范围2) 转移：把威胁造成的影响连同应对责任一起转移给第三方。保险、履约保函、担保书、保证书3)减轻：采取行动降低风险发生的概率
采用不太复杂的流程、进行更多的测试、选择更可靠的供应商，在系统中加入冗余部件4)接受：该策略可以是被动或主动的主动接受策略是建立应急储备 1)开拓：如果组织想要确保机会得以实现，就可对具有积极影响的风险采取 本策略。2)提高：提高机会的发生概率和积极影响。尽早完成活动增加资源。3) 分享：应对机会的部分或全部责任分配给最能为项目利益抓住该机会的第三方。例如建立风险共担的合作关系和团队。4)接受：机会发生时乐于利用，但不主动追求机会。（主动接受） 1.风险再评估：2.风险审计：检查记录风险应对措施有效性，以及风险管理过程的有效性3.偏差和趋势分析 （挣值分析）4.技术绩效测量5.储备分析6.会议
第十九 项目收尾管理项目收尾管理工作的内容： 项目验收阶段工作内容 系统集成项目文档包括如下部分：(1)项目验收工作(2)项目总结工作(3)系统维护工作(4)项目后评价工作（团队成员的后续工作） 1. 验收测试2. 系统试运行3. 系统文档验收4. 项目终验 (1）系统集成项目介绍：(2）系统集成项目最终报告：(3）信息系统说明手册；(4）信息系统维护手册：(5）软使件产品说明书、质量保证书等。
项目总结的主要意义如下。 项目总结会应讨论如下内容。 项目后评价的内容/意义：Cl）了解项目全过程的工作情况及相关的团队或成员的绩效状况。(2）了解出现的问题并进行改进措施总结。(3）了解项目全过程中出现的值得吸取的经验并进行总结。(4）对总结后的文档进行讨论，通过后即存入公司的知识库，从而纳入企业的
过程资产。 (1) 项目绩效(2) 成本绩效(3) 技术绩效(4) 进度计划绩效(5) 项目的沟通(6) 识别问题和解决问题(7) 意见和建议项目、成本、技术、进度计划 (1)信息系统目标评价(2)信息系统实施过程 评价（前期论证阶段、 招投标阶段、 开发建设阶段、运营维护阶段）(3)信息系统效益评价(4)信息系统可持续性 评价项目后评价意义：(1)通过项目活动实践的检查总结 ，确定项目预期的目标是否达到 ，项目规划是否合理有效，项目的主要效益指标是否实现；(2)通过分析评价 找出成败 的原因 ，总结经验教训；(3)通过及时有效的信息反馈 ，为提高未来
新项目的决策水平和管理水平提供基础 ；(4)为后评价项目实施运营中出现的问题 提出改进建议，从而达到提高投资效益的目的。
需求管理的问题 需求管理问题应对措施●对客户(或用户)的需求获取不充分;●没有按照规范的需求开发与需求管理的流程及内容开展需求工作;.●需求分析工作不充分;●缺乏需求定义环节，没有定义出需求规格说明书;●缺乏需求验证环节，没有请客户代表一起进行需求评审;●没有制定需求管理计划;●没有求得干系人对需求的-致理解;
●没有求得干系人对需求的承诺;●没有有效地管理需求变更控制;●没有有效维护对需求进行跟踪管理;●没有及时识别项目工作与需求之间的不一-致性。★ ●建立需求变更控制策略和需求变更控制流程。●采用多种方式充分获取用户需求并进行详细的需求分析●形成需求规格说明书并与用户进行需求验证(确认)和评审。●需求定稿建立基线，以后的需求变更必须走变更控制流程，并及时更新需求规格说明书和需求跟踪矩阵。●编写需求跟踪矩阵，需求状态表等文档●在需求规格说明书基础.上编制技术方案，并进行评审。●定期不定期对项目绩效进行监督检查，找出问题原因并指导团队成员解决。
干系人管理中的问题 干系人管理中的问题应对1、干系人名册(登记册)不能只由 PM 一个人识别和制定，这样很容易遗漏。2、沟通管理计划也不能只PM--人制定，且制定后应进行评审3、没有针对不同的干系人提交相应的项目信息4、缺乏对项目干系，人沟通需求和沟通风格的分析5、没有对沟通情况和问题进行记录
6、控制沟通工作做得不好，没有对存在的沟通问题及时进行解决7、缺乏对外包公司进行绩效跟踪和监控8、缺乏沟通规划，实际沟通不足9、沟通技术和手段过于单一，除了电子邮件外，还应适当向关键干系人进行会议和面对面的沟汇报等。 1、应尽量让关键和更多人参与千系人识别工作，可以通过已识别出的干系人进行再识别2、应将外包等所有项目干系人都纳入干系人登记册3、应组织相关干系人一起制定一个详细适合的沟通管理计划，并经干系人评审确认4、应将外包等干系人纳入沟通管理计划。5、进行干系人沟通需求和沟通风格的分析，对不同的干系人要提交不同的项目信息6、进行沟通控制工作，通过项目例会等形式对沟通存在的问题及时进行解决。
风险管理中存在常见问题 合同管理可能出现的问题:●编制风险管理计划存在问题，未结合本项目的实际情况编制计划，仅参照以前的项目模板来编制;●风险管理(规划、识别、分析等)不能只由项目经理一个人来做，应由项目团队和相关干系人共同参与，并经充分沟通和评审后才能发布实施;●缺乏风险识别过程，没有对风险进行全面识别，以做好后续风险管理;
●缺乏风险的定性和定量分析过程，没有对风险进行详细分析，风险评估和控制缺少依据;●缺乏风险应对规划，没有提前制定好风险的规划应对措施，出现问题时只按各自理解对风险进行处理，导致项目问题不断;●没有做好风险控制工作，对风险做再评估和审计及偏差趋势分析等，缺乏有效的风险监控的工具和技术;●没有对进度风险及关联影响进行充分评估。在应对进度风险方面没有做好相应的准备和安排，也未预留储备
●没有做好技术绩效测量工作，及时进行评电和绩效对比，及时纠偏;●在项目执行过程中，与客户缺乏沟通，这会产生很多不必要的项目风险和隐患;●风险管理计划也没有进行追踪检查和更新，没有及时记录和归档。
●没有签订合同或条款不全;●合同条款约定不明(产品或服务范围目标，时间、地点、质量要求、费用等);●没有做好签订合同之前的调查工作，合同签订过于草率●没有采取措施，确保合同签约双方对合同条款的一-致理 解.●合同执行过程中没有留下相应的记录;●项目变更中没有相应的进行合同变更;●甲乙双方对项目范围没有达成-致认可或承诺;
●缺少违约责任相关条款;●缺少变更处理相关条款;●缺少索赔及纠纷处理条款
项目收尾可能存在问题.●未制定规范的项目收尾规程●没有做好验收前的准备工作，软件还存在缺陷，缺陷未经修复和确认便进入正式验收环节。●在验收过程中未根据变更控制流程对软件进行修改，导致文档与软件不一-致●软件更新后没有对文档进行变更便交付给客户●项目产品未经正式验收和确认，未签
署验收报告就进行了项目总结●项目总结报告未能反映项目的实际情况●未经过正式规范的收尾就提前报告项目结束、可进行人员转移，给项目带来诸多风险●项目总结会议没有让全部项目人员参与●项目收尾时应提交的必要文件没有准备好，并经客户签收验证●催收剩余款项没有正式和必要的依据
●项目收尾时与建设方的沟通工作没有做好●项目在产品和项目工作上都还不满足收尾条件
|
|
