系统集成项目管理工程师 软考中项 第6章项目整体管理（2）

系统集成项目管理工程师/软考中项/第6章项目整体管理（2），包含监督项目工作、实施整体变更控制、结束项目或阶段等。

第6章 项目整体管理 （2）

• 实现过程
  • 步骤（四） 监控项目工作
    • 含义
      • 跟踪、审查和报告项目进展，以实现项目管理计划中确定的绩效目标的过程
      • 贯穿于项目工作的始终
        • 不仅要对项目执行进行监控，还要对项目的启动、规划和收尾进行监控
    • 作用
      • 让干系人了解项目的当前状态、已采取的步骤，以及对预算、进度和范围的预测
    • 主要关注
      • （1） 把项目的实际绩效与项目管理计划进行比较
      • （2） 评估项目绩效，决定是否需要采取纠正或预防措施，并推荐必要的措施
      • （3） 识别新风险，分析、跟踪和监测已有风险，确保全面识别风险，报告风险状态，并执行适当的风险应对计划
      • （4） 在整个项目期间，维护一个准确且及时更新的信息库，以反映项目产品及相关文件的情况
      • （5） 为状态报告、进展测量和预测提供信息
      • （6） 做出预测，以更新当前的成本与进度信息
      • （7） 监督已批准变更的实施情况
      • （8） 如果项目是项目集的一部分，还应向项目集管理层报告项目进展和状态
    • ITO
      • 输入 Input
        • （1） 项目管理计划
        • （2） 进度预测
          • 通过预测可以确定项目是否仍处于可容忍范围内，并识别任何必要的变更
        • （3） 成本预测
          • 通过比较EAC与BAC可以看出项目是否仍处于可容忍范围内，是否需要提出变更请求
        • （4） 确认的变更
          • 需用数据说明变更已得到正确落实。
        • （5） 工作绩效信息
          • 考虑了相互关系和所处背景，可以作为项目决策的可靠基础
        • （6） 事业环境因素
        • （7） 组织过程资产
      • 工具与技术 Tool&Technology
        • （1） 分析技术
          • 1||| 回归分析
            • 确定两种或两种以上变数间相互依赖的定量关系的一种统计分析方法
          • 2||| 分组方法
            • 根据研究的目的和客观现象的内在特点，按某个标志或几个标志把被研究的总体划分为若干个不同性质的组，使组内的差异尽可能小，组间的差异尽可能大
          • 3||| 因果分析
            • 又称鱼骨图或石川图 详见质量管理
          • 4||| 根本原因分析（RCA）
            • 一项结构化的问题处理法，用以逐步找出问题的根本原因 并加以解决，而不是仅仅关注问题的表征
            • 分析工具
              • 因果图
              • 头脑风暴法
              • 因果分析（鱼骨图）
          • 5||| 预测方法
            • 假设情景分析、模拟（蒙特卡洛分析）详见质量管理
          • 6||| 失效模式与影响分析（FMEA）
            • 是一套流程和工具，帮助人们在概念和设计等早期阶段，来识别一个产品或过程失效情形，以及一旦发生这种失败情形时造成的影响；还指导人们对可能的失效原因进行排序，并且制定和落实相应的应对措施。
          • 7||| 故障树分析（FTA）
            • 采用逻辑的方法，形象地进行薄弱环节和风险等危险的分析工作，特点是直观、明了，思路清晰，逻辑性强，可做定性也可做定量分析
          • 8||| 储备分析
            • 详见成本管理
          • 9||| 趋势分析
            • 又称趋势预测法，用于检查项目绩效随时间的变化情况，以确定绩效是在改善还是在恶化。
            • 具体包括：趋势平均法、指数平滑法、直线趋势法、非直线趋势法
            • 优点是考虑时间序列发展趋势，使预测结果能更好地符合实际。
          • 10||| 挣值管理
            • 详见成本管理
        • （2） 项目管理信息系统
        • （3） 会议
        • （4） 专家判断
      • Output 输出
        • 1||| 变更请求
        • 2||| 工作绩效报告
        • 3||| 项目管理计划更新
        • 4||| 项目文件更新
  • 步骤（五） 实施整体变更控制
    • 含义
      • 审查所有变更请求，批准或否决变更，管理对可交付成果、组织过程资产、项目文件和项目管理计划的变更，并对变更处理结果进行沟通的过程
      • 贯穿项目始终，并且应用于项目的各个阶段；项目经理对此负最终责任
      • 项目的任何干系人都可以提出变更请求。尽管可以口头提出，但所有变更请求都必须以书面形式记录，并纳入变更管理以及配置管理系统中
      • 每项记录在案的变更请求都必须由一位责任人批准或否决。这个责任人通常都是项目发起人或项目经理，应该在项目管理计划或组织流程中指定这位责任人。必要时，应该由变更控制委员会CCB来决策是否实施整体变更控制过程。
    • 变更控制管理流程图
    • 作用
      • 从整合的角度考虑记录在案的项目变更，从而降低因未考虑变更对整个项目目标或计划的影响而产生的项目风险。
    • 变更控制委员会CCB
      • 是一个正式组成的团体，负责审查、评价、批准、推迟或否决项目变更，以及记录和传达变更处理决定
    • 批准
      • 整体变更控制可以通过CCB和变更控制系统来完成。但整体变更控制不只是CCB的事情，也是项目经理和项目团队的事情
      • CCB是由主要项目干系人（客户、用户、发起人、高管、领导、经理、项目经理等）的代表所组成的一个小组，项目经理可以是其中的成员之一，但通常不是组长。CCB负责审查变更请求，批准或否决这些变更请求
      • 对于可能影响项目目标的变更，必须经过变更控制委员会CCB的批准才能实施；在CCB批准之后，还可能需要得到客户或发起人的批准，除非他们本来就是CCB的成员
      • 变更控制系统是指关于变更管理的一系列正式的书面程序，包括文档、跟踪系统、变更的批准层次等
    • 区别
      • 配置控制
        • 重点关注可交付成果及各个过程的技术规范之间的匹配问题
      • 变更控制
        • 着眼于识别、记录、批准或否决对项目文件、可交付成果或基准的变更
    • 配置管理活动
      • 1. 配置识别
      • 2. 配置状态记录
      • 3. 配置核实与审计
    • 包括的变更活动
      • （1） 识别可能发生和已经发生的变更
      • （2） 影响整体变更控制的相关因素，确保只有已批准的变更才能被实施
      • （3） 评审并批准变更申请
      • （4） 通过规范化的变更申请流程来管理已批准的变更
      • （5） 管理基线的完备性，确保只有已批准的变更才能被集成到项目产品或服务中，并对变更的配置和计划文档进行维护
      • （6） 评审并审批所有书面的纠正措施和预防措施
      • （7） 根据已批准的变更，控制并更新项目的范围、成本、预算、进度和质量需求，变更要从整个项目的高度上进行协调
      • （8） 要记录变更申请的所有影响
      • （9） 验证缺陷修复的正确性
      • （10） 基于质量报告控制项目质量使其符合标准
    • ITO
      • 输入 Input
        • （1） 项目管理计划
        • （2） 工作绩效报告
        • （3） 变更请求
        • （4） 事业环境因素
        • （5） 组织过程资产
      • 工具与技术 Tool&Technology
        • （1） 变更控制工具
        • （2） 专家判断
        • （3） 会议
      • Output 输出
        • （1） 批准的变更请求
        • （2） 项目管理计划更新
        • （3） 项目文件更新
        • （4） 变更日志
          • 用来记录项目过程中出现的变更。未经批准的变更请求也应该记录在变更日志中。
  • 步骤（六） 结束项目或阶段
    • 含义
      • 完成并结束所有项目管理过程组的所有活动，以正式结束项目或项目阶段的过程
      • 这个过程包括完成所有项目过程中的所有活动以正式关闭整个项目或阶段；恰当地移交已完成或已取消的项目或阶段；对项目可交付物进行验证和记录；协调和配合顾客或出资人对这些可交付物的正式接受
      • 结束阶段的主要管理内容是收尾管理。实质是进行项目行政收尾。在结束项目过程中，虽然也需要获得项目发起人或客户对项目产品、服务或成果的最终验收，这个验收主要是一个必需的程序，是一个形式上的验收而非实质性技术验收。真正的技术验收早在范围核实过程中已经完成。
    • 作用
      • 总结经验教训，正式结束项目工作，为开展新工作而释放组织资源。
    • 包含
      • 1. 行政收尾 [管理收尾]
        • 当项目结束或项目提前终止时，又或项目每个阶段结束时需要开展行政收尾工作。
        • 内容
          • 1||| 产品核实
            • 确认全部工作都按项目产品的既定要求完成了
          • 2||| 财务收尾
            • 支付最后的项目款项，完成财务结算
          • 3||| 更新项目记录
            • 完成最终的项目绩效报告和项目团队成员的业绩记录
          • 4||| 总结经验教训，进行项目完工后评价
          • 5||| 进行组织过程资产更新
            • 收集、整理和归档各种项目资料
          • 6||| 结束项目干系人在项目上的关系，解散项目团队
        • 结果
          • 1. 对项目产品的正式接受
          • 2. 完整的项目档案
          • 3. 组织过程资产更新（经验教训总结）
          • 4. 资源释放（包括人力和非人力资源）
      • 2. 合同收尾
        • 定义：结束合同工作，进行采购审计，结束当事人之间的合同关系，并将有关资料收集归档
      • 二者关系
        • 联系
          • 都需要进行产品核实，都需要总结经验教训，对相关资料进行整理和归档，更新组织过程资产
        • 区别
          • a. 行政收尾是针对项目和项目各阶段的，不仅整个项目要进行一次行政收尾，而且每个项目阶段结束时都要进行相应的行政收尾； --------------------------------------------------------------------- 合同收尾是针对合同的，每一个合同需要并且只需要进行一次合同收尾
          • b. 从整个项目说，合同收尾发生在行政收尾之前； ------------------------------------------------------- 如果是以合同形式进行的项目，在收尾阶段，先要进行采购审计和合同收尾，然后进行行政收尾
          • c. 从某一个合同的角度说，合同收尾中又包括行政收尾工作（合同的行政收尾）
          • d. 行政收尾要由项目发起人或高级管理层给项目经理签发项目阶段结束或项目整体结束的书面确认； ------------------------------------------------------------------ 而合同收尾则要由负责采购管理成员（可能是项目经理或其他人）向卖方签发合同结束的书面确认
    • ITO
      • 输入 Input
        • （1） 项目管理计划
        • （2） 验收的可交付成果
          • 可能包括批准的产品规范、交货收据和工作绩效文件。在分阶段实施的项目或被取消的项目中，可能会包括未全部完成的可交付成果或中间可交付成果。
        • （3） 组织过程资产
          • 项目或阶段收尾指南或要求
          • 历史信息与经验教训知识库
      • 工具与技术 Tool&Technology
        • a. 分析技术
          • 回归分析
          • 趋势分析
        • b. 专家判断
        • c. 会议
      • Output 输出
        • 1||| 最终产品、服务或输出移交
        • 2||| 组织过程资产更新
          • 项目档案
          • 项目或阶段收尾文件
            • 如果项目在完工前提前终止，则需要再正式的收尾文件中说明项目终止的原因，并规定正式程序，把该项目的已完成和未完成的可交付成果移交他人。
          • 历史信息
    • 其它
      • 在结束项目时，项目经理需要审查以前各阶段的收尾信息，确保所有项目工作都已完成，确保项目目标已经实现。
      • 项目经理需要审查范围基准，确保在项目工作完成后才宣布项目结束。
      • 如果项目在完工前就提前终止，结束项目或阶段过程还需要制定程序，来调查和记录提前终止的原因。
      • 项目经理应该邀请所有合适的干系人参与本过程。