【项目管理】PMP备考宝典-第二章《环境》

第一节：概述

1.项目所处的组织环境

（1）事业环境因素（EEFs）

组织内部的事业环境因素：

企业都会有愿景、使命、价值观，这些决定了企业的发展方向。不忘初心，坚定地走自己的路，这样的经营理念就决定了企业里“什么项目可以做，什么项目不做”的基本原则。

企业在做项目之前应充分考虑自身的软件、硬件条件。例如，场地、设备在很大程度上会影响项目的决策方案和成本、进度、沟通等各项计划；企业的信息化平台、系统、管理流程、制度这些软件条件也深刻的影响着项目的规划和实施。

组织外部的事业环境因素：

团队做项目必须遵守自己国家及项目所在地的法律、法规、行业标准、规范，这些都需要团队先认真学习，研究，因为依法合规是项目管理的底线。

另外，团队还要充分研究市场、经济和自然环境因素，即便项目已经开始，也要持续分析市场形势、静静形式和国际局势的变化。如果是对自然环境因素敏感的工程项目，团队还必须关注水文、地质、气象、灾害等对项目等影响。

（2）组织过程资产（OPAs）

过程、政策和程序

过程、政策和程序是用来规范和指导项目管理的，例如，项目立项要经过哪些步骤，项目验收要满足哪些条件，需求变更该走什么程序。

过程、政策和程序也包括项目管理办公室（PMO）整理和编撰的项目计划板、操作手册、项目管理指南等。

组织和识库

管理成熟的企业都很重视知识管理，做过的项目都有完整、规范、及安全的档案，包含项目计划、项目经验和教训，以便于以后的项目团队参考。

企业收集、购买的行业数据、洗你想和资料也是项目中很重要的资源。

以上知识只有通过规范和严谨的管理，才能被妥善地保存、维护、检索和分享，发挥出它们的价值。

事业环境因素与组织过程资产的区别

	事业环境因素（EEFs）	组织过程资产（OPAs）
出自	政府、行业协会、公司管理层	历史项目团队及PMO
用于	遵守	参考
方式	被动接受，入乡随俗	主动参与，更新维护

下面属于事业环境因素的是（B）。

A.上一个项目的经验教训登记册

B.项目管理信息系统（PMIS）

C.企业购买的最新的行业数据

D.整体变更控制程序

答案：B。企业提供的项目管理信息系统( PMIS ) 和其他企业信息化平台(如CRM、ERP、OA 等)性质相同，需要所有项目团队都规范使用，属于项目团队必须遵守的组织内部的流程制度。不过，PMIS 中保留下来的以往项目的数据、模板日志、报告等都属于组织过程资产。A、C、D 选项都属于组织过程资产。D 选项整体变更控制程序，每个项目的变更程序都是根据发起人和各参与方的意见为这个项目单独制定的，是项目各参与方的共识，不同的项目不一定通用。

2.组织结构类型

需要注意的是，下图中的矩阵( 弱矩阵、平衡矩阵和强矩阵 ) 与 PMP考题中出现的 “紧密型矩阵” 不是同一范畴的概念。紧密型矩阵并不是一种矩阵组织而是指团队成员集中办公( War Room)，这样有利于团队建设、提高团队沟通协作效率。

职能型组织

如下图，在职能型组织中，资源由职能经历掌握，项目的协作至少要在职能经理这个层次沟通。

职能型组织通常适用于项目规模较小、历时短，或以技术和运营为主体的组织，如工厂、医院。

矩阵型组织

如下图，矩阵型组织有不同的职能部门（纵向），也有不同的项目团队（横向）。

矩阵型组织应用比较广泛，它既能发挥职能分工的优势，又能满足项目管理的要求。

项目型组织

如下图，在项目型组织中，独立的项目公司或公司高层直接管理多个项目经理，项目经理管理项目团队。

项目型组织适用长期、大型和复杂的项目，如航天工程、大型基础设施建设项目、综合房地产开发项目。

职能型、矩阵型和项目型的优缺点对比

类型	优点	缺点
职能型	发挥职能部门资源集中的优势 在人员使用上有较大的灵活性 同部门人员在一起易于交流只是和经验 项目人员的流动不影响技术的连贯性 为本部门人员提供一条正常的晋升途径	项目往往不能成为职能部门工作的焦点 不同的项目在资源使用的优先权上容易产生冲突 项目所有者不明确，容易导致无人责任 对客户的响应迟缓且艰难 调配给项目的人员积极性不高 跨部门的交流比较困难
矩阵型	充分利用组织资源，避免重复设置 有利于集中各部门的技术、管理优势 对客户及公司组织内部的响应快速、灵活 项目团队能保存与公司政策的一致性	违反了命令单一性原则 项目经理与职能经理在工作优先级上存在冲突
项目型	项目所有者明确 命令单一、决策速度快 易于沟通和协调 可充分发挥团队的优势 对客户的响应速度快 组织结构简单灵活，易于操作	资源独占，可能造成浪费 机构重复设置，不利于共享 团队成员缺乏安全感和归属感 团队之间横向联系少，经验分享难 易导致不同项目团队对公司规章制度的执行不一致

项目管理者在不同组织中的特征

3.治理模式与管理流程

治理与管理

我们来认识一下企业中治理和管理之间的联系。

治理可以被理解为“定规矩”，实现责、权、利的合理分配与制衡，例如，公司里谁向谁汇报，谁对谁负责。管理是在治理的框架下实现经营目标的所有举措。

治理和管理都是为了组织健康发展服务的，它们之间是相辅相成的关系: 治理给管理指明了方向、规划了路线、划清了边界;经营层在管理实践中也会不断向董事会反馈并与其互动，从而使董事会动态地调整和优化治理结构。

企业中治理与管理的区别如表：

	治理（Governance）	管理（Management）
定位	宏观、稳定	具体、灵活
目的	设计组织制定、制定规则、定义决策机制	提升组织效率、达成经营目标
主体	董事会	经营层

组织治理与项目治理

我们还需要理解组织治理与项目治理的区别和联系。组织治理是针对整个组织的高级别的指导、支持、监督与控制框架。项目治理是组织为项目建立的高级别的指导、支持、监督与控制框架。项目治理由项目指导委员会执行。作为项目的最高决策机构，项目指导委员会由项目主要干系人的高层代表组成，相当于公司的董事会。

项目治理与项目管理

项目治理是联系组织治理与项目管理之间的桥梁，项目经理和项目管理团队必须在项目治理框架下开展项目管理工作。项目治理是把项目经理无力处理或不便处理的项目的“政治”问题(如干系人之间的利益冲突) 剥离出来，交给项目指导委员会处理，以便项目经理可以专注于项目本身的管理。

项目治理的层次高于项目管理，是高层次的项目决策机制。项目治理的作用包括不限于以下几点：

• 提供项目方向指导
• 提供高层及外部支持
• 监督项目管理工作
• 对项目所有权变更、项目中止等大事项进行决策

例如，企业里项目组合管理、项目集管理的机制、项目经理的任职资格和晋级规则、PMO 的权限和职责定义、项目立项标准和评审流程都属于项目治理，而项目的计划与控制，以及进度、成本、质量等目标的实现属于项目管理范畴。

企业文化

企业文化包含是三个层次，从低到高分别如下。

• 物质层：企业的形象、标识、工作环境等。
• 制度层：企业的流程、制度、人际关系。
• 理念层：企业的传统、追求、价值观。

企业文化企业的灵魂，好的企业文化可以激发员工的使命感，凝聚员工的归属感，加强员工的责任感，赋予员工荣誉感，实现员工的成就感。企业文化薪火相传，使企业具有鲜明的个性和特性，体现了企业的经营哲学，构成了企业的品牌美誉度和独特竞争力。

战略

项目是战略落地的载体，这个定位决定了项目必须服务于组织发展战略。项目与战略的关系，可以从以下四个方面去理解。

投资决策

组织发展战略决定了组织发展的方向，也就决定了哪些项目必须做，哪些项目可以做，哪些项目不能做。精力需要专注，资源需要集中，只有深耕某个领域才能积蓄能力，获得竞争优势。在众多项目机会面前，必须经得住诱惑，坚决而果断地根据组织发展战略做出取舍。

分配资源

因为不同的项目对企业发展战略的意义也不同，即便组织选择了投资这个项目，也必须客观地分析项目的优先级，如此才能科学地分配资源，实现投资效益最大化的目标。

战略一致性

在项目生命周期中，由于受到各种外界环境和内部协作的影响，项目计划需要不断调整和变更。无论计划如何改变，都必须始终保证项目与组织发展战略的一致性。

战略价值

组织应该持续评估项目对组织发展战略的价值和贡献，这不仅体现在市场份额和财务指标上，还体现在人才培养、效率提升、技术突破、模式创新、质量改进环境贡献、品牌价值等方面。

企业中的软硬件条件

企业所拥有的工作场所、设备、工具等属于硬件条件，而信息系统、知识、经验、方法、工艺等属于软件条件，这些都会直接或间接地影响项目的规划、实施甚至项目的成败。

比如，我们因为没有制造高端芯片的光刻机而受制于人，很多依赖高端芯片的产品研发项目被迫停滞或搁浅:而中国交通建设集团因为拥有亚洲最大的重型自航式绞吸船“天鳃号”，在疏浚项目中大显身手，在国际市场上所向披靡。

4.项目所处的商业环境

项目所处的商业环境包含专业、行业、经济、社会、自然等多个方面。

• 专业：往往指团队可以凭借的优势，比如，你的团队专注于大数据算法、AR、VR或者人工智能等，依赖丰富的经验或独特的技术构建起自己的核心竞争力。
• 行业：项目多处的专业应用领域，比如，将人工智能应用于金融、医药或者汽车行业。
• 经济：包含国内的经济、贸易、金融、供应链及竞争关系。
• 自然：包括交通状况、气候、卫生等。

第二节：原则

1.识别和响应系统交互

项目总是处于由多种因素构成的复杂、动态、有机的系统中，很难剥离出业种因素对项目的影响。各个因素之间相互作用，彼此影响。

• 项目团队应该具备系统性思维，系统性思维包含以下三个关键词。
• 协作：促进多专业、多部门、多组织构成多元协作体系。
• 平衡：理清个元素之间的逻辑，平衡各主题之间的关系。
• 效率：把系统当作一个生命体，不断优化演进，提升系统的效率。

掌握了这三个关键词，有助于项目团队连续做出正确的判断，减少偶然性，把目标变成可操作性的方法和步骤，也可以及时发现并纠正偏差和错误。

拥有系统性思维常用的方法是建模和推演。比如在足球比赛中，赛前教练会用战术板给队员们讲解本场比赛敌我双方的阵型和战术，推演各种可能的情况，比如对手如果采取高位逼抢，我们如何稳固防线，如何寻找破解的机会。再比如，在海湾战争中联合国军构建了战争模型，推演了多种作战方案，模拟了可能发生的各种情况。

2.驾驭复杂性

必须接受项目的复杂性，复杂性的成因包含以下三个方面。

• 系统行为：项目需要的专业、人员、设备、信息等要素数量庞大，且彼此相互依赖和影响。
• 人为行为：不同组织、不同部门、不同专业背景的人在一起产生的相互作用。
• 不确定性：在项目发展趋势和各种要素的变化中存在未知领域，对此缺乏理解，也无法预测。

这三个方面的因素相互作用，导致项目的复杂性成指数级上升。

如何驾驭复杂性

可以从**“拥抱变化” “管理知识” “持续学习”**三个方面人手，在态度、认知和行为习惯上持续提升管理项目复杂性的能力，并逐渐形成自己的管理思想和管理模式。

比如，敏捷开发就是从小范围、小规模的局部实践开始，不断发展成熟，形成了面对不同需求、不同场景的较为完整、成体系的敏捷企业文化，如图所示。

管理项目知识

管理项目知识是指使用现有知识并生成新知识，以实现项目目标，并帮助组织学习的过程。

如下图所示，知识分为显性知识和隐性知识。可以编辑、易于表达的知识属于显性知识，比如，可以用文字、图片、数字、表格展示的容易分享和传播的:识。无法编辑、难以表法的知识属于隐性知识，比如人们的经验、直觉、洞察力诀窍。

知识管理的PSCA循环

如图，PSCA 循环的含义是将知识管理分为四个过程，即知识生成 (Produce )、知识积累( Stockpile )、知识交流( Communication )、知识应用( Application )。

知识生成( Produce )

知识生成是指知识的获取与创造。获取知识是指对已有的知识进行沉淀，形成显性知识;而创造知识是指在开展具体业务和工作中对知识进行的总结和创造。

知识积累( Stockpile )

支离破碎的数据、信息并不能称为知识，只有把它们组织起来才能称其为知识。

例如，看一本书，如果只是走马观花地浏览一遍，没有通过记笔记、画思维导图等方式对作者的思想进行整理、提炼和思考，并将作者的思想与我们已有的知识进行匹配融合、重新组织、再次表达出来，那么书里的内容很快就会被我们淡忘了，书里的知识没有经过积累，就无法转化为我们自己的知识。

组织对不同形式的知识有如下不同的积累方式。

• 显性知识的积累:创建“知识库”，并持续维护、运营。
• 隐性知识的积累:一方面，通过分享、演示、观摩、师傅带徒弟等方式，让这些隐性知识不会失传;另一方面，也要减少拥有隐性知识的人才的流失。

知识交流 ( Communication )

知识交流是指通过直接或间接的方式进行知识传递和分享，以满足不同主体对各类知识的需求。

每个知识工作者都应该以一种开放的心态对知识进行交流、讨论，使真理越辩越明。

知识应用 ( Application )

如果不运用知识，那么知识就还不是自己的！

例如，我们英语学了很多年，学过大量语法，背过无数单词，可结果我们对我们自己的英语水平还不满意，只有把知识用在实践中，通过实践形成反馈，才能使自己的认知得到升级。

3.拥抱适应性和韧性

拥抱适应性

VUCA 时代，环境多变，需求未知，只有拥抱适应性，构建起项目的韧性，能身轻如燕、闪转腾挪，在复杂多变的背景下驾驭项目，并取得成功。

敏捷就是在这样的背景下诞生的，敏捷不仅是一种项目开发方法，而且是~种提升项目适应性的思想。敏捷开发常见的框架有 Scrum、极限编程(XP 、看板(Kanban )、精益等，其中，使用 Scrum 框架的团队在全球超过 50%。

Scrum 这个词源自橄榄球比赛，它是并列争球的仪式，形容团队需要面向相同的方向，并肩作战。框架中的 Sprint，我们把它翻译成冲刺，用以形容选代周期非常短，在冲刺中能够获得对变化更好的适应和响应能力。

敏捷中强调去中心化，避免一言堂，要激发团队每个人的潜能和智慧，发扬民主精神，当团队成员遇到不同意见时，进行举手表决。

我们在传统项目场景下强调，在范围和进度基本不变的前提下，成本最优，而项目产生缺陷就是成本浪费。

在敏捷场景下，不为用户创造价值的活动才是浪费。埃里克·莱斯( Eric Ries )在其著作《精益创业》( The Lean Startup) 中提到，如果要做一个创新型产品，客户是谁、客户的需求都是未知的，也是快速变化的，那么在这样不确定的环境中，耗费在产品特性、工作优先级、技术路线上的争论都是实实在在的浪费。

为什么不缩短整个反馈周期，早一点听到用户的声音呢? 精益创业的核心思想就是当有了一个产品概念时，不要急着投人大量资源去开发产品，而是要先开发一个最小可行产品 (Minimum Viable Product，MVP )，将 MVP 带到早期客户中去验证概念的价值，然后依据早期客户的反馈来调整产品概念。MVP 不一定是真实的产品，而是以最少的精力投人和最快的速度完成一次“开发一测量一认知”反馈循环的试验品。在验证产品概念过程中，团队要经历多次验证循环。

例如，这些年，知识付费大热，得到、混沌大学、樊登读书会等平台不断刷新着知识付费的新高度，一门在线课程有几十万名付费用户，几千万元的单品收人已不罕见。这让很多人眼热心跳，也想在知识付费的赛道上搏一回。那么，你应该先去策划一门 100 节的课程，然后组建团队录制、剪辑、包装、开发 App，再投入广告推广吗?那得花费多少钱，投人多少时间呢? 就算你做出来，有人愿意付费听你的课吗? 这些都是未知数!有多少创业公司就这样耗光了资金，产品还没做出来壮志未酬就身先死了。

那么应该怎么做呢?你可以先准备一段 10 分钟的课程内容，不需要精雕细琢只要能体现你的课程特色就行了，然后在朋友圈里召集感兴趣的人进微信群，约定好时间就可以在群里开讲。接下来，你要做好心理准备，迎接暴风骤雨般的吐槽!根据大家的反馈，你要不断修正你的产品定位，不断试错，发现和留下对的内容,直到有很多人愿意付费听你的课。这样做能花多少钱，能有多大风险呢? 其实创业并不是遥不可及的，不是吗?

MVP 的原则就是用最少的资源、最短的时间做试验，获得早期用户的反馈，验证产品的价值。

常用的 MVP 方法如下：

视频：在产品被开发出来之前，公司可以制作一个介绍产品的视频。著名的云存能司多宝箱 (Dropbox)通过一段介绍产品核心功能的视频，使注册用户一夜之间5 000 人暴增到 75 000 人。其实，多宝箱在还没开始做这款产品时，就已经验评这些功能是用户喜欢的。

仿真：在产品被开发出来之前，企业通过人工来模拟产品的功能。例如，美国网上大的鞋店 Zappos 的创始人尼克想知道人们到底有没有在网上买鞋的需求，他并没开发电商平台，而是到各商场专柜拍鞋子的照片，并把它们放到网上。如果有人单，他就跑去店里买来寄给用户。他没有库存压力，也没有开发成本。在他看来商业逻辑的成立远比系统上线重要得多！

众筹：企业在开发产品之前先发起众筹，根据众筹的情况判断人们对产品的态度。我国著名的空气净化器品牌“三个爸爸”就是在京东上发起众筹的，不但很快筹到了足够的开发经费，还找到了产品的早期用户。

原型：开发产品不是把未经用户验证的需求交给团队，而是先向用户演示产品原型(Prototype )。这些原型可能是手画的、泥捏的、纸糊的，虽然它是假的，但是很直观、很生动，远比一大堆模棱两可的描述文字更有价值。

预售：在产品开发之前先推出预售页面，如果预售数量达到约定标准，企业就可以开始开发产品了;如果预售数量没达到约定标准，那么企业就取消活动，如数退还货款通过预售，公司不仅很容易验证产品是否真的受欢迎，而且不会产生什么成本。

访谈：咨询顾问通过与客户组织中各类人员的接触谈话，能够获取客户组织的重要的主观问题，被访谈的人也感到他们在为项目作贡献。访谈过程是一个耗费时间的过程，需要巧妙周全的构建，访谈之前要做好充分的准备，包括材料准备、思想准备等 。

拥抱韧性

当项目遭遇风险或受到干扰时，整个项目团队还能保持:

• 维持状态的能力
• 迅速恢复的能力
• 更好地应对未来不确定性的能力

这三种能力通俗一点解释就是项目皮实耐造，经折腾！

4.根据环境进行裁剪

做项目必须要充分考虑环境对项目的影响，即所谓审时度势、因地制宜。首先要根据环境设定项目目标，需要考虑的环境因素包括:

• 组织的治理模式
• 必须遵守的流程制度
• 可以选择的项目开发方法
• 可以参考的模板和资料
• 项目的生命周期

除了考虑环境因素之外，在设定目标时还需要考虑：

• 适应环境的独特目标
• 利益干系人和相关复杂性
• 统一和个性的结合
• 团队成员参与裁剪决策
• 裁剪是持续的、迭代的
• 不断评估目标有效性

根据环境设定目标，力争实现：

• 价值最大化
• 更高效地利用资源
• 提高创新、效率和生产力
• 有效整合多学科
• 经验教训分享
• 改进组织方法论

5.优化风险应对

风险来源于不确定性，包括负面的威胁和正面的机会。风险有两个属性: 概率和影响。风险管理是通过识别、分析和应对风险来提高正面机会的概率和影响，路低负面威胁的概率和影响。

风险敞口 ( Risk Exposure )

风险敞口是未加保护的风险，也称“风险暴露”，是指对风险未采取任何防范措施而可能导致出现损失的部分。

例如，即便项目是按客户要求交付的，仍然可能有 10% 的项目尾款因为各种原因收不回来，那么对于这个项目而言，就存在着 10% 的风险敞口。

已知风险的风险敞口是从零到该风险产生的最大损失之间的部分，未知风险的风险敞口是从零到无穷大。

单个项目风险与整体项目风险

风险管理专家大卫·希尔森 (David Hillson) 博士认为，只关注单个项目风险而忽略整体项目风险，只关注项目局部风险，而忽略项目全局风险，只关注项目短期风险，而忽略项目长期风险;只关注项目战术风险，而忽略项目战略风险，这些都是风险近视症的表现。

例如，一个互联网金融 P2P 项目，代码 Bug、系统安全漏洞、服务器宕机、项目团队骨干离职都是单个项目风险，而国家出台政策限制 P2P 业务就是整体项目风险。

非事件类风险

非事件类风险包括变异性风险和模糊性风险。

变异性风险

如果项目所依赖的关键条件或制约因素出现异常改变，就会导致变异性风险例如我们常说的“黑天鹅事件”“草根逆袭”等一切不按常理出牌的局面。

我们可以通过模拟技术，如蒙特卡洛技术进行风险定量分析，来评估变异性风险的概率和影响。

模糊性风险

模糊性风险意味着人们不确定未来可能会发生什么。知识不足可能影响团队达成项目目标的能力，例如，无法预测技术发展的方向和速度、政策法规的未来变化、快速变化的用户需求等。团队可采取迭代开发、增量开发及适应型(敏捷型)开发模式，提高对此类风险的适应能力。

干系人对风险的态度

干系人表现出来的对风险的态度通常与风险偏好和风险承受力有关。风险偏好是指为了预期的回报，干系人愿意承受不确定性的程度，属于主观意愿，风险承受力是指干系人能承受的风险程度或数量，属于客观能力。

我们通常用风险临界值来表示干系人对风险的态度:如果风险低于临界值，干系人会接受风险，如果风险高于临界值，干系人会拒绝风险。

整合式风险管理

整合式风险管理是指在项目、项目集、项目组合及项目所在组织进行多层次的风险统筹管理。有些风险管理应该授权给项目管理者，有些风险超出了项目管理的能力范围或影响多个项目，应上报给相应的高级管理层。企业应将风险管理贯至项目管理的各个层次，形成一个有机、动态的风险管理系统。

主动管理风险

当面临风险时，手忙脚乱往往于事无补，追悔莫及。团队只有在做项目计划时提前识别风险，评估风险的概率和影响，并合理分工，责任到人，提前规划风险应对策略和方法，才能临危不乱、淡定从容。这种主动管理风险的意识和习惯会帮助团队更好地适应环境，完成项目。

团队在主动管理风险时，建议做到以下几点:

• 提前启动并持续进行风险识别
• 评估干系人的风险闯值，确定管理策略
• 进行风险定性分析，确定优先级
• 进行风险定量分析，设立止损机制和储备
• 研究触发机理，设置预警机制
• 平衡威胁和机遇，积极配置风险组合
• 规划风险应对方法，控制风险
• 跟踪风险，动态调整应对方案
• 评估应对措施的有效性，并防范次生风险

识别风险

识别风险是判断哪些风险可能影响项目并记录其特征的过程。本过程的主要作用是对已有风险进行文档化，并为项目团队预测未来事件积累知识和技能。识别风险的工具和技术如下。

头脑风暴法 ( Brainstorming )

参与风险识别的小组成员在正常、融洽和不受任何限制的气氛中以会议的形式进行讨论、座谈，小组成员在会上可以打破常规，积极思考，畅所欲言，充分发表自己的看法。小组成员互相启发，而且不轻易评价，甚至鼓励看似愚蠢的想法，以获得尽可能多的想法。

德尔菲法 ( Delphi Method )

德尔菲法又称专家规定程序调查法。该方法主要是由调查者拟定调查表，按照既定程序，以函件的方式分别向专家组成员进行征询，而专家组成员又以匿名的方式(函件) 提交意见。经过几次反复征询和反馈，专家组成员的意见逐步趋于集中，最后获得具有很高准确率的集体判断结果。

德尔菲法的特点是专家们始终不见面，也不知道其他专家是谁，从而最大限度地避免了由于个别专家的偏见而误导其他专家的判断的情况发生。

根本原因分析法 ( Root Cause Analysis )

根本原因分析是一种结构化的问题处理法，用来逐步找出问题的根本原因并加以解决，而不是仅仅关注问题的表征。根本原因分析是一个系统化的问题处理过程，包括确定和分析问题的原因、找出问题解决办法并制定问题预防措施。

核对单分析法 ( Check List Analysis )

为了查找项目中人员、设备设施、物料、工件、操作、管理和组织措施中的风险，事先把检查对象加以分解，将大系统分割成若干个小的子系统，以提问或打分的形式对检查项目列表中的各项进行逐一检查，避免遗漏。这种表称为核对单，也叫检查表。用核对单进行项目风险盘点的方法叫核对单分析。

假设分析法

每个项目及其计划都是基于一套假设而构建的。假设分析是检验假设条件在项目!的有效性，并识别因其中假设的不准确、不稳定、不一致或不完整而导致的项目风险假设分析的步骤如下。

• 提出一个假设，这个假设可能会产生我们担心的结果
• 验证这个假设，对其进行确认或排除
• 如果排除，再提出第二个设;如果确认，提出更具体的下一层级的假
• 通过验证，逐步缩窄范围，直到找出问题可能会产生的真正原因

如图展示了“直播网课卡顿”问题的假设分析过程。该问题的分析一共有种假设:震设一，教师端的问题，大部分同学反馈视频流畅，所以此项排除:设二，学生端的问题，同一个学生看到的其他视频是流畅的，所以此项排除;售三，服务器端的问题。这三种假设中，前两种假设已经被排除了，那么问题只能出自第三种假设了。

第三种假设包含三个子假设: 子假设一，服务器软件问题，该软件已经过多测试，所以此项排除;子假设二，服务器硬件问题，该硬件已经是顶配，所以排除;子假设三，带宽负荷问题，个别地区负载不均衡，这应该就是直播网课卡问题的罪魁祸首。

鱼骨图法

鱼骨图又称“因果图”，是一种发现问题“根本原因”的方法。它看上去有些像鱼骨，其特点是简单、实用、深人、直观。项目的风险、问题或缺陷(即后果)被标在“鱼头”处。鱼刺上，按出现机会多寡列出问题产生的可能的原因，以有助于说明各个原因之间是如何相互影响的。

系统或过程流程图法 ( System Flowchart )

该流程图是描绘系统物理模型的传统工具。它的基本思想是用图形符号以黑盒子形式描绘系统里面的每个部件(如程序、文件、数据库、表格、人工过程等 ).表达信息在各个部件之间流动的情况，如图所示。

专家判断法

拥有类似项目或业务领域经验的专家可以直接识别风险。在借助专家的判断时，我们需要注意专家的偏见，同时，也要重视专家的直觉。

假设条件和制约因素分析法

每个项目及其项目管理计划的构思和开发都基于一系列的假设条件(不确的 )，并受一系列制约因素(确定的)的限制。这些设条件和制约因素往往都纳人范围基准和项目估算。通过开展假设条件和制约因素分析，可以判断假设条件和制约因素的有效性，确定其中哪些会引发项目风险，从而可以从不准确、不稳定、不一致或不完整的假设条件中识别出威胁，通过清除影响项目或过程执行的制约因素来创造机会。例如，适当放宽制约因素，如果在 6个人的基础上再增加2个人，那么完不成项目的风险就会降低;如果适当收紧假设条件，比如客户不会更改需求(实践证明这是不可能的 )，那么项目的风险就会暴露。

SWOT 分析法

SWOT 分析法又称态势分析法，20 世纪 80 年代初，旧金山学的管理学教授海因茨·韦里克 (Heinz Weihrich) 提出了 SWOT 分析法。

SW(分析法是一种能够较客观而准确地分析和研究一个项目现实情况的方法。其中代表优势 (Strengths)，w 代表劣势 ( Weaknesses )，它们属于内部因素: O 代表会(Opportunities )，T 代表威胁 ( Threats )，它们属于外部因素。

单个项目风险与整体项目风险

提示清单是关于可能引发单个项目风险及可作为整体项目风险来源的风险类别的预设清单。在采用风险识别技术时，提示清单可用于协助项目团队形成想法。我们可以用风险分解结构(RBS ) 底层的风险类别作为提示清单来识别单个项目风险如下图所示。

战略框架

某些常见的战略框架更适用于识别整体项目风险的来源，如“PESTLE”(政治经济、社会、技术、法律、环境)、“TECOP”(技术、环境、商业、运营、政治)或“VUCA”(易变性、不确定性、复杂性、模糊性 )。

层级图( 气泡图 )

如图所示，在气泡图中，我们把每个风险都绘制成一个气泡，并用X轴的值、Y轴的值和气泡大小来表示风险的三个参数。其中，X 轴代表可监测性，Y轴代表邻近性，影响值则以气泡大小表示。

我们还可以选择的指标有紧迫性、潜伏期、可管理性、可控性、连通性、战影响力及密切度等。

第三节：任务

1.规划和管理项目的合规性

规划和管理项目的合规性氛围如下四个步骤。

• 确认合规要求：包括安全健康、环境保护、质量标准、行业监管等。
• 分析不合规的后果：区分合规类别，判断潜在威胁。
• 确定必要的方法和行动：提前制定保障措施和规章制度。
• 衡量合规的程度：通过审计与回顾不断总结，持续改进。

项目管理计划与项目文件

答案肯定是否定的，项目管理计划和项目计划不能混淆。广义上的“项目计划”包括项目管理计划和项目文件，是统称：狭义上的“项目计划”特指项目文件上的“实施计划”。

如表所示，项目管理计划中有“进度管理计划”，项目文件中有“项目进度计划”。我们不难发现，成本、质量等也有类似的对应关系。

需要注意的是，在 PMP考题中，“项目管理计划”和“项目计划”这两个名称的使用有时不够严谨，需要你认真分析题意，根据上下文来判断题目所指的到底是“项目管理计划”还是“项目计划”。

项目管理计划

• 规则程序

在项目管理计划中，项目成本管理计划并不是指项目预算，没有“项目需要花费多少钱”这样的信息，而是规定了编制预算的单位(如美元、欧元、人民币)编制预算的精度(比如，精确到万元还是元 )、编制预算的方法和依据( 比如，参照哪个会计准则，按照公司哪些相关规定执行，遵照国家和行业的哪此规范 )。

同样，进度管理计划中也没有项目的工期。进度管理计划定义的是进度的单位(天、周)、进度计划编制的方法 (关键路径法、关键链法 )、进度计划编制的工具(横道图、网络图 )。

由此可见，“x x 管理计划”都属于规则程序，定义了计划的单位、规则、流程、方法和工具等，并不包含项目的具体信息和数据。

• 项目基准

如何评价项目绩效的好与坏? 例如，如何界定进度延迟? 如何界定成本超支?这个衡量的标准就是项目基准。项目经理带领团队评估项目的工期、成本和工作内容，并经过项目发起人和组织高层评审与沟通后确认，从而形成范围基准、进度基准和成本基准。它们是衡量项目管理绩效的三大基准。

基准确定之后还能不能修改?

答案当然是能! 但是基准变更相对于文件更新要严肃得多。我们做计划时通常会留出余地，我们把这些余地叫作储备。例如，我们预估成本是 45 万元，将预算定为 50 万元，那么多出的 5万元就是成本储备。我们预估 80 天可以完成项目，但报的工期是90 天，多出的 10 天就是进度储备。所以，当我们遇到一些需求变更或风险时，这些储备可以帮助我们抵挡一阵，起到缓冲的作用，不至于一有风吹草动我们就得变更基准。

如果变更影响基准，那就不得不修改基准。例如，客户要增加的新需求实在太“大”了，如果要满足这个需求，剩下的时间完全不够，需要多花 30 天的时间，那么这种情况就需要有新的进度基准。但凡要更新基准，都必须经过项目变更控制委员会(CCB) 的批准。而如果变更并不影响基准，就不必经过 CCB，项目经理就可以决策，这些变更需要更新的是项目文件中的实施计划，如图所示。

为什么项目基准里没有“质量基准”?难道质量不重要吗?

当然不是，质量不是不重要，而是太重要了! 质量标准已经从项目层面上升到企业标准、行业标准甚至国家标准。不单是某一个项目，所有这个行业的项目质量都得按统一的标准进行控制和验收。

项目文件

项目的具体信息和数据在哪里呢？在项目文件中。项目文件分为实施计划和资料文件两类。在实施计划中描述项目工期的是进度计划，描述项目成本的是成本估算。资料文件包括问题日志、变更日志、沟通记录等各种日志和记录文件。

项目管理计划和项目文件的作用不同，项目管理计划定义的是规则和程序，不能朝令夕改;而项目文件是具体的实施计划和资料文件，包含了大量的项目细节信息和数据。因为项目的不确定性决定了需求、范围、进度、成本等都会不断发生变化，所以这些文件需要经常更新与维护。

如下表所示，项目管理计划和项目文件不仅修改频率不同，而且修改流程也不同。项目管理计划中的基准更新必须走整体变更控制程序，而且必须由 CCB准;而项目文件中实施计划的更新虽然也需要走整体变更控制程序，但只需要项经理批准。对于项目文件中的资料文件(如问题日志、沟通记录)，项目团队成员随时记录，不需要走变更控制程序。

里程碑计划与里程碑清单

里程碑是项目中的重要时点或事件。里程碑与常规的进度活动类似，有相同的结构和属性，但是里程碑持续的时间几乎为零，因为里程碑代表的是一个标志性的时间点，比如，在软件项目中，签约、验收、发布等就属于里程碑事件。

里程碑计划是指把里程碑事件依次标记在时间轴上，用来控制项目的整体进度，如图所示。

里程碑计划的作用

• 计划：分解为阶段性目标。
• 控制：强制约束，控制各阶段目标实现。
• 沟通：便于与管理层、干系人进行良好的沟通。
• 责任：明确规定了项目各方的责任和义务。
• 报告：简明、生动、通俗、实用。

里程碑清单是指列出项目的所有里程碑，并指明每个里程碑是强制性的(如合同要求的)还是选择性的(如根据过往经验确定的)。

项目启动会议与项目开工会议

项目启动会议 ( Initiating Meeting )

在制定项目章程过程中，由项目发起人召集主要干系人参加项目启动会议，主要完成以下任务:

• 发布项目章程
• 任命项目经理
• 宣布项目正式启动

项目开工会议( Kick-off Meeting )

当项目计划编制完成时，由项目经理召集主要干系人参加项目开工会议，主要完成以下任务:

• 宣布项目计划编制完成
• 确认资源已按计划到位
• 宣布项目进入执行阶段

如果项目分为多个阶段，那么每个阶段在开始执行前都应召开阶段开工会议。项目开工会议来自足球比赛中的中圈开球，当比赛开始时或取得进球时，裁一声哨响，由发球方把球踢出中圈，标志着“开踢!” 所以项目开工会议也常常称为“项目开踢会议”。

项目启动会议与项目开工会议的区别如下表所示。需要注意的是，在 PMP考试中，有时“Kick-Of Meeting”会被错误地翻译成“项目启动会议”。所以，当你看到“项目启动会议”时，务必对照一下英文。

2.评估并交付项目的利益和价值

识别项目的利益和价值

评估并交付项目的利益和价值分为以下三个步骤:

• 识别项目的利益和价值
• 制订项目效益管理计划
• 跟踪与评价项目价值

识别项目的利益和价值，应该从经济效益、社会效益和环境效益三个方面入手，这三方面又分别包括有形的效益和无形的效益。

比如，视频会议的广泛应用减少了大量的差旅成本和花在路上的时间，同时减少了出行产生的排放。视频会议的便利性提升了人们的工作体验，不过，面对面交流机会的减少，改变了人们的社交方式，对社会效益可能产生深远影响。

同时，视频会议的沟通效率和沟通效果与线下会议存在差距，沟通成本是上升还是下降也需要评估。

项目效益管理计划

为了实现项目预期的效益，项目发起人应该事先编制项目效益管理计划，其包含:

• 项目效益目标与组织战略的一致性
• 效益管理的责任
• 实现效益的时间计划
• 效益测量指标与测量方法
• 风险与应对

确定了项目经理之后，项目效益管理计划应由项目经理负责维护，根据项目实际进展和环境因素的变化而不断更新和修订，不仅要始终保证效益目标的合理性而且要保证效益目标按计划实现。

3.评估应对外部业务环境变化的影响

评估并应对外部业务环境变化对范围的影响的步骤如下：

• 调查环境的变化

比如开发动力电池项目，就需要时刻关注新技术、新材料的涌现，新能源车相关政策的变化，车企的发展战略和竞争态势等，这些都直接影响项目的绩效，甚至决定着项目的成败。

• 评估影响和优先级

项目环境的变化来自方方面面，而且随时随地发生，项目团队不可能拿出相同的精力去应对这些变化，否则就是风声鹤唳草木皆兵，应该事先对这些可能出现的变化进行分析，评估它们对项目影响的大小和发生的概率，以此来排除应对的优先级。

• 提出变更建议

对于必须面对的变化，项目团队应该拿出应对方案，并正式提出变更建议，获得批准后对项目方案进行及时修正。

• 持续审视和评估影响

即便团队对项目环境变化做出了评估和应对，也不能忽略环境变化是动态的，因此应该持续审视和评估变化对项目的影响，动态调整变化的优先级和应对方。

为组织变革提供支持

组织为了提升效率和改进管理，会根据战略需要不断寻求变革，变革包括治模式、组织架构、流程制度、组织文化等方面。

变革必然会影响即将开展及正在进行的项目，项目团队首先要动态调整项目理模式和项目管理计划，使其符合组织变革的要求，同时积极反馈实践中出现的题，便于组织及时验证变革的效果和调整优化变革方案。

第四节：绩效

1.项目后评价

项目评价模型

为了对项目绩效进行评价，很多组织都开发了项目评价模型。其中比较有代表性的例子是来自 IPMA 的“卓越项目管理模型”。

如图所示，卓越项目管理模型中包含 3 个领域、9 个子领域、20 个评准和 107 个要素标准，还包括大量的案例、过程记录和证明文件。

如图所示，卓越项目管理模型中的 3 个领域和9个子领域的内容包含了人过程、成果的主要评价指标。

项目后评价

项目后评价是指针对已经完成的项目或已经完成规划的项目，就项目的目的执行过程、效益、作用和影响所进行的系统、客观的分析。

项目后评价通过对项目的实施过程、结果及其影响进行调查研究和全面系统的回顾，与项目决策时确定的目标以及技术、经济、环境、社会指标进行对比，确定项目预期的目标是否达到，项目或者项目规划是否合理有效，项目的主要效益指标是否实现;通过分析评价找出成败原因，总结经验教训;并通过及时、有效的信息反馈，为提高未来新项目的决策水平和管理能力提供基础;项目后评价也可为项目运营中出现的问题提供改进建议，从而实现提高投资效益的目的。

项目后评价包含以下内容：

• 目标评价：项目目标的实现程度
• 实施过程评价：过程的合理性和规范性
• 效益评价：财务指标和经济性
• 影响评价：经济、社会和环境影响
• 持续性评价：可持续性和可重复性

2.面向环境的价值交付

项目所处的环境包括组织环境、行业环境、社会环境和自然环境。项目会受到环境的影响，同时项目也在影响着环境。

因此，团队需要识别和评估项目与环境的相互影响，通过项目计划和监控扩大积极影响，同时减少消极影响。

对于环境影响评价，人们主要关注项目对自然环境和社会环境的影响，比如新建化工厂项目，必须通过环境影响评价，保证对水、大气、土壤、固废、噪声光、辐射、地质、生态等方面的影响符合国家法律法规的要求。

环境影响评价包括判断功能、预测功能、选择功能和导向功能。

3.项目适应性和韧性

项目适应性是指项目团队对不断变化的环境做出反应的能力。当然，这里的环境是广义的，包括组织环境、行业环境、市场环境、经济环境、自然环境等。在项目管理过程中，应该持续评估项目与环境的适应性，发现偏差及时调整，避免项目绩效指标与环境因素脱节，造成无法挽回的被动局面。

提升项目韧性是应对外部环境变化的必然选择。只有让项目团队的抗干扰能力、自我修复能力和自我学习能力持续提升，才能使组织在纷繁复杂的环境中，把握瞬息万变的机遇，规避险象环生的场景，最终达成项目目标。

4.组织过程资产

合同收尾和行政收尾

根据不同的目的，项目收尾分为合同收尾和行政收尾。合同收尾也称采购收尾，行政收尾也称管理收尾，两者的区别是重要的考点，如表所示。

合同收尾是指对外履行完合同约定的责任和义务，包括与分包商、供应商完成交付验收，与客户完成交付验收，向客户收款，向分包商、供应商付款。

行政收尾需要对内归档并上报项目文档资料、经验教训，包含所有版本的项目计划、项目文件、经验教训和获得的知识。

行政收尾中归档并上报的项目资料由项目管理办公室(PMO) 进行整理、甄别、归纳、提炼。其中，对于其他项目有参考价值和共享意义的，PMO 通过组织学习、分享、观摩、交流，让组织过程资产发挥价值。