PMP®考能提升

外框

例题

答题基本原则

项目经理先想办法解决，一般不直接上报发起人、管理成，或请求职能经理解决

主动想办法，不被动等待

不为自己辩解、不追纠别人的责任

责任

不直接开除人、公开批评人

不直接向相关方的领导告状

向员工提供培训

尊重

公开公正，信息透明

公正

如实报告项目信息，不隐瞒

诚实

最符合“责任、尊重、公正、诚实”

PMI的职业道德原则

现在怎么做

做好计划、流程

若要避免，事先怎么做

经验教训登记册、组织过程资产

确保未来不再发生

看清问题的时间点和阶段

没有具体的项目管理计划、项目基准

可以和发起人直接沟通

项目应该有商业论证和效益分析

项目章程一定要正式获批

商业论证不可行，可以取消项目

在后期项目执行过程中，范围、时间、成本发生变更
时，不用调整项目章程，只调整相应的项目管理计划

启动阶段

一般不“联系发起人”、“联系高级管理层”

基准还没建立，不用走变更，可以直接调计划

范围说明书已形成，正在分解WBS，改范围要走变更

项目管理计划需获得相关方批准，批准后调整要走变更

开工大会( kick-off ) ，获得支持和承诺

阶段结束

规划阶段

子主题

项目管理计划和项目文件

有实体内容

沟通管理计划、相关方参与计划

需求管理计划vs需求文件、需求跟踪矩阵

成本管理计划vs成本基准

进度管理计划vs进度基准

资源管理计划vs职责分配矩阵、资源日历等

风险管理计划vs 风险登记册

采购管理计划vs采购协议
(具体问题不改变程序性计划)

质量标准+管理质量的方法

质量管理计划

程序性计划和实体性计划

严格按照整体变更控制流程

遇到问题，先努力维护现有基准

仍无法解决的，提变更，调整进度基准、成本基准

考虑范围、进度、成本的平衡

执行阶段

可交付成果的验收和移交

处理合同中的财务和法律关系

合同收尾

收集整理项目资料、开展内部总结、评估团队项目绩效、
编制并分发项目最终报告与存档项目信息

行政收尾

解散团队释放资源

收尾的一般流程

合同收尾完成，代表与客户之间的项目关系结束。此时，如有变更或
其他问题，项目团队只负责记录成经验，并给出处理建议，如开启一
个新项目。后续维护由质保或运营团队接入。

财务中断、战略不再符合等原因导致发起人决定中止项目，下一步不
是去“尝试解决财务问题”或试图影响发起人决定或“马上解散团队”。
而是开展收尾工作。

收尾的注意事项

收尾阶段

获得批准的项目管理计划。没有获批，就无需走变更流程

变更的基础

纳入变更管理范畴的，无论题干如何描述，都需遵循变更流程

实在来不及走标准变更控制流程的，需补走流程

直接实施

直接调整计划/基准

直接拒绝

错误选项

变更的原则

变更的基础和原则

提出变更请求→评估和审批变更→更新受影响的项目管理计划及文件→通知相关方

优选遵循变更控制流程

问怎么做

优选具体步骤，提出变更请求或评估影响

问首先/下一步那怎么做

当答案中又有遵循变更流程，又有提出变更请求/评估影响时

变更的流程

（CCB）已批准的变更，必须确保落实，不能拒绝

变更的实施

首选应令其停止，防止私自变更继续扩大。然后分析影响，补走变更流程。

团队成员私自变更

如果变更审批通过，那么就纳入范围基准。
如果拒绝，撤销所做更改。

私自变更的处理

敏捷项目分各个迭代期实施，每个迭代期（一般1-3周)开展前召开迭代规划会议，
从待办列表（拟实现的需求）中选取本迭代期的工作内容。非必要的变更一般纳
入下一个迭代期实施。

本迭代期的变更，产品经理和团队确认后即可实施，但也需要记录。

敏捷项目的变更

需求源——需求——可交付成果（范围）——质量

质量是符不符合既定的标准，主要用于内部检查；而范围确认是客户接不接受可交付成果。
客户最终接不接受可交付成果，以主要取决于是否满足了客户的需求

项目执行过程中，对范围进行变更，要关注是否仍满足最开始的需求

需求与范围

WBS是将工作进行分解

RACI是在WBS的基础上，把分解后的工作与职责分配挂钩

分工明确是执行的基础，当团队人员变更或职责不清，审查或更新RACI矩阵

WBS与RACI

先核实

团队成员声称没有时间

在资源日历中找

资源可用性

矩阵型组织结构（无特殊说明默认为弱矩阵）中，获取资源先与职能经理协商，不直接上报

与职能经理协商需要使用人际关系技能

资源技能不足先考虑培训

培训由项目经理负责，而不是职能经理负责

组织内部资源短缺，可以从外部获取

PMI不提倡直接“加班”、“提高团队效率”、“分配给剩余成员”，
加班会导致成本增加，需要遵循变更流程，经过批准