• 主要掌握输入，输出内容先看他的过程域本身，过程域是什么输出就是什么

• 上一个过程域的输出是下一个过程域的输入

• 十大管理1+4+3+2都有计划过程组，通常规划为首，控制为尾

• 规划阶段的万能输出是各子计划，即项目管理计划的子计划；规划阶段的万能输入是章程计划+组织事业

• 各大管理的子计划/规划阶段的输出子计划会作为后续过程域（监控除外）的主要输入

• 执行过程组的管理阶段的万能输出是变更请求+三大更新

• 监控过程组控制阶段的万能输出是变更请求+工作绩效信息+三大更新，即个性化输出＋12345（监控项目工作：变更请求+工作绩效报告；实施整体变更控制：批准的变更请求+变更日志)，万能输入为项目管理计划+工作绩效数据+组织事业（控制风险/控制采购输入：工作绩效数据+工作绩效报告）

• 三大更新：项目文件更新、项目管理计划更新、组织过程资产更新

• 三大基准：创建WBS输出的范围基准、制定进度计划输出的进度基准、成本预算输出的成本基准

• 监控项目工作输入的两大预测：控制进度输出的进度预测、控制成本输出的成本预测

• 两个日历：资源日历（实施采购、组件项目团队输出）、 项目日历（制定进度计划输出）

• 三个说明书：项目范围说明书（定义范围输出）、项目工作说明书（制定项目章程输入）、采购工作说明书（编制采购管理计划输出）

• 两个日志：变更日志（实施整体变更控制输出) 、问题日志（管理干系人参与输出）

• 编制范围管理计划：范围管理计划、需求管理计划

• 规划进度管理：输入两册（风险登记册-识别风险输出、干系人登记册-识别干系人输出）、计划组织事业；输出进度管理计划（区别进度计划）

• 规划质量管理：质量管理计划、过程改进计划、个性化输出（质量核对单，质量测量指标）

• 编制采购管理计划：采购管理计划、采购文件、采购工作说明书

• 确认范围：核实的可交付成果 = > 验收的可交付成果

• 工作绩效报告：是实施整体变更控制；管理项目团队、管理沟通；控制采购、控制风险的输入

• 问题日志：是管理项目团队、控制沟通、控制干系人参与的输入

• 项目文件：是识别风险；实施质量保证、实施采购；控制质量、控制干系人参与的输入

• 批准的变更请求：是指导和管理项目工作、控制质量、控制采购的输入

基础

• PMO分类

  1. 支持型：担当顾问的角色，为项目提供模板、最佳实践、培训，以及来自其他项目的信息和经验教训

  2. 控制型：不仅给项目提供支持，而且通过各种手段要求项目服从PMO的管理策略，对项目的控制程度属于中等

  3. 指令型：直接管理和控制项目，对项目的控制程度很高

• 项目经理应具备的技能

  1. 足够的知识

  2. 良好的协调和沟通能力

  3. 良好的职业道德

  4. 丰富的项目管理经验

  5. 一定的领导和管理能力

立项

• 项目建议：项目建议书

  1. 是项目建设单位向上级主管部门提交的项目申请文件，是对拟建项目提出的总体设想

  2. 项目建议书是项目发展周期的初始阶段，是国家或上级主管部门选择项目的依据，也是可行性研究的依据

  3. 项目建设单位组织编制项目建议书，在编制项目建议书阶段应专门组织项目需求分析，形成需求分析报告送项目审批部门组织专家提出咨询意见，作为编制项目建议书的参考

  4. 项目建设单位完成项目建议书编制工作之后报送项目审批部门。项目审批部门在征求相关部门意见，并委托有资格的咨询机构评估后审核批复，或报国务院审批后下达批复

• 项目可行性分析

  初步可行性研究报告比较粗略，也要对项目进行全面的描述分析（√）

  只有通过初步可行性研究认为该项目基本可行后，才会开展详细的可行性研究（×）

  项目可行性研究内容（默写）：

  • 投资必要性；经济可行性；财务可行性

  • 技术可行性；组织可行性；社会可行性

  • 风险因素及决策（市场风险、技术风险、财务风险、法律风险、组织风险、经济及社会风险等因素）

• 项目建议书对比可行性研究

项目建议书	可行性研究
项目简介	项目概述
项目建设单位概括	项目建设单位概括
项目建设的必要性	项目建设的必要性
业务分析	需求分析
总体建设方案	总体建设方案
本期项目建设方案	本期项目建设方案
环保、消防、职业安全	环保、消防、职业安全
项目实施进度	项目实施进度
投资估算和资金筹措	资金估算和资金来源
效益和风险分析	效益与评价指标分析
	项目风险和风险管理
	项目招标方案
	项目组织机构和人员培训

• 项目可行性分析-项目评估与论证

  1. 由第三方(国家、银行或有关机构) 进行

  2. 项目评估是项目投资前期进行决策管理的重要环节

  3. 项目评估的目的是审查项目可行性研究的可靠性，真实性和客观性

  4. 项目评估为银行贷款决策或行政部门主管部门审批决策提供科学依据，项目评估最终成果是项目评估报告

• 项目审批

• 项目招投标

• 项目合同谈判与签订

• 供应商项目立项

  系统集成供应商，不需要在组织内为签署的设备采购类项目单独立项以确保对合同责任加以约束和规范

  1. 通过项目立项方式为项目分配资源。系统集成合同中虽然有明确的合同金额，但合同执行时需要各种资源，所以通过内部立项方式将合同金额转换为资源类型和资源

  2. 通过项目立项方式确定合理的项目绩效，有助于提升人员的积极性

  3. 以项目型工作方式提升项目实施效率

• 案例分析

  万能

  1. 项目经理可能项目管理经验不足，缺少项目立项管理意识和经验

  2. 根据经验完成该过程不妥，依据不足，经验仅仅是组织过程资产

  3. 直接使用XXX系统不妥，应该评审或者评估之后方可使用

  4. 项目沟通管理存在问题，导致产生冲突

  立项（输入输出、工具内容角度）

  1. 没有人员可以投入该项目不妥，应该有技术人员支撑维护工作

  2. 缺少项目建议书的编制，应组织编写项目建议书

  3. 缺少项目可行性研究分析，应进行初步可行性研究、详细可行性研究等

  4. 缺少项目评估与论证工作，应组织第三方（国家、银行、专业评估机构）进行评估

整体

• 制定项目章程：项目章程理解

  1. 项目章程之前要进行需求估计、可行性研究、初步计划等

  2. 项目章程是正式批准项目的文件，项目章程是由项目实施组织外部签发的文件，通常由公司高级管理层签发。项目章程是项目经理寻求主要干系人支持的依据

  3. 项目章程不能太抽象，也不能太具体。当项目目标发生变化，需要对项目章程进行修改时，只有管理层和发起人有权进行变更，项目经理对项目章程的修改不在其权责范围之内。项目章程遵循“谁签发，谁有权修改”的原则

  4. 作用：确定并任命项目经理，规定项目经理的权力；正式确认项目的存在，给项目一个合法的地位；规定项目的总体目标，包括范围、时间、成本和质量等；通过叙述启动项目的理由，把项目与执行组织的日常经营运作及战略计划等联系起来

• 制定项目章程：项目章程内容（默写） 风-目-预-要-标-进-描-发-审-经

  1. 项目主要风险

  2. 项目目的或批准项目的原因

  3. 总体预算

  4. 项目的总体要求

  5. 可测量的项目目标和相关的成功标准

  6. 总体里程碑进度计划

  7. 概括性项目描述和项目产品描述

  8. 发起人或其他批准项目章程的人员的姓名和职权

  9. 项目审批要求

  10. 委派的项目经理及其职责和职权

• 制定项目管理计划：项目管理计划13+3（默写）

  • 范围管理计划、需求管理计划、范围基准(批准的范围说明书/WBS/WBS词典)；

  • 进度管理计划、进度基准；

  • 成本管理计划、成本基准；

  • 质量管理计划、过程改进计划；

  • 人力资源管理计划；沟通管理计划；干系人管理计划；

  • 采购管理计划；风险管理计划；变更管理计划；配置管理计划

• 制定项目管理计划：区分项目文件

  变更日志、问题日志；干系人登记册、风险登记册；项目进度计划、进度预测、成本预测；资源日历、项目日历；质量测量指标、质量核对单；采购文件、采购工作说明书；团队绩效评价

• 制定项目管理计划：项目管理计划内容（默写）

  1. 所使用的项目管理过程

  2. 每个特定项目管理过程的实施程度

  3. 完成这些过程的工具和技术的描述

  4. 项目所选用的生命周期及各阶段将采用的过程

  5. 为项目选择的生命周期模型

  6. 如何用选定的过程来管理具体的项目。包括过程之间的依赖与交互关系及基本的输入和输出

  7. 如何执行工作来完成项目目标及对项目目标的描述

  8. 如何监督和控制变更，明确如何对变更进行监控

  9. 配置管理计划，明确如何开展配置管理

  10. 对维护项目绩效基线的完整性说明

  11. 与项目干系人进行沟通的要求和技术

  12. 为解决某些遗留问题和未定的决策，对于其内容、严重程度和紧迫程度进行的关键管理评审

• 制定项目管理计划：项目典型生命周期模型

  1. 瀑布模型/结构化开发方法：需求明确优先选择，侧重于开发过程，F-S型

  2. V 模型：需求明确且变更不频繁，侧重于测试过程。需求分析/验收测试、概要设计/系统测试、详细设计/集成测试、编码/单元测试

  3. 螺旋模型：四个象限分别代表制定计划、风险分析、实施工程、客户评估。强调风险分析，特别适用于庞大而复杂的、高风险的系统

  4. 迭代模型：需求不明确，包含初始、细化、构造、移交四个过程

  5. 原型化/快速模型：动态响应、逐步纳入。可分为抛弃型模型、进化型模型

  6. 敏捷方法：是一种以人为核心、迭代、循序渐进的开发方法，适用于一开始并没有或不能完整地确定出需求和范围的项目，或者要应对快速变化的环境，或者需求和范围难以事先确定，或者能够以有利于干系人的方式定义较小的增量改进

• 监控项目工作

  1. 输入：项目管理计划、进度预测、成本预测、确认的变更、工作绩效信息、组织事业

  2. 工具：专家判断、会议、项目管理信息系统、分析技术(回归分析、挣值管理、趋势分析、分组方法、根本原因分析-因果图/头脑风暴法/因果分析/鱼骨图、预测方法-模拟/蒙特卡洛分析、失效模式和影响分析、故障树分析、储备分析）

  3. 趋势分析法：称趋势预测法，用于检查项目绩效随时间的变化情况，以确定绩效是在改善还是在恶化，包括趋势平均法、指数平滑法、直线趋势法、非直线趋势法

• 案例分析

  万能

  1. 项目经理可能项目管理经验不足，缺少整体管理意识

  2. 根据经验完成该过程不妥，依据不足，经验仅仅是组织过程资产

  3. 独自编制项目管理计划不妥，项目经理应带领全体成员自下而上共同完成

  4. 项目管理计划、项目文件直接发布不妥，所有计划、文件必须评审

  5. 项目变更未执行变更控制流程；变更控制流程不合理，未严格按照变更控制流程制定；未建立CCB变更控制委员会，未书面记录变更请求，形成变更日志，变更请求必须以书面形式形成记录且经CCB进行批准；变更实施过程中未做好配置和版本管理，变更结束后未通知相关受影响干系人

  6. 项目监控不到位，监控过程贯穿于项目始终，因此导致进度滞后、成本超支、客户不满意

  7. 项目沟通管理存在问题，导致产生冲突

  整体（输入输出、工具内容角度）

  1. 未制定项目章程，必须实施组织外部签发

  2. 未编制项目管理计划，必须自下而上

  3. 指导和管理项目工作存在问题，未按计划执行

  4. 监控项目工作存在问题，未对项目进行指导和监控

  5. 实施整体变更控制存在问题，未执行变更程序

  6. 结束项目或阶段存在问题，提前解散项目团队，未召开收尾会议

范围

• 编制范围管理计划：范围管理计划内容

  有助于降低项目范围蔓延的风险

  1. 制定项目范围说明书

  2. 根据项目范围说明书创建WBS（属于项目管理计划，不属于项目文件）

  3. 维护和批准WBS

  4. 正式验收已完成的项目可交付成果

  5. 处理对项目范围说明书或WBS的变更

• 编制范围管理计划：需求管理计划内容（默写）

  1. 如何规划、跟踪、汇报各种需求活动

  2. 需求跟踪结构

  3. 配置管理活动

  4. 培训计划

  5. 需求管理需要使用的资源

  6. 项目干系人参与需求管理的策略

  7. 判断项目范围与需求不一致的准则和纠正规程

• 编制范围管理计划：需求管理计划的理解

  1. 描述在整个项目生命周期内如何分析、记录和管理需求

  2. 如何规划、跟踪和汇报各种需求活动：配置管理活动、需求优先级排序过程、产品测量指标及使用这些指标的理由、用来反映哪些需求属性将被列入跟踪矩阵的跟踪结构、收集需求过程

  3. 需求管理贯穿于整个过程，其最基本的任务就是明确需求，并使项目团队和用户达成共识，即建立需求基线；还要建立需求跟踪能力联系链，确保所有用户需求都被正确地应用，并且在需求发生变更时，能够完全控制其影响范围，始终保持产品与需求的一致性

• 收集需求：需求文件主要内容（默写）业-干-项-过-假-依-解

  业务需求，干系人需求，解决方案需求，项目需求，过渡需求，与需求有关的假设条件、依赖关系和制约因素

• 收集需求：需求分类（默写）

  业务需求，干系人需求，解决方案需求，项目需求，过渡需求，质量需求

• 定义范围：

  输入：项目章程和初步的范围说明书、范围管理计划、组织过程资产、需求文件、批准的变更申请（不包括合同）

  工具：焦点小组是召集预定的干系人和主题专家，了解他们对所讨论的产品、服务或成果的期望和态度

• 定义范围：范围说明书（默写）——描姐可约，虚假目标

  1. 产品范围描述

  2. 项目边界

  3. 项目的可交付成果

  4. 项目的制约因素

  5. 项目需求

  6. 假设条件

  7. 项目目标

• 定义范围：项目范围说明书的主要作用（默写）

  确定范围；规划和控制依据；规划基础、沟通基础、变更基础

• 定义范围：项目目标

  1. 包括成果性标和约束性目标，约束性目标也叫管理性目标，成果性目标有时也简称为项目目标

  2. 项目成果性目标指通过项目开发出的满足客户要求的产品、系统、服务或成果

  3. 项目的目标特性：多目标性、优先性、层次性

  4. 项目的目标要求遵守SMART原则：具体的-Specific；可测量的-Measurable；可以达到的-Attainable；有相关性的-Relevant；有明确时限的-Time-bound

• 创建WBS：分解WBS活动（默写）

  1. 识别和分析可交付成果及相关工作

  2. 确定WBS的结构和编排方法（组织结构图、列表形式）

  3. 自上而下逐层细化分解（随着情况的逐渐清晰，规划包最终将被分解成工作包以及相应的具体活动）

  4. 为WBS组件制定和分配标识编码

  5. 核实可交付成果分解的程度是否恰当

  老教材：

  1. 识别和确认项目的阶段和主要可交付物

  2. 分解确认每一组成部分是否分解的足够详细

  3. 确认项目主要交付成果的组成要素

  4. 核实分解的正确性

• 创建WBS：WBS分解注意事项、原则（默写）

  1. 在层次上保持项目的完整性，避免遗漏必要的组成部分（符合项目的范围100%)

  2. 相同层次的工作单元应用相同性质

  3. 一个工作单元只能从属于某个上层单元，避免交叉从属

  4. 工作单元应能分开不同的责任者和不同的工作内容

  5. 最底层工作应该具有可比性，是可管理的、可定量检查的

  6. 应包括项目管理工作，包括分包出去的工作

  7. 便于项目管理计划和项目控制的需要

  8. WBS 中的元素必须只由一个人负责，应控制在3-6 层，工作包大小应遵循8/80原则

  9. WBS 的编制需要所有项目干系人参与，需要项目团队成员参与

  10. WBS 并非一成不变，在完成WBS 后的工作中仍有可能需要对 WBS 进行修改

• 确认范围：

  1. 输入： 需求文件、需求跟踪矩阵、核实的可交付成果（控制质量）、范围管理计划、工作绩效数据、事业环境因素（行业风险数据库）

  2. 输出: 验收的可交付成果、变更请求、工作绩效信息、项目文件更新

  3. 工具与技术: 检查(审查、产品评审、审计、走查、巡检)、群体决策(独裁、相对多数、大多数、一致通过)

• 确认范围：步骤

  1. 确定需要进行确认范围的时间

  2. 识别确认范围需要哪些投入

  3. 确定范围正式被接受的标准和要素

  4. 确定确认范围会议的组织步骤

  5. 组织确认范围会议

• 确认范围：作用（易忘记/默写）

  1. 使验收过程具有客观性，同时通过验收每个可交付成果，提高最终产品、服务或成果获得验收的可能性

  2. 确认范围与控制质量的区别

     • 前者关注可交付成果的验收，后者关注可交付成果的正确性及是否满足质量要求

     • 确认范围一般在阶段末尾进行；质量控制一般在确认范围前进行，也可同时进行

     • 确认范围由外部干系人 (客户或发起人) 对项目可交付成果进行检查验收；质量控制属内部检查，由执行组织的相应质量部门实施

• 控制范围

  1. 输入：项目管理计划、需求文件、需求跟踪矩阵、工作绩效数据、组织过程资产

  2. 输出：变更请求、工作绩效信息、项目文件更新、项目管理计划更新、组织过程资产更新

  3. 工具：偏差分析

• 案例分析

  万能

  1. 项目经理可能项目管理经验不足，缺少范围管理意识

  2. 根据经验完成该过程不妥，依据不足，经验仅仅是组织过程资产

  3. 独自编制范围管理计划、需求管理计划不妥，项目经理应带领全体成员共同完成

  4. 范围管理计划、需求管理计划、需求文件、范围说明书直接发布不妥，所有计划、文件必须评审

  5. 项目变更未执行变更控制流程；变更控制流程不合理，未严格按照变更控制流程制定；未建立CCB变更控制委员会，未书面记录变更请求，形成变更日志。所有变更请求必须以书面形式形成记录且经CCB进行批准；变更实施过程中未做好配置和版本管理，变更结束后未通知相关受影响干系人

  6. 项目监控不到位，监控过程贯穿于项目始终，因此导致进度滞后、成本超支、客户不满意

  7. 项目沟通管理存在问题，导致产生冲突

  范围（输入输出、工具内容角度）

  1. 编制范围管理计划存在问题，未编制范围管理计划、需求管理计划

  2. 定义范围存在问题，未进行范围定义，需要反复进行，范围说明书内容不全，需要评审

  3. 创建WBS存在问题，需要项目经理带领项目组全体成员、项目干系人共同参与完成；工作包大小应遵循8/80原则；干系人要确认；WBS应包含分包工作、项目管理工作；范围基准未经确认；WBS应控制在3-6层；WBS的编制必须由一个人负责

  4. 确认范围存在问题，未进行范围确认，贯穿项目始终，干系人要确认

  5. 控制范围存在问题，未进行控制范围，贯穿项目始终，需求变更问题，范围蔓延问题

  6. 依据原有系统编写需求说明书不妥，没有考虑客户新的需求

  7. 按照需求说明书进行后续实施不妥，形成需求规格说明书后应该经过范围定义、创建 WBS 等一系列步骤后方可实施

进度

• 规划进度管理：

  1.工具和技术：专家判断、分析技术、会议

  2.项目进度管理计划内容：项目进度模型制定、项目进度模型维护；准确度、计量单位；组织程序衔接、控制临界值、绩效测量规则；报告格式、过程描述

• 定义活动

  1. 概念：识别和记录为完成项目可交付成果而需采取的具体行动

     • 活动就是为完成工作包所需进行的工作，是实施项目时安排工作的最基本的工作单元

     • 活动与工作包是 1对 1或多对 1的关系，即有可能多个活动完成一个工作包

     • 除了首尾两项活动之外，每项活动和每个里程碑都至少有一项紧前活动和一项紧后活动

  2. 输入：进度管理计划、范围基准、组织过程资产、事业环境因素

  3. 工具和技术：分解、滚动式规划、专家判断

     滚动式规划：一种迭代式规划技术，即近期要完成的工作在工作分解结构最下层详细规划，而计划在远期完成的工作，在工作分解结构较高层粗略规划。是一种渐进明细的规划方式，项目团队得以逐步完善规划

  4. 输出

     • 活动清单：是一份包含项目所需的全部活动的综合清单

     • 活动属性：随时间演进

     • 里程碑清单：是项目中的重要时点或事件 ，某时刻里程碑持续时间为零、不消耗资源也不消耗成本。里程清单列出了所有项目里程碑，并指明每个里程碑是强制性的(如合同要求) 还是选择性的（如根据历史信息确定的)，里程碑清单为后期的项目控制提供了基础

• 排列活动顺序

  1. 输入：进度管理计划、活动清单、活动属性、里程碑清单、项目范围说明书(主要输入)、批准的变更请求

  2. 输出：项目进度网络图、项目文件更新

  3. 工具与技术：前导图法、箭线图法、确定依赖关系、提前量与滞后量

     • 前导图法PDM: 单代号网络图或活动节点图AON，每项活动有唯一活动号，每项活动都注明预计工期

     • 箭线图法ADM: 双代号网络图或活动箭线图AOA，每一活动和每一事件都必须有唯一的一个代号，即网络图中不会有相同的代号

     • 提前量：相对于紧前活动，紧后活动可以提前的时间量，提前量往往表示为负数

     • 滞后量：相对于紧前活动，紧后活动需要推迟的时间量，滞后量往往表示为正数

  4. 确定依赖关系

     • 强制性依赖关系：是法律或合同要求的该工作的内在性质决定的依赖关系

     • 选择性依赖关系：首选逻辑关系、优先逻辑关系或软逻辑关系，是基于具体应用领域的最佳实践或者是基于项目的某些性质而设定

     • 外部依赖关系：是项目活动与非项目活动之间的依赖关系，往往不在项目团队的控制范围内

     • 内部依赖关系：是项目活动之间的紧前关系，通常在项目团队的控制之中

• 估算活动资源

  工具与技术：专家判断、备选方案分析、发布的估算数据、项目管理软件、自下而上估算

• 制订进度计划：

  工具和技术：进度网络分析、关键路线法、关键链法；资源优化技术、建模技术；提前量与滞后量、进度压缩、进度计划编制工具

  • 资源平衡：为了在资源需求与资源供给之间取得平衡，根据资源制约对开始日期和结束日期进行调整的一种技术。资源平衡往往导致关键路径改变，通常是延长

  • 资源平滑：对进度模型中的活动进行调整，从而使项目资源需求不超过预定的资源限制的一种技术。资源平滑不会改变项目关键路径，完工日期也不会延迟。资源平滑技术可能无法实现所有资源的优化

• 控制进度

  1. 输入：项目日历、进度数据、项目进度计划、项目管理计划、工作绩效数据、组织事业

  2. 输出：进度预测、变更请求、工作绩效信息、项目文件更新、项目管理计划更新、组织过程资产更新

  3. 工具技术：绩效审查(关键路径法、关键链法、趋势分析、挣值管理)、项目管理软件、资源优化技术、建模技术、提前量与滞后量、进度压缩、进度计划编制工具

• 控制进度：赶-快-使-减-改-加缩短工期（重点默写）

  1. 赶工：投入更多的资源或增加工作时间，以缩短关键活动的工期；通过增加资源，以最小的成本增加来压缩进度工期的一种技术。只适用于那些通过增加资源就能缩短持续时间的，且位于关键路径上的活动。赶工并非总是切实可行，它可能导致风险、成本增加

  2. 快速跟进：并行施工，以缩短关健路径的长度，可能造成返工、增加风险；一种进度压缩技术，将正常情况下按顺序进行的活动或阶段改为至少是部分并行开展。只适用于能通过并行活动来缩短项目工期的情况

  3. 使用高素质的资源或经验更丰富的人员

  4. 在业主客户许可的前提下，减小活动范围或降低活动要求，未经业主允许，客户会不满意

  5. 改进方法或技术，以提高生产效率，可能增加风险，导致进度滞后

  6. 加强质量管理，及时发现问题减少返工，从而缩短工期

     注意：若项目成本也同时超支，此时“赶工"不要写，赶工可能会导致成本增加

• 案例分析

  万能

  1. 项目经理可能项目管理经验不足，缺少进度管理意识

  2. 根据经验完成该过程不妥，依据不足，经验仅仅是组织过程资产

  3. 独自编制进度管理计划、进度计划不妥，项目经理应带领全体成员共同完成

  4. 进度管理计划、进度计划、活动清单直接发布不妥，所有计划、文件必须评审

  5. 项目变更未执行变更控制流程；变更控制流程不合理，未严格按照变更控制流程制定；未建立CCB变更控制委员会，未书面记录变更请求，形成变更日志，所有变更请求必须以书面形式形成记录且经CCB进行批准；变更实施过程中未做好配置和版本管理，变更结束后未通知相关受影响干系人

  6. 项目监控不到位，监控过程贯穿于项目始终，因此导致进度滞后、成本超支、客户不满意

  7. 项目沟通管理存在问题，导致产生冲突

  进度（输入输出、工具内容角度）

  1. 规划进度管理存在问题，未编制进度管理计划；进度网络图中可能有多条关键路径

  2. 定义活动存在问题

  3. 排列活动顺序存在问题

  4. 估算活动资源存在问题

  5. 估算活动持续时间存在问题，应该把估算活动持续时间所依据的全部数据与假设都记录下来；应该由项目团队中最熟悉具体活动的个人或小组，来提供估算活动持续时间所需的各种输入

  6. 制定进度计划存在问题，制订可行的项目进度计划，往往是一个反复进行的过程；经批准的最终进度计划将作为基准用于控制进度过程

  7. 控制进度存在问题，资源平衡会导致关键路径改变，一般是延长；资源平滑不会影响关键路径，完工日期也不会推迟；进度基准的任何变更都必须经过实施整体变更控制过程的审批，控制进度是实施整体变更控制过程的一个组成部分

成本

• 成本分类：可变+固定+直接+间接+机会+沉没成本

  • 直接成本: 直接可以归属于项目工作的成本为直接成本，项目团队差旅费、工资、项目使用的物料及设备使用费、应急储备金

  • 间接成本：来自一般管理费用科目或几个项目共同担负的项目成本所分给本项目的费用，税金、额外福利 (保险、保暖费) 、保卫费用、电费、行政管理费、押金

  • 沉没成本：是一种历史成本，对现有决策而言是不可控成本，会很大程度上影响人们的行为方式与决策，在投资决策时应排除沉没成本的干扰

  • 机会成本：泛指一切在做出选择后其中一个最大的损失

• 制订成本管理计划

  1. 输入：项目管理计划、项目章程；事业环境因素、组织过程资产

  2. 输出：成本管理计划

  3. 工具和技术：专家判断、会议、分析技术

  4. 8个内容（默写）：精确度、准确度、计量单位；组织程序衔接(用于项目成本核算的WBS单元被称为控制账目）、控制临界值、绩效测量规则（需要规定用于绩效测量的挣值管理EVM规则)；报告格式、过程描述、其他细节

• 成本估算

  1. 是对完成项目活动所需资金进行近似估算的过程，可以是汇总的或详细分列的，为了加强预算控制，成本估算建议在 WBS 的最底层进行

  2. 输入：成本管理计划、组织事业；范围基准、项目进度计划；人力资源管理计划、风险登记册

  3. 输出：活动成本估算、估算依据、项目文件更新

  4. 工具技术：类比估算、参数估算、自下而上估算/工料清单法、三点估算；储备分析/准备金分析、卖方投标分析；质量成本、项目管理软件；专家判断、群体决策技术、确定资源费用率

  5. 参数估算法：是一种基于历史数据和项目参数，使用某种算法来计算成本或工期的估算技术。参数估算的准确性取决于参数模型的成熟度和基础数据的可靠性。参数估算可以针对整个项目或项目中的某个部分，并可与其他估算方法联合使用

  6. 储备分析

     • 应急储备: 已知-未知，用来应对已经接受的已识别风险，以及已经制定应急或减轻措施的已识别风险。是包含在成本基准内的一部分预算

     • 管理储备：未知-未知，为了管理控制的目的而特别留出的项目预算，来应对项目范围中不可预见的工作。管理储备不包括在成本基准中，但属于项目总预算和资金需求的一部分。当动用管理储备资助不可预见的工作时，就要把动用的管理储备增加到成本基准中，从而导致成本基准变更

• 成本估算：主要步骤（默写）

  1. 识别并分析成本的构成科目

  2. 根据已识别的项目成本构成科目，估算每一个科目的成本大小

  3. 分析成本估算结果，找出可以相互替代的成本，协调各种成本之间的比例关系

• 成本预算

  1. 输入：活动成本估算、估算依据、成本管理计划；范围基准、项目进度计划；风险登记册、资源日历；协议、组织过程资产

  2. 输出：成本基准、项目资金需求、项目文件更新

  3. 成本基准/完工预算BAC

  • 成本基准=活动成本估算+应急储备，是不同进度活动经批准的预算总和，经批准的、按时间段分配的项目预算

  • 成本基准包含应急储备，不包含管理储备

  • 项目预算包括经批准用于项目的全部资金，项目总预算 = 成本基准+管理储备(挣值计算不考虑管理储备 ）

  • 成本基准是50W，应急储备是20W，管理储备是10W，项目的总预算是（60）

• 成本预算：3特征

  1. 计划性: 指在项目计划中，尽量精确地将费用分配到 WBS 的每一个组成部分，从而形成与 WBS 相同的系统结构

  2. 约束性: 指预算分配的结果可能并不能满足所涉及的管理人员的利益要求，而表现为一种约束

  3. 控制性: 指项目预算的实质就是一种控制机制

• 成本预算：步骤（默写）

  1. 将项目总成本分摊到项目工作分解结构的各个工作包中，分解按照自顶向下，根据占用资源数量多少而设置不同的分解权重

  2. 将各个工作包成本再分配到该工作包所包含的各项活动上

  3. 确定各项成本预算支出的时间计划及项目成本预算计划

• 成本预算：4原则（默写）

  以项目需求为基础；与项目目标相联系，必须同时考虑项目质量和进度等目标；切实可行；应当留有弹性

• 控制成本

  1. 输入: 项目资金需求、项目管理计划、工作绩效数据、组织过程资产

  2. 输出：成本预测、变更请求、工作绩效信息、项目文件更新、项目管理计划更新、组织过程资产更新

  3. 工具：挣值管理、储备分析、预测、完工尚需绩效指数、绩效审查、项目管理软件

• 控制成本：成本失控5原因

  1. 对工程项目的认识不足

  2. 组织制度不健全

  3. 需求管理不当

  4. 方法问题

  5. 技术制约

• 控制成本：9方法/内容

  1. 对造成成本基准变更的因素施加影响

  2. 当变更实际发生时，管理这些变更

  3. 确保所有变更请求都得到及时处理

  4. 确保成本支出不超过批准的资金限额

  5. 监督成本绩效，找出并分析与成本基准间的偏差

  6. 对照资金支出，监督工作绩效

  7. 防止在成本或资源使用报告中出现未经批准的变更

  8. 向有关干系人报告所有经批准的变更及其相关成本

  9. 设法把预期的成本超支控制在可接受的范围内

• 案例分析

  万能

  1. 项目经理可能项目管理经验不足，缺少成本管理意识

  2. 根据经验完成该过程不妥，依据不足，经验仅仅是组织过程资产

  3. 独自编制成本管理计划、成本基准不妥，项目经理应带领全体成员共同完成

  4. 成本管理计划、成本基准直接发布不妥，所有计划、文件必须评审

  5. 项目变更未执行变更控制流程；变更控制流程不合理，未严格按照变更控制流程制定；未建立CCB变更控制委员会，未书面记录变更请求，形成变更日志；所有变更请求必须以书面形式形成记录且经CCB进行批准；变更实施过程中未做好配置和版本管理，变更结束后未通知相关受影响干系人

  6. 项目监控不到位，监控过程贯穿于项目始终，因此导致进度滞后、成本超支、客户不满意

  7. 项目沟通管理存在问题，导致产生冲突

  成本（输入输出、工具内容角度）

  1. 项目成本管理就是要确保在批准的预算内完成项目

  2. 成本估算应该覆盖活动所使用的全部资源

  3. 只有经过实施整体变更控制过程的批准，才可以增加预算

  4. 有效成本控制的关键在于，对经批准的成本基准及其变更进行管理

质量

• 菲利普-克劳士比提出“零缺陷”的概念，他指出“质量是免费的“

• 质量故障成本是由于项目质量存在缺陷进行检测和弥补而引起的成本

• 项目质量是应顾客需求进行的，不同顾客有着不同的质量要求， 合同是项目质量管理的主要依据

• 规划质量管理

  1. 输入：干系人登记册、风险登记册、需求文件；项目管理计划、组织过程资产、事业环境因素

  2. 输出：质量管理计划、过程改进计划；质量测量指标、质量核对单、项目文件更新

  3. 工具技术：成本效益分析、质量成本、实验设计、标杆对照、老七种基本质量工具、统计抽样、会议、头脑风暴、力场分析、名义小组

  4. 老七基本质量工具(默写)：因果图，流程图，核查表；散点图，控制图（时间）；直方图，帕累托/排列图

     • 因果图(鱼骨图、石川图)：问题放在鱼的头部，作为起点来追溯问题来源，回推到可行动的根本原因

     • 流程图(过程图)：用来显示在一个或多个输入转化成一个或多个输出的过程中，所需要的步骤顺序和可能分支

     • 核查表(计算表)：是用于收集数据的查对清单，用核查表收集的关于缺陷数据或后果的数据，又经常使用帕累托图来显示

     • 散点图(相关图)：画出一条回归线，来估算自变量的变化将如何影响因变量的值

     • 控制图：用来确定一个过程是否稳定，或者是否具有预测的绩效，与时间有关

     • 直方图：是一种特殊形式的条形图，用于描述集中趋势、分散程度和统计分布形状，不考虑时间分布内的变化的影响

     • 帕累托图：是一种特殊的垂直条形图，用来识别造成大多数问题的少数重要原因，80/20法则；在任何特定的群体中，重要的因素通常只占少数，而不重要的因素则占多数，因此只要能控制关键性的少数因素即能控制全局

  5. 质量测量指标：准时性、成本控制、缺陷频率、故障率、可用性、可靠性和测试覆盖度等

• 实施质量保证

  1. 在实际质量管理过程中，多种质量管理工具可以综合使用，例如可以利用树形图产生的数据来绘制关联图

  2. 计划评审技术：又称为三点估算技术，其理论基础是假设项目持续时间，以及整个项目完成时间是随机的，且服从某种概率分布

  3. 新七种基本质量工具（默写）

  • 矩阵图，亲和图，关联图，过程决策程序图（PDPC目标步骤之间的关系）

  • 树形图/系统图（可用于表现WBS工作、RBS风险和OBS组织的层次分解结构）

  • 网络活动图（箭线图、节点图、计划评审技术PERT、关键路径法）

  • 优先矩阵图（用来识别关键事项和合适的备选方案，通过一系列决策，排列出备选方案的优先顺序）

• 实施质量保证：内容和作用

  1. 实施质量保证是一个执行过程，使用规划质量管理和控制质量过程所产生的数据

  2. 是审计质量要求和质量控制测量结果，确保采用合理的质量标准和操作性定义的过程

  3. 属于质量成本框架中的一致性工作，促进质量过程改进，为持续过程改进创造条件

  4. 通过持续过程改进，可以减少浪费，消除非增值活动，使各过程在更高的效率与效果水平上运行

• 实施质量保证：质量审计

  1. 又称质量保证体系审核，是对具体质量管理活动的结构性评审

  2. 质量审计可以是事先安排，也可随机进行

  3. 在具体领域中由有专长的内部、外部审计师实施

  4. 质量审计还可确认已批准的变更请求的实施情况

• 实施质量保证：质量审计5目标（默写）

  1. 识别全部正在实施的良好及最佳实践

  2. 识别全部违规做法、差距及不足

  3. 分享所在组织或行业中类似项目的良好实践

  4. 积极主动提供协助，改进过程的执行，帮助团队提高生产效率

  5. 强调每次审计都应对组织经验教训的积累做出贡献

• 质量控制

  1. 输入：项目管理计划、质量测量指标、质量核对单；工作绩效数据、组织过程资产；批准的变更请求、可交付成果、项目文件

  2. 输出：质量控制测量结果，核实的可交付成果；确认的变更，变更请求；工作绩效信息，项目管理计划更新，项目文件更新 (质量标准、协议、过程文档)，组织过程资产更新

  3. 工具技术：老七种基本质量工具、统计抽样（降低质量控制成本）、检查、审批

  4. 七种基本质量工具主要还是用在质量控制中，主要作用是确保可交付成果满足需求

• 实施质量保证/质量控制：区别（重点默写）

  1. 实施质量保证：是审计质量要求和质量控制测量结果，确保采用合理的质量标准和操作性定义的过程

  2. 质量控制：是监督并记录质量活动的执行结果，以便评估绩效，并推荐必要的变更过程

  3. 质量控制测量结果是对质量控制活动结果的书面记录，会作为实施质量保证的输入（输入、输出、工具角度）

  4. 质量控制（检查、测试）属于监控过程组，由 QC 完成

  5. 实施质量保证属于执行过程组，由 QA 完成

• 案例分析

  万能

  1. 项目经理可能项目管理经验不足，缺少质量管理意识

  2. 根据经验完成该过程不妥，依据不足，经验仅仅是组织过程资产

  3. 独自完成质量管理计划、过程改进计划不妥，项目经理应带领全体成员共同完成

  4. 质量管理计划、过程改进计划直接发布不妥，所有计划、文件必须评审

  5. 项目变更未执行变更控制流程；变更控制流程不合理，未严格按照变更控制流程制定；未建立CCB变更控制委员会，未书面记录变更请求，形成变更日志；所有变更请求必须以书面形式形成记录且经CCB进行批准；变更实施过程中未做好配置和版本管理，变更结束后未通知相关受影响干系人

  6. 项目监控不到位，监控过程贯穿于项目始终，因此导致进度滞后、成本超支、客户不满意

  7. 项目沟通管理存在问题，导致产生冲突

  8. 人员“兼职”问题，QA、QC必须专职

  质量（输入输出、工具内容角度）

  1. 规划质量管理存在问题，未编制质量管理计划、过程改进计划；未制订质量检查计划；没有明确的质量验收标准规范、质量方针、质量目标

  2. 实施质量保证存在问题 ，未按照质量管理计划执行；没有QA质量保证人员；没有进行测试；未进行质量审计(内部或外部审计)

  3. 控制质量存在问题 ，贯穿于项目始终；没有QC质量控制人员；产品质量和过程质量都要监控；需求评审必须进行质量控制

人力资源

• 编制人力资源管理计划

  1. 输入：项目管理计划、活动资源需求；事业环境因素、组织过程资产

  2. 输出：人力资源管理计划（角色与职责、项目组织图、人员配备管理计划-人员招募、资源日历、人员遣散计划、培训需要、认可与奖励、合规性、安全)

  3. 工具和技术：组织图和职位描述（责任分配矩阵）、人际交往、组织理论、专家判断、会议

  4. 角色和职责的定义形式：

     层级型：组织图，高层级，自上而下；工作分解结构 WBS、资源分解结构 RBS（有助于跟踪项目成本，能够与组织的会计系统协调一致）、组织分解结构 OBS

     矩阵型：职责图，责任分配矩阵 RAM--RACI 图，反映员工个人与其承担工作之间最直观的方法

     文本型：角色描述，记录详细职责

• 建设项目团队

  1. 输入：人力资源管理计划、项目人员分派、资源日历

  2. 输出：团队绩效评估

  3. 工具和技术：集中办公、培训、基本规则、认可与奖励；团队建设活动、人际关系技能、人事测评工具

  4. 马斯洛层次(默写)：生理的需要、安全需要、社会交往的需要、受尊重的需要、自我实现的需要

• 冲突管理6特点

  技术冲突一般发生在项目的执行阶段，个人冲突一般发生在项目的收尾阶段

  1. 冲突不可避免，冲突并不一定是有害的

  2. 冲突是自然的，而且要找出一个解决办法

  3. 冲突是一个团队问题，而不是某人的个人问题

  4. 冲突的解决应聚焦在问题，而不是人身攻击

  5. 冲突的解决应聚焦在现在，而不是过去

  6. 应公开地处理冲突（冲突应早被发现，利用私下但直接的、合作的方式来处理冲突）

• 冲突管理6方法（默写）

  1. 问题解决: 冲突各方一起积极定义问题、收集问题信息、制定解决方案，最后选择一个最合适的方案来解决冲突，是双赢、多赢、最理想的结果

  2. 合作：集合多方观点和意见，得出一个多数人接受和承诺的冲突解决方案

  3. 强制/强迫：以牺牲其他各方观点为代价，强制采纳一方的观点（输赢、零和游戏）

  4. 妥协：冲突各方协商寻找一种能够使冲突各方都有一定程度满意、但冲突各方没有任何一方完全满意，因而都做一些让步的冲突解决方法

  5. 求同存异：冲突各方都关注一致的一面，淡化不一致的一面。让大家都冷静下来，先把工作做完

  6. 撤退：把眼前或潜在的冲突搁置起来，从冲突中撤退

• 团队发展阶段：优秀团队的建设不是一蹴而就的，一般要依次经历形成、震荡、规范、发挥、解散5个阶段。若有新成员加入从形成重新开始

• 成功团队特点

  1. 团队的目标明确，成员清楚自己的工作对目标的贡献

  2. 团队的组织结构清晰，岗位明确

  3. 有成文或习惯的工作流程和方法，而且流程简明有效

  4. 项目经理对团队成员有明确的考核和评价标准，工作结果公正公开、赏罚分明

  5. 共同制订并遵守的组织纪律

  6. 协同工作，也就是一个成员工作需要依赖于另一个成员的结果，善于总结和学习

• 5 种基本权力（默写）

  合法权力、奖励权力、强制力（公司授权） + 专家权力、感召权力（本人），多用奖励权力和专家权力

• 案例分析

  万能

  1. 项目经理可能项目管理经验不足，缺少人力资源管理意识

  2. 根据经验完成该过程不妥，依据不足，经验仅仅是组织过程资产

  3. 独自完成人力资源管理计划不妥，项目经理应带领全体成员共同完成

  4. 人力资源管理计划直接发布不妥，所有计划、文件必须评审

  5. 项目变更未执行变更控制流程；变更控制流程不合理，未严格按照变更控制流程制定；未建立CCB变更控制委员会，未书面记录变更请求，形成变更日志；所有变更请求必须以书面形式形成记录且经CCB进行批准；变更实施过程中未做好配置和版本管理，变更结束后未通知相关受影响干系人

  6. 项目监控不到位，监控过程贯穿于项目始终，因此导致进度滞后、成本超支、客户不满意

  7. 项目沟通管理存在问题，导致产生冲突

  人力资源（输入输出、工具内容角度）

  1. 编制人力资源管理计划存在问题，未编制人力资源管理计划；项目型组织；项目经理权力问题；人员储备计划；新员工培训问题；人员角色和职责

  2. 组建项目团队存在问题，人员分派；虚拟团队；人员兼职问题，必须专职

  3. 建设项目团队存在问题，团队发展5个阶段；马斯诺需求层次理论；团队绩效考核标准问题；集中办公；培训；团队建设活动；人员激励方案

  4. 管理项目团队存在问题 ，冲突管理问题，应公开处理冲突；项目经理避免使用强制力；观察和交流

沟通/干系人

• 识别干系人

  1. 输入：项目章程、采购文件、事业环境因素、组织过程资产（干系人记录模板）

  2. 步骤：识别干系人及信息；评估关键干系人的诉求和影响力；对干系人分类；制定干系人管理计划

• 识别干系人-干系人分类

  权利/利益方格：根据干系人的职权大小和对项目结果的关注(利益)程度进行分类

  权力/影响方格：干系人的职权大小以及主动参与(影响) 项目的程度进行分类

  影响/作用方格：干系人主动参与(影响) 项目的程度及改变项目计划或者执行的能力进行分类

  凸显模型：根据干系人的权力(施加自己意愿的能力) 、紧迫程度和合法性对干系人进行分类

• 权力/利益方格

  A.权力高、利益低——令其满意；B.权力高、利益高——重点管理；

  D.权力低、利益低——花最少的时间监督；C.权力低、利益高——随时告知

• 及时性不是沟通的第一目标，沟通的目标是交换信息、澄清问题

• 沟通

  1. 方式没有优劣之分 ，但有不同的相对优缺点，应鼓励在不同场合下综合应用不同的沟通方式

  2. 过程（控制增强、参与减弱，默写）：讨论、(头脑风暴)、征询（调查问卷）、推销/说明、叙述（劝说鼓动）

  3. 控制沟通工具：项目例会、信息管理系统、专家判断（易错点）

  4. 沟通方法

     交互式沟通：在两方或多方之间进行多向信息交换，会议、电话、即时通信、视频会议

     推式沟通：把信息发送给需要接收这些信息的特定接收方，信件、备忘录、报告、电子邮件、传真、语音邮件、日志、新闻稿

     拉式沟通：用于信息量很大或受众很多的情况，企业内网、电子在线课程、经验教训数据库、知识库

• 案例分析

  万能

  1. 项目经理可能项目管理经验不足，缺少沟通/千系人管理意识

  2. 根据经验完成该过程不妥，依据不足，经验仅仅是组织过程资产

  3. 独自完成沟通管理计划/干系人管理计划不妥，项目经理应带领全体成员共同完成

  4. 沟通管理计划/干系人管理计划、干系人登记册直接发布不妥，所有计划、文件必须评审

  5. 项目变更未执行变更控制流程；变更控制流程不合理，未严格按照变更控制流程制定；未建立CCB变更控制委员会，未书面记录变更请求，形成变更日志；所有变更请求必须以书面形式形成记录且经CCB进行批准；变更实施过程中未做好配置和版本管理，变更结束后未通知相关受影响干系人

  6. 项目监控不到位，监控过程贯穿于项目始终，因此导致进度滞后、成本超支、客户不满意

  7. 项目沟通管理存在问题，导致产生冲突

  沟通（输入输出、工具内容角度）

  1. 制定沟通管理计划存在问题，未编制沟通管理计划，沟通管理计划与人力资源计划、干系人计划相关；沟通需求分析(个人或者组织为干系人)

  2. 管理沟通存在问题，未按照沟通管理计划执行；沟通方式单一，只采用了电子邮件/项目例会方式；项目经理应采用适合本项目的沟通方式、应针对不同的干系人制定不同的、适合于干系人的沟通方式，如拉式、推式、交互式；没有对沟通情况进行记录，无法了解沟通效果，所有沟通情况要形成书面记录；与干系人、团队成员沟通不足，对项目成员提出的沟通需求没有给出满意答复，应及时反馈问题解决方案；私下解决问题(避免例会批评团队成员); 沟通技巧

  3. 控制沟通存在问题，监控过程贯穿于项目始终；沟通中的冲突管理存在问题，冲突处理方法不当，采取强制手段制止项目成员抱怨；与各相关部门沟通存在问题，导致项目安排经常发生冲突

  干系人（输入输出、工具内容角度）

  1. 识别干系人存在问题，采购文件是识别干系人的主要依据；干系人的识别是否全面 (包含外包方)；干系人识别需要反复进行、需在早期进行；缺少对干系人的分析和分类 (权力/利益方格)，分析技术建立干系人参与评估矩阵

  2. 编制干系人管理计划存在问题，未编制干系人管理计划；采取群发周报形式，没有针对不同干系人的沟通需求提供项目信息

  3. 管理干系人存在问题 ，未按照干系人管理计划执行；沟通方法；人际关系技能

  4. 控制千系人参与存在问题，监控过程贯穿于项目始终；变更问题；冲突问题

风险

• 风险的认识

  特点：客观性，独立于人的意识；偶然性，信息不对称难预测；相对性，时空变化；不确定性，时间

  组织把风险看作不确定性给项目和组织目标造成的影响；基于不同的风险态度，组织和干系人愿意接受不同程度的风险，风险态度受风险偏好、风险承受力、风险临界值（易忘记）因素的影响

• 识别风险

  1. 输入: 风险/进度/成本/质量/人力资源管理计划、范围基准；活动成本估算/活动时间估算；干系人登记册、项目文件、采购文件；组织过程资产、事业环境因素

  2. 输出：风险登记册(已识别风险清单、潜在应对措施清单)

  3. 工具技术：文档审查、专家判断；核对表分析、假设分析、SWOT 分析；信息收集技术（德尔菲、头脑风暴、访谈、根本原因识别）、图解技术(因果图、系统/过程流程图、影响图)

  4. 文档审查：是对项目文档进行结构化审查

  5. 核对单：简单易用但无法穷尽所有事项

  6. SWOT 分析：可用于考察组织优势能够抵消威胁的程度

  7. 专家判断：拥有类似项目或业务领域经验的专家可以直接识别风险

  8. 图解技术

     • 因果图：石川图或鱼骨图，用于识别风险的成因

     • 系统/过程流程图：显示系统各要素之间如何相互联系，以及因果传导机制

     • 影响图：显示因果影响，按时间顺序排列的事件，以及变量与结果之间的其他关系的图解表示法。用图形方式表示变量与结果间的因果关系、事件时间顺序及其他关系

  9. 可能的风险（默写）

     范围蔓延风险；进度风险，进度滞后；成本风险，成本超支；质量风险，后期返工风险；干系人不同意的风险；

     （接口不配的风险、数据不匹配的风险、数据存储风险）

• 规划风险应对

  1. 风险应对措施应由所有相关方商定并由1名负责人具体负责

  2. 风险应对措施必须与风险的重要性相匹配

  3. 积极风险的应对策略

     分享，提高，接受，拓展

     分享：是把应对机会的部分和全部责任分配给最能为项目利益抓住该机会的第三方

  4. 消极风险/危险的应对策略

     • 接受：接受或默认风险的存在（应急储备）

     • 减轻：冗余思想，风险依然存在（找一个有相关技术经验的专家来处理这个风险，高影响）

     • 转移：转移至第三方（保障、保险）

     • 规避：风险有效规避，可能不存在（改变计划、减小活动范围，高影响）

• 风险控制

  1. 输入：项目管理计划、风险登记册、工作绩效数据、工作绩效报告

  2. 输出：变更请求、工作绩效信息、项目文件更新、项目管理计划更新、组织过程资产更新

  3. 工具和技术：风险再评估、风险审计；偏差和趋势分析、储备分析；会议、技术绩效测量

  4. 作用(默写)：控制风险在整个项目中实施风险应对计划、跟踪已识别风险、监督残余风险、识别新风险，以及评估风险过程有效性。在整个项目生命周期中提高应对风险的效率，不断优化风险应对措施

• 案例分析

  万能

  1. 项目经理可能项目管理经验不足，缺少风险管理意识

  2. 根据经验完成该过程不妥，依据不足，经验仅仅是组织过程资产

  3. 独自完成风险管理计划不妥，项目经理应带领全体成员共同完成

  4. 风险管理计划、风险登记册直接发布不妥，所有计划、文件必须评审

  5. 项目变更未执行变更控制流程；变更控制流程不合理，未严格按照变更控制流程制定；未建立CCB变更控制委员会，未书面记录变更请求，形成变更日志；所有变更请求必须以书面形式形成记录且经CCB进行批准；变更实施过程中未做好配置和版本管理，变更结束后未通知相关受影响干系人

  6. 项目监控不到位，监控过程贯穿于项目始终，因此导致进度滞后、成本超支、客户不满意

  7. 项目沟通管理存在问题，导致产生冲突

风险（输入输出、工具内容角度）

1. 规划风险管理存在问题，未编制风险管理计划，规划风险管理应在项目规划过程的早期完成

2. 识别风险存在问题，是一项反复过程，应鼓励所有项目人员参与

3. 定性风险分析包括为了采取进一步行动，对已识别风险进行优先排序的方法

4. 定量风险分析一般在定性风险分析之后进行，经验丰富的风险经理可以在风险分析过程之后直接进行定量分析

5. 风险应对措施应由所有相关方商定，并由一名负责人负责

6. 控制风险以及其他风险管理过程是项目生命周期内不间断实施的过程

7. 可以在日常的项目审查会中进行风险审计，也可单独召开风险审计会

8. 项目不同阶段会有不同的风险。风险大多随项目进展而变化，不确定性会随之逐渐减少。最大的不确定性存在于项目的早期

采购

• 识别需求是采购过程的起点，采购审计是结束采购的技术

• 编制采购管理计划

  1. 输入：千系人登记册、风险登记册、需求文档；项目进度、活动资源需求、活动成本估算、项目管理计划、事业环境因素、组织过程资产（两册文档+进度、资源、成本）

  2. 输出：采购文件、采购管理计划、采购工作说明书；供方选择标准、自制/外购决策；变更请求、项目文件更新

  3. 自制/外购分析

     • 应该考虑所有相关的直接成本和间接成本，有时项目的执行组织可能有能力自制，但是可能与其他项目有冲突或自制成本明显高于外购，在这些情况下项目需要从外部采购，以兑现进度承诺。保密项目必须自制

     • 任何预算限制都可能是影响“自制/外购”决定的因素，如果决定购买，还要进一步决定是购买还是租借

  4. 采购文件：包括采购需要的各种文书

     • 方案邀请书/请求建议书：RFP，征求潜在供应商建议的文件

     • 报价邀请书/请求报价单：RFQ，依据价格选择供应商时，用于征求潜在供应商报价的文件，一般项目执行组织多在涉及简单产品的招标中使用

     • 征求供应商意见书：RFI，用来征求供应商意见，以使需求明确化。如果需求很明确，则用方案邀请书RFP

     • 投标邀请书：IFB，采用邀请招标方式的招标人，向三个以上具备承担招标项目的能力、资信良好的特定的法人或者其他组织发出

     • 招标通知书、治谈邀请以及承包商初始建议征求书

• 编制采购管理计划：采购工作说明书内容（默写，易忘记）

  前言、方法、假定；服务范围、服务期限和工作量估计；双方角色和责任、交付资料、完成标准；顾问组人员、收费和付款方式、变更管理

• 实施采购

  1. 输入（重点默写）：采购文件、采购工作说明书；卖方建议书、供方选择标准、自制/外购决策；项目文件、项目管理计划、组织过程资产

  2. 输出：合同、选定的卖方、资源日历；变更请求、项目文件更新、项目管理计划更新

  3. 潜在卖方的报价建议书是根据买方的采购文件制定的

  4. 采购谈判过程以买卖双方签署文件 (如合同、协议) 为结束标志

  5. 在合同谈判期间，项目管理团队可列席

  6. 供应商选择的三大主要因素：价格、质量、服务，其他因素: 位置、库存、柔性

  7. 资源日历：表明每种具体资源的可用工作日和工作班次的日历，用来确定项目进行各个阶段，项目团队成员可以在项目上工作的时间

• 实施采购：政府采购方式

  1. 公开招标、邀请招标、竞争性谈判、单一来源采购、询价采购和国务院政府采购监督管理部门认定的其它方式

  2. 合同分类（付款方式，默写）：固定总价合同、成本补偿合同、工时和材料合同

  3. 竞争性谈判公告至谈判文件递交截止时间一般不得少于5天，采购数额在300万元以上、技术复杂的项目一般不得少于10天；招标20天

  4. 资格预审文件或者招标文件的发售期不得少于 5 天；退换保证金5日，公示日期不少于3日，发出投标文件是20日，招标方更改招标文件截止开标前15日，30日内完成书面合同；投资保证金不得超过招标项目估算价的 2%； 中标候选人应当不超过 3 个，并标明排序（易错点）

  5. 订立项目分包合同必须同时满足 5 个条件：(1) 经过买方/发包人认可。(2)分包的部分必须是项目非主体工作。 (3) 只能分包部分项目，而不能转包整个项目。(4)分包方必须具备相应的资质条件。（5) 分包方不能再次分包

• 实施采购：招投标程序（默写）

  1. 发布招标公告(公开招标、邀请招标)

  2. 招标人根据招标项目的具体情况，可以组织所有潜在投标人踏勘项目现场

  3. 投标人投标

  4. 开标

  5. 评标

  6. 确定中标人

  7. 订立合同

• 控制采购

  1. 输入: 合同/合同管理计划、采购文件、批准的变更请求；项目管理计划、工作绩效数据、工作绩效报告

  2. 输出：变更请求、工作绩效信息、项目文件更新、项目管理计划更新、组织过程资产更新

  3. 确定后的采购需求在履行中发生变更，需走变更控制审批流程

  4. 控制采购过程是买卖双方都需要的

  5. 合同索赔

     涉及承建方、建设方、监理方三方，涉及索赔工期均为 28 天；合同索赔流程：提出索赔要求28 天内、报送索赔资料28 天内、监理工程师答复 28 天内、监理工程师逾期答复结果、持续索赔28 天、仲裁与诉讼

• 案例分析

  万能

  1. 项目经理可能项目管理经验不足，缺少采购管理意识

  2. 根据经验完成该过程不妥，依据不足，经验仅仅是组织过程资产

  3. 独自完成采购管理计划、采购文件、采购工作说明书不妥，项目经理应带领全体成员共同完成

  4. 采购管理计划、采购文件、采购工作说明书直接发布不妥，所有计划、文件必须评审

  5. 项目变更未执行变更控制流程；变更控制流程不合理，未严格按照变更控制流程制定；未建立CCB变更控制委员会，未书面记录变更请求，形成变更日志；所有变更请求必须以书面形式形成记录且经CCB进行批准；变更实施过程中未做好配置和版本管理，变更结束后未通知相关受影响干系人

  6. 项目监控不到位，监控过程贯穿于项目始终，因此导致进度滞后、成本超支、客户不满意

  7. 项目沟通管理存在问题，导致产生冲突

  采购（输入输出、工具内容角度）

  1. 编制采购管理计划存在问题，未制定采购管理计划。项目生命周期模型的选择是否恰当？项目的组织结构是否选择合理？采购需求识别是否全面？是否经干系人确认？自制/外购是否合理？采购部门是否按照变更后的合同制定采购计划？

  2. 实施采购存在问题。采购谈判、询价比价是否存在问题？采购管理是否执行采购管理流程？项目招投标方式、招投标流程、评标流程是否合理合规？招投标法中的“综合评分法”和“最低价评分法”是否正确理解？违反投标法违法分包、转包？供应商选择是否存在问题，是否考虑价格、质量、服务等综合因素？对设备的采购备件是否执行不合格控制？合同约定的保密条款任何一方不得泄露，不得泄露给第三方，合同违约责任是否清楚？合同类型选择是否合理？

  3. 控制采购存在问题，是否执行采购监控？工期延期、范围变更后合同是否执行变更流程？是否补签协议，是否进行补签协议的盖章确认？合同索赔流程是否存在问题？

  4. 结束采购存在问题

配置

• 判断

  • 信息系统相关信息(文档)具有永久性——（T）

  • 按开发任务建立相应的配置库，适用于通用软件的开发组织——（F）

  • 配置控制是配置管理过程的基础——（F）——配置管理计划

  • 每个产品都有配置基线，一个产品只有一个配置基线 ——（F）

  • 配置库是存放配置项并记录与配置项相关的所有信息，是配置管理的有力工具——（T）

  • 动态库是开发人员的个人工作区，由开发人员自行控制——（T）

  • 配置控制委员会CCB不必是常设机构——（T）

  • 小的项目CCB可以只有一个人，但必须是专职人员——（F）

• 基线

  • 基线配置项向开发人员授权，非基线配置项向项目管理人员、CCB授权

  • 随着项目的进展，需求基线将越定越高，容许的需求变更将越来越少

• 配置库

  1. 开发库：动态库、程序员库、工作库，用于保存开发人员当前正在开发的配置实体，是开发人员的个人工作区，由开发人员自行控制

  2. 受控库：主库，包含当前的基线加上对基线的变更。在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库

  3. 产品库：静态库、发行库、软件库，包含已发布使用的各种基线的存档。在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装

• 变更管理中的配置管理活动（默写）：配置标识、配置状态记录、配置审计

• 配置管理 6 项活动（默写）

  1. 配置管理计划：明确任务

  2. 配置标识：建立基线

  3. 配置控制：管理变更

  4. 配置状态记录/报告：草稿、正式、修改

  5. 配置审计/审核/评价：独立评价，功能配置审计验证配置项的一致性，物理配置审计验证配置项的完整性；配置审计的实施是为了确保项目配置管理的有效性，体现了配置管理的最根本要求-不允许出现任何混乱现象

  6. 发布管理和交付：存储、复制、打包、交付、重建（默写）

• 配置标识：内容（默写）

  1. 识别需要受控的配置项

  2. 为每个配置项指定唯一性的标识号

  3. 定义每个配置项的重要特征

  4. 确定每个配置项的所有者及其责任

  5. 确定配置项进入配置管理的时间和条件

  6. 建立和控制基线

  7. 维护文档和组件的修订与产品版本之间的关系

• 配置标识：典型配置项

  项目计划书、需求文档、设计文档；源代码、可执行代码；测试用例、运行软件所需的各种数据

• 配置控制：变更流程

  1. 将待升级的基线(假设版本号为 V2.1)从产品库取出，放入受控库

  2. 程序员将欲修改的代码段从受控库检出Check out，放入自己的开发库中进行修改。代码被 Check out 后即被“锁定”，以保证同一段代码只能同时被一个程序员修改，如果甲正对其修改，乙就无法 Check out

  3. 程序员将开发库中修改好的代码段检入Check in受控库。Check in 后，代码的“锁定”被解除，其他程序员可以 Checkout 该段代码了

  4. 软件产品的升级修改工作全部完成后，将受控库中的新基线存入产品库中(软件产品的版本号更新为 V2.2，旧的 V2.1 版并不删除，继续在产品库中保存)

• 配置管理员的配置管理活动(默写)

  1. 编写配置管理计划

  2. 建立和维护配置管理系统

  3. 建立和维护配置库

  4. 配置项识别

  5. 建立和管理基线

  6. 版本管理和配置控制

  7. 配置状态报告

  8. 配置审计

  9. 发布管理和交付

  10. 对项目成员进行配置管理培训

• 

• 案例分析

  万能

  1. 项目经理可能项目管理经验不足，缺少配置管理意识

  2. 根据经验完成该过程不妥，依据不足，经验仅仅是组织过程资产

  3. 项目经理完成配置管理计划不妥，应由配置管理员完成

  4. 配置管理计划直接发布不妥，所有计划、文件必须评审

  5. 项目变更未执行变更控制流程；变更控制流程不合理，未严格按照变更控制流程制定；未建立CCB变更控制委员会，未书面记录变更请求，形成变更日志，所有变更请求必须以书面形式形成记录且经CCB进行批准；变更实施过程中未做好配置和版本管理，变更结束后未通知相关受影响干系人

  6. 项目监控不到位，监控过程贯穿于项目始终，因此导致进度滞后、成本超支、客户不满意

  7. 项目沟通管理存在问题，导致产生冲突

  8. 人员“兼职”问题，配置管理员应该专职；开放所有的配置权限不妥， 权限应当分别配置

  配置（输入输出、工具内容角度）

  1. 配置管理计划：未制订配置管理计划

  2. 配置标识：未进行配置项的识别

  3. 配置控制：缺少配置控制；缺少基于配置库的变更控制流程；向配置管理员提出变更申请不妥，应向 CCB 提出变更申请，由 CCB 批准或否决；删除了旧的代码存在问题，应该保留旧的版本号；

  4. 配置状态记录：未进行配置状态报告；没有进行配置状态报告更新；正式的版本号应该表示为“X.Y”

  5. 配置审计：未进行配置审计

  6. 发布管理和交付：未进行发布管理与交付；新版本由项目经理发布不妥，应由 CMO 配置管理员发布

变更

• 分类

  根据变更性质：重大变更、重要变更、一般变更，通过不同审批权限控制

  根据变更的紧迫性：紧急变更、非紧急变更，通过不同变更处理流程进行

• 变更过程涉及到的角色（默写） 项目经理、配置管理员；变更控制委员会、变更申请人、变更执行人

• 变更合同价款

  1. 公平合理是合同变更的处理原则

  2. 首先确定合同变更量清单，然后确定变更价款

  3. 合同中已有适用于项目变更的价格，按合同已有的价格变更合同价款

  4. 合同中只有类似于项目变更的价格，可以参照类似价格变更合同价款

  5. 合同中没有适用或类似项目变更的价格，由承包人提出适当的变更价格，经监理工程师和业主确认后执行

• 监理活动主要内容

  四控：信息系统工程质量、进度、投资、变更控制

  三管：信息系统工程合同、信息、安全管理

  一协调：在信息系统工程实施过程中协调有关单位及人员间的工作关系

• 变更管理变更流程（默写） 提出变更申请、变更影响分析、CCB 审查批准、实施变更、监控变更实施、结束变更

• 案例分析

  1. 所有变更都必须遵循变更控制流程进行控制，项目是否执行变更控制流程、是否建立变更控制委员会 CCB

  2. CCB 由项目所涉及的多方人员共同组成，通常包括用户和实施方的决策人员。小的项目 CCB 可以只有一个人，甚至只是兼职人员

  3. 项目的任何干系人都可以提出变更申请，所有变更申请都必须以书面形式记录，并纳入配置管理系统中，同时要通知相关人员

  4. 明显不合理的变更请求、超出范围边界的变更请求是否有效应对

  5. 项目经理响应变更提出者的需求，评估分析变更对项目的影响及应对方案，对项目负责，也对整个项目变更管理过程负责。项目经理是受业主委托对项目经营过程负责者，其正式权利由项目章程取得，而资源调度的权力通常由基准中明确。基准中不包括的储备资源需经授权人批准后方可使用

  6. 变更申请人提交的每个变更申请都必须由一位责任人批准或否决，这个责任人通常是项目发起人或项目经理，必要时应由变更控制委员会 (CCB) 进行审查批准

  7. 变更实施是否有效监控，变更实施人负责执行已批准的变更，也要参与变更正确性的确认工作

  8. 配置管理员负责把变更后的基准纳入整个项目基准中，所有配置项的操作权限应由 CMO(配置管理员)严格管理；在项目实施过程中，每个基线都要纳入配置控制，对这些基线的更新只能采用正式的变更控制程序

收尾

• 项目收尾管理工作具体内容（默写）

  项目验收、项目总结、系统维护、项目后评价

• 行政收尾与合同收尾

  • 行政收尾是针对项目和项目各阶段的，不仅整个项目要进行一次行政收尾，而且每个项目阶段结束时都要进行相应的行政收尾；而合同收尾是针对合同的，每个合同需要而且只需要进行一次合同收尾

  • 从整个项目说，合同收尾发生在行政收尾之前；从某个合同角度说，合同收尾中又包括行政收尾工作(合同的行政收尾)

  • 行政收尾要由项目发起人或高级管理层给项目经理签发项目阶段结束或项目整体结束的书面确认；合同收尾则要由负责采购管理成员(可能是项目经理或其他人)向卖方签发合同结束的书面确认

• 项目验收：工作内容

  验收测试、系统试运行、系统文档验收、项目终验（最终验收标志着项目的结束和售后服务的开始）

• 项目验收：系统集成项目包含文档（默写）

  系统集成项目介绍、系统集成项目最终报告；信息系统说明手册、信息系统维护手册；软硬件产品说明书、质量保证书

• 项目总结：项目的总结会

  需要全体参与项目的成员都参加，并由全体讨论形成文件，同时项目总结会需要讨论项目绩效、项目经验教训等实质性内容，具有非常重要的意义

• 项目总结：项目总结讨论内容（默写）：

  项目绩效、技术绩效、成本绩效、进度计划绩效；项目的沟通；识别问题和解决问题；意见和建议

• 项目后评价

  信息系统目标、过程、效益、可持续性评价

• 项目评估的依据：盈利、客户满意度、后续项目指标、内部满意度要求

其他

• 休哈特：统计过程控制SPC理论，应用统计技术对生产过程进行监控，以减少对检验的依赖；戴明：质量改进

• 朱兰，全面质量管理

• 《个人信息保护法》于2021年11月1日正式施行（通常都是1日施行）

• 《中华人民共和国数据安全法》于2021年9月1日正式施行

• 我国国家标准由SAC 国家标准化管理委员会进行管理

• 我国现行专利法规定的发明专利权保护期限为20年

• 国家标准9过程：准备、立项、起草；征求意见、审查、批准；出版、复审、废止(有效期5年)

• 知识产权：

  1. 域外效力的取得，对著作权而言，依赖于国际公约或者双边协定即可；专利权、商标权则必须有他国行政主管机关的确认，方可产生法律效力

  2. 特性：无体性、专有性、地域性、时间性

  3. 使用权是商标权的核心权利

• 著作权：

  1. 不需要登记或标注版权标记就应得到保护，非法人单位的作品，不论是否发表，依照本法享有著作权

  2. 外国人的作品首先在中国境内发表的，依照本法享有著作权。外国人在中国境内发表的作品，根据其所属国同中国签订的协议或者共同参加的国际条约享有的著作权，受本法保护

  3. 没有作品就没有著作权，脱离具体作品的著作权是不存在的（50年）

  4. 著作权三要素：著作权主体、著作权客体、著作权内容