9.3 定义范围（define scope）
针对需求明确要做哪些事不做哪些事，描述产品、服务、成果的边界和验收标准。
定义范围需要从需求文件中选取最终的项目需求，需要多次反复开展定义范围的过程。

输入：
项目章程（有成功标准和验收标准，高层级描述、产品特征等）、需求文件、项目管理计划、项目文件（需求文件、假设日志）、环境

工具与技术：
产品分析：将高层级产品描述转变为有型的可交付成果，包括产品分解、系统分析、需求分析、系统工程、价值工程、价值分析等。
备选方案分析：制定尽可能多的备选方案。
决策：多标准决策分析
人际关系与团队技能：引导，协调不同专业知识的干系人，达成跨职能的共识。

项目章程英文（project charter）
输出：范围说明书（project scope statement），是对项目范围、主要可交付成果、假设条件和制约因素的描述，作用：记录了整个范围包括项目和产品范围，描述了项目可交付成果，还代表干系人之间就项目范围所达成的共识。为了便于干系人期望，可明确指出哪些工作不属于项目范围内。（背诵）

9.4 创建WBS
项目范围说明书，文件内容不直观，但图表达更为直观。将文字转化为WBS图表。
WBS（work breakdown structure），工作分解结构，每一个组件就是一个可交付成果，最底层的80小时可完成的可交付成果，称为 工作包。
WBS定义：把可交付成果分解为工作包，组织并定义了项目总范围。包括工作包（80小时内完成的可交付成果）、规划包（工作内容已知，但详细进度活动未知，是低于控制账户高于工作包的结构组件，体现滚动式规划）和控制账户（针对每个wbs组件，详细描述可交付成果、活动和进度信息的文件，有助于评价变更的影响）。

工具与技术：重点，曾考过10次，背诵。
分解：把项目范围和可交付成果逐步划分为更小，更便于管理的组成部分的技术。
1，识别和分析可交付成果，依据是项目范围说明书；2，确定WBS的结构和编排方法，可参考范围管理计划，里边都是指南；3，自上而下逐层分解；4，为WBS组件定制和分配标识编码。5，核实可交付成果分解的程度是否恰当。
工作包：WBS最底层组件，对其成本和持续时间进行估算和管理。
创建WBS，就是将整个项目工作分解为工作包。

WBS结构三种形式
1，每一层都是可交付成果
2，把项目生命周期的各个阶段放到第二层，其他层都是可交付成果。
3，纳入由项目团队以外的组织开发的各种低层次组件（比如外包），做为外包工资的一部分，卖方需要定制相应的合同WBS。

8个注意事项：
1，WBS是面对可交付成果；
2，必须符合项目范围（100%原则），所有下一级元素之和必须100代表上一级元素；
3，wbs底层要支持计划和控制——支持项目管理计划、进度和预算的控制；
4，元素必须只有1个人负责（独立责任原则）；
5，WBS控制在4~6层，如果超过6层需要继续分解；
6，wbs应包括项目管理工作，也要包括分包出去的工作；
7，wbs编制需要所有（主要）干系人参与；
8，wbs并非一成不变。渐进明细的。

控制账户
是一个管理控制点，人为设定的，可以与组织的财务程序连接，在该控制点上，把范围、预算和实际成本、进度加以整合，与挣值做比较，以测量绩效。
每个控制账户可能包含一个或者多个工作包，但一个工作包只属于一个控制账户。
控制账号设置在较高层次或者较低层次上，就表明项目管理团队想要对项目实施“粗管” 还是 “细管”。

输出：
范围基准
经过批准的项目范围说明书、WBS、WBS词典，只有通过正式的变更程序才能进行变更，它被用作比较的基础。
记录了整个范围，包括项目和产品范围。

9.6，控制范围，监控过程组
控制范围（control scope）：监督项目和产品的范围状态，管理范围基准变更的过程。
作用：在项目期间保持对范围基准的维护，确保所有变更请求、纠正措施、预防措施都通过实施整体变更控制过程进行处理。

输入：
项目管理计划、需求文件、工作绩效数据（执行过程中收集的第一手工作数据表数据，接受的变更的数量，核实确认和完成的可交付成果数量 ）、组织过程资产
工具与技术：
数据分析：
偏差分析，将基准和实际结果做比较，确定偏差是否处理临界值区间内或是否有必要纠正或预防措施。
趋势分析：审查项目绩效随着时间的变化情况，判断绩效是否正在改善或恶化。
输出：工作绩效信息、变更请求、项目管理计划更新、项目文件更新。

9.5 确认范围，监控过程组
确认范围（validate scope）客户或者发起人正式验收已完成项目的可交付成果的过程。
作用：使验收具有客观性，通过确认每个可交付成果，来提高最终产品、服务或成果验收的可能性。
确认范围需要检查的问题：
1，可交付成果是否是确定、可确认的。
2，每个可交付成果是否有明确的里程碑，是否有明确可辨别的事件。
3，是否有明确的质量标准。
4，审核和承诺是否有清晰的表达。
5，项目范围是否覆盖了需要完成的产品或服务所进行的所有活动，有没有遗漏或者错误。
6，项目范围的风险是否太高，管理层能发能够降低可预见风险发生时对项目的冲击。

干系人的关注点（重点）：
1，管理层，关注范围对进度、资金和资源的影响，是否超出了组织承受范围，投入产出是否合理。
2，客户，关心产品范围，项目的可交付成果是否能够完成产品或服务。
3，项目管理人员，关注可交付成果是否能够和必须完成，时间、资金和资源子否足够，主要的潜在风险等。
4，团队成员，关心自己参与和负责的元素，检查工作时间是否足够。
另外，客户和团队成员往往有在当前版本中加入所有功能和特征的意愿，是一种潜在风险。

输入：
核实的可交付成果：是验收的对象，已完成冰杯控制质量过程检查为正确的可交付成果。来自于质量管理中 控制质量的子过程。
项目管理计划：包括 范围管理计划（定义了如何验收可交付成果）和需求管理计划（描述了如何确认项目需求），以及范围基准（用基准和实际结果做比较）。
项目文件：需求文件（将需求和实际结果比较）和需求跟踪矩阵（含有和需求相关的信息，包括如何确认需求）。相当于反向验证。

技术与工具：
检查（审查、产品审查、巡检），查的是结果。开展测量、审查与确认等，判断工作和可交付成果是否符合需求和产品的验收标准。验收测试是一种典型的确认范围的技术。检查查结果，审计审过程。

输出：
验收通过，则输出：验收了的可交付成果：符合验收标准的可交付成果由客户或者发起人签字批准。
从客户或发起人获得正式文件，证明干系人对交付成果的正式验收。

验收不通过：
输出：变更请求，按照步骤：1，记录原因；2、提交变更申请流程；3、缺陷补救。

立项四个阶段：立项申请（提交项目建议书）、立项初步可行性研究、立项详细可行性研究、决策（甲方自己做或者招标乙方做，涉及十大知识领域）。

49510图，五大过程组，十大知识领域，49个子过程

了解项目管理知识体系叙述的结构：子过程、ITTO、过程组、知识领域。
子过程：为创建预定的产品、服务或者成果而执行的一些列相关的行为和活动。既属于某一过程组（启动、规划、执行、监控、收尾）又属于某一知识领域（范围、成本、进度、风险等…）
I：input，T：tool，T：technology，O：output

项目整合管理：包括识别、定义、组合、统一和协调项目管理过程组的各个过程和项目管理活动。整合管理兼具统一、合并、沟通和建立联系的性质，贯穿项目始终。
目标（背诵）：资源分配、平衡竞争性需求、研究各种备选方法、裁减过程以实现项目目标、管理各知识领域之间的依赖关系。
发生整合的三个层面：过程层面、认知层面、背景层面。

项目整合管理要求整合所有其他知识领域的成果。
发展的趋势包括：使用信息化工具、使用可视化管理工具、项目知识管理、项目经理在项目外的职责、混合型方法（敏捷或者迭代、商业分析技术、组织变革管理方法等混合使用）。
迭代和敏捷方法中：
团队成员：以领域专家的身份参与整合管理，自行决定并控制具体产品的规划和交付；
项目经理：授权给团队，重点关注营造一个合作型的决策氛围，并确保团队有能力应对变更。
如果团队成员有广泛技能(而不是狭窄领域)，则这种合作型方法就会更加有效。
制定项目章程——制定项目管理计划——指导与管理项目工作——管理项目知识——监控项目工作——实施整体变更控制——结束项目或阶段。

启动过程组：（制定项目章程、识别干系人）
制定项目章程：编写正式批准项目并授权项目经理在项目活动中使用组织资源的文件的过程。
本过程作用：明确项目和组织战略目标之间的直接联系、确立项目的正式地位、展示组织对项目的承诺。
输入：立项管理文件、协议（定义了启动项目的章程，合同、备忘录、服务协议、意向书等）、环境事业因素、组织过程资产。
工具与技术：专家判断、数据收集（头脑风暴、焦点小组、访谈等）、人际关系技能（冲突管理、引导、会议管理）、会议。
输出：项目章程、假设日志。

立项管理文件：立项管理阶段经批准的结果或相关的立项管理文件，从业务视角描述必要的信息，并且据此决定项目的期望结果是否值得所需投资。它包括：项目建议书、经济可行性研究报告、项目评估报告等。在项目之前制定，需要定期审核。不属于项目文件，项目经理不可以更新或修改。
项目章程（背诵）——由项目启动者或发起人发布的，正式批准项目成立，并授权项目经理动用组织资源开展项目活动的文件。
包含内容（背诵）：委派的项目经理及其权责；项目的目的、目标、项目的成功/退出标准；高层级需求和项目描述、高层级的战略和运营假设条件和制约因素主要可交付成果、总体里程碑进度计划、预先批准的财务预算、整体项目风险、关键干系人名单；项目审批要求、批准项目章程的人员。
假设日志：用于记录整个项目生命周期中的所有假设条件和制约因素。
假设条件：不需验证即可视为正确、真实或确定的因素。同时还应描述如果这些因素不成立，可能造成的潜在影响。
制约因素：对项目或过程的执行有影响的限制性因素。

制定项目管理计划：定义、准备和协调项目计划的所有组成部分，并整合为一份总和项目管理计划的过程。
作用：生成一份综合文件，做为所有项目工作的基础和执行方式，确定项目的执行、监控和收尾方式。
可以是概括的或者详细的，通过不断更新来渐进明细。一旦被确定为基准，只能通过提出变更请求并经过过实施整体变更控制过程批准后才能更新。
输入：项目章程（是初始计划的起点，包括高层级的信息、供进一步细化）、其他知识领域过程的输出（用于打包到项目管理计划，范围管理计划、进度管理计划等等）、环境事业因素、组织过程资产。
工具与技术：专家判断、数据收集、人际关系技能、会议等。
输出：项目管理计划，包括10个子计划、3基准、6个组件。（背诵）
其中，生命周期描述指的是项目各个阶段，开发方法指的是预测、敏捷或者混合。

制定项目管理计划工具与技术：会议
启动会议（initiating meeting）：招考时间在启动结束，规划尚未开始时。目的是发布项目章程、任命并授权项目经理。
开工会议（kick-off meeting）：传达目标、获得团队对项目的承诺、阐明干系人角色和职责、获得干系人对项目管理计划的一致认可。

整合管理过程——指导与管理项目工作。
领导和执行项目管理计划中确定的工作，并实施已批准变更的过程。
作用：干计划（按项目管理计划去干活）、干变更（实施已批准的变更）、干接口（实施接口的整合）、干成果（产生可交付成果）、干数据（产生工作绩效数据）。

输入：项目管理计划（项目管理计划的任何组件）、批准的变更请求、项目文件、环境事业因素和组织过程资产。
工具与技术：专家判断、项目管理信息系统（PMIS，为指导和管理项目工作提供自动化工具并自动收集和报告关键绩效指标，用于保证项目工作由正确的组织、正确的时间里以正确的顺序进行，防止“镀金”）、会议。
输出：可交付成果（只在指导与管理项目过程中输出，在某一阶段或者项目完成后，必须产生的任何独特并可核实的产品、成果或者服务能力，通常是项目结果，并包括项目管理计划的组成部分）、工作绩效数据（只在指导与管理项目过程中输出，工作绩效数据、工作绩效信息、工作绩效报告）、问题日志、变更请求、项目管理计划更新、项目文件更新。

问题日志：记录和跟进所有问题的项目文件，在指导语管理项目工作的过程中首次创建，在整个项目周期随同监控活动更新。

变更请求：关于修改任何文档、可交付成果或者基准的正式提议。可以是直接或者间接、由外部或者内部提出，自选或者法律/合同强制，必须有书面记录。
变更的种类：
预防措施：为确保项目工作的未来绩效符合项目管理计划而进行的活动，防风险。
纠正措施：为使项目工作绩效重新与项目管理计划一致而进行的活动，纠偏差。
更新：对正式受控的项目文件或计划等进行的变更，改基准。
缺陷补救：为了修正不一致的产品或产品组件而进行的活动，补质量，通常针对质量缺陷。

如何召开高效会议（案例、论文可用）：
1、事先制订一个例会制度、明确会议规则；
2、放弃可开可不开的会议；
3、明确会议的目的和期望结果、明确每个参会者的角色；
4、发布会议通知；
5、在会议之前将会议资料发给参会人员；
6、面对面的会议效果最好、也可以借助视频设备；
7、会议后要总结、提炼结论、达成共识、有行动计划；
8、会议要有纪要；
9、做好会议的后勤保障；
10、不要把各种会议类型混合在一起。

项目生命周期和项目阶段，不同的项目周期可能不一样。（掌握）
项目生命周期——项目从启动到完成所经历的一系列阶段，阶段间的关系可顺序、迭代、交叠。（时间维度划分）。
开发生命周期——项目生命周期内与产品、服务或成果的开发相关的一个或多个阶段。 （生命周期中某几个阶段）。
项目通用生命周期——启动项目；组织与准备；执行项目工作；结束项目； （4个通用阶段）。
产品生命周期——从项目开始到项目结束再到项目产品运行生命终止（退出市场）的全过程。
项目管理过程组——启动、规划、执行、监控、收尾（5个通用操作过程）（管理操作维度划分）。

通用生命周期（掌握）
（1）成本与人力投入：项目开始时“缓慢增加”，在“执行工作”期间达到最高，项目快结束时“迅速回落”。
（2）风险与不确定性、干系人的影响力、变更的数量：项目开始时最大，后续“逐步降低”。
（3）变更的代价、风险的影响：项目开始时较小，后续“显著增高”。

开发生命周期——预测型（瀑布型、计划驱动）如建筑行业（掌握）
可行性——设计——构建——测试——部署——收尾
优点：按阶段便于管理；开发团队比较弱适用；
缺点：周期长；不灵活；
特点：
范围、进度、成本在早期阶段就确定；范围变更很少，干系人之间有高度共识；对任何范围的变更都要进行严格管理；每个阶段都侧重于某一特定类型的工作；上一阶段输出作为下一阶段输入，阶段评审通过则进入下一阶段，否则返回之前阶段；按计划执行、一次交付。
适用：需求明确或很少变更的项目；有厚实的行业实践基础；整批一次性交付有利于干系人。

开发生命周期类型—迭代型（掌握）
迭代型——范围在早期确定，但时间及成本估算将随项目团队对产品理解的不断深入而定期修改。
适用于：计划多期开发的、在开发早期需求可能有所变化、需要降低项目复杂性的、部分交付有利于干系人的。重复的循环，属于“完善型迭代”。

开发生命周期类型—增量型（掌握）
在预定的时间区间内渐进增加产品功能的一系列迭代来产出可交付成果。
（1）只有在最后一次迭代之后，可交付成果具有了必要和足够的能力，才能被视为完整的。
（2）渐进地增加，属于“功能型迭代”。

开发生命周期类型—适应型（敏捷型、变更驱动）（掌握）
在每次迭代前，项目和产品愿景的范围被明确定义和批准，每次迭代（又称 “冲刺”）结束时，客户会对具有功能性的可交付物进行审查并提供反馈，反馈意见会更新至项目待办事项列表，以确定下一次迭代中特性和功能的优先级。
特点：先基于初始需求制定一套高层级计划，再逐渐把需求细化到适合特定规划周期所需的详细程度。较小增量、快速迭代（2~4周，固定）、每次交付最有价值成果。
适用：需求不确定，不断发展变化的项目。

项目管理过程组——为了达成项目的特定目标，对项目管理过程进行的逻辑上的分组。（了解）
启动过程组——授权一个项目或阶段的开始；
规划过程组——明确项目范围、优化目标，并为实现目标制订行动计划；
执行过程组——完成项目管理计划中确定的工作，以满足项目要求；
监控过程组——跟踪、审查和调整项目进展与绩效，识别变更并启动相应的变更；
收尾过程组——正式完成或结束项目、阶段或合同。
过程组在整个项目期间相互重叠；过程组中的各个过程会在每个阶段按需要重复开展，到达到该阶段的完工标准。

项目管理过程组—适应型项目中的过程组（掌握）
启动过程组——识别关键干系人，每个迭代期开展，频繁回顾和重新确认项目章程，确保朝最新的目标推进；
规划过程组——让尽可能多的团队成员和干系人参与到规划过程；
执行过程组——每次迭代都在一个很短的固定时间段内开展工作，干系人和团队基于演示来进行回顾性审查；项目经理聚焦于高层级的目标，并授权团队成员用最能实现目标的方式自行安排具体工作；
监控过程组——通过维护包含工作和变更的未完项清单，对进展和绩效进行跟踪、审查和调整；
收尾过程组----对工作进行优先级排序，以便首先完成最具业务价值的工作。

五过程，10领域，49个过程（掌握）。

第七章 项目立项管理（重点）
项目建议与立项申请（第一阶段）——可行性研究（内容、初研（第二阶段）、细研（第三阶段））——项目评估与决策（第四阶段）。
项目立项管理——对拟规划和实施的项目技术上的先进性、适用性，经济上的合理性、效益性，实施上的可能性、
风险性以及社会价值的有效性、可持续性等进行全面科学的综合分析，为项目决策提供客观依据的一种研究活动。
包括4个阶段----项目建议与立项申请、初步可行性研究、详细可行性研究、评估与决策。
初步可行性研究和详细可行性研究可以依据项目的规模和繁简程度合二为一，但详细可行性研究不可缺少。
升级改造项目只做初步和详细研究，小项目一般只进行详细可行性研究。

项目建议与立项申请（重点）
项目建议书（立项申请）——是项目建设单位（甲方，乙方是承建单位）向上级主管部门提交项目申请时所必须的文件，是提出的某一具体项目的建议文件，是对拟建项目提出的框架性的总体设想。
作用：
（1）是国家或上级主管部门选择项目的依据；
（2）也是可行性研究的依据；
（3）涉及利用外资的项目，在项目建议书批准后，方可开展对外工作。
核心内容：项目的必要性、项目的市场预测、产品方案或服务的市场预测、项目建设的比需的条件。

项目的可行性研究（重点）
可行性研究——从技术、经济、社会和人员等方面的条件和情况进行调查研究，对可能的技术方案进行论证，
以最终确定整个项目是否可行。信息系统项目开发的可行性包括：可能性、效益性和必要性，三者缺一不可。
技术可行性分析：（技术能力、开发风险、人力资源有效性、物资可用性）技术可行性分析往往决定了项目的方向。
经济可行性分析：支出分析—一次性（开发费、差旅费、购置费等）和非一次性（租金、工资、水电费、消耗品支出等）；收益分析—直接（产品收入）和间接（成本降低）；收益投资比和投资回收期分析、敏感性分析。
社会效益可行性分析：对组织内部（品牌、竞争力、 技术创新、人员提升、管理提升）；对社会发展（公共、文化、环境、社会责任感）。
运行环境可行性分析：运行环境是制约信息系统发挥效益的关键。
其他方面的可行性分析：法律可行性、政策可行性等。

可行性研究—初步可行性研究（掌握）
初步可行性研究——在对市场或者客户情况进行调查后，进行大体收集材料，对投资项目的前景进行初步评估的过程，并决定是否继续进行详细可行性研究。（可和详细可行性研究合二为一） 。
经过初步可行性研究，可以形成初步可行性研究报告，该报告可以作为正式的文献供决策参考。
初步可行性研究的主要内容基本与详细可行性研究相同。不同的是占有的资源、研究细节方面有较大差异。

初研主要内容：需求与市场预测；设备与资源投入分析；空间布局；项目设计；项目进度安排；项目投资与成本估算。

辅助（功能）研究——包括项目的一个或几个方面（如试验室和中间工厂的实验、规模的经验性研究、设备选择研究等），但不是所有方面。
只能作为初步可行性研究、详细可行性研究的前提或辅助。 辅助研究的费用必须和项目可行性研究的费用一并考虑。
在初步可行性研究之前进行——一项基本投入是确定可行性的一个决定因素。
完成可行性研究之后进行——可研中要对项目的某一方面进行更详尽地鉴别。

可行性研究—详细可行性研究（重点）
详细可行性研究----在项目决策前对项目有关的技术、经济、法律、社会环境等各方面的条件和情况进行详尽的、系统的、全面的调查、研分析，对各种可能的技术方案进行详细的论证、比较，并对项目建设完成
后所可能产生的经济、社会效益进行预测和评价，最终提交的可行性研究报告将成为进行项目评估和决策的依据（不可省略，必须要有）。
详细可行性研究的方法有：投资估算法、增量净效益法（有无比较法）、经济评价法、市场预测法；
投资估算法——数量性估算（比例估算法）、研究性估算、预算性估算、投标估算；
增量净效益法（有无比较法）——将有项目时的成本（效益）与无项目时的成本（效益）进行比较，求得两者差额，即为增量成本（效益）。
详细可行性研究原则：科学性、客观性、公正性。

详细可行性研究内容：市场需求预测、经济评价及综合分析、部件和投入的选择供应、架构及技术方案、技术与设备选择、网络物理布局设计、投资（重点）、成本估算与资金筹措（资金来源等）。
可行性研究报告的开发总成本：经营成本和非经营成本。
经营成本：研发成本、行政管理费、销售与分销费用。
非经营成本：财务费用和折旧。
细研阶段：否定或初步肯定（±30%）、初步可行性研究（±20%）、详细可行性研究（±10%）、设计开发时（±5%）。

项目评估与决策—掌握
项目评估——在项目可行性研究的基础上，由第三方（国家、银行或有关机构）对拟建项目的各方面进行评价、分析和论证，进而判断其是否可行的一个评估过程。
项目评估是项目投资前期进行决策管理的重要环节，目的是审查项目可行性研究的可靠性、真实性和客观性；
为银行的贷款决策或行政主管部门的审批决策提供科学依据；
项目评估的最终成果是项目评估报告。

评估依据：项目建议书及审批文件、项目可行性研究报告、申请报告及初审意见、关键建设性意见和协议文件、必须的其他文件。
项目评估的7个步骤：
成立评估小组——开展调查研究——分析与评估、编写讨论修改评估报告——专家论证会——评估报告定稿发布。

1，敏捷项目里，当前sprint不做变更，所以项目经理不能再当前迭代里做紧急更改。
2，项目正在被延迟，已经是一个问题。项目经理将谈判已经记录为风险，这是一个已识别并发生的风险。所以，整体来说应该是记录问题，并遵循风险应对计划的行动。
3，审计审查过程，问题是没有遵守政策流程和审批手续。应该按照质量管理计划的内容，审查流程，找到缺失的差距。
4，项目经理发现一个风险，做为风险管理的一部分，这是一个机会。应该告诉管理层，这是一个扩大市场份额和开发新产品的机会。
5，团队专注于sprint目标，解决障碍应该是项目经理的事，PMO实施的框架跟当前敏捷交付不见人，说明这是一个障碍，理论上不应该直接让团队进入，应该先审查框架，再决定是否让团队参与沟通。
6，关键干系人无法参加会议，如果重新安排会议的话，即使这次可以参加，那后续仍然无法参加，应该是分享会议议程，期望达成目标。
7，客户的标准，指的是验收的标准，就是确认范围。收集需求——定义范围——范围说明书有可交付成果的定义及验收标准，所以开始的时候要记录和定义【需求】。目标在项目章程里，不在标准里。
8，规划质量是描述项目将如何证明符合质量要求和(或)标准的过程。要确保在执行阶段符合质量要求那么需要做好规划质量管理。持续调查可交付成果的质量，这是控制质量查结果。质量不是靠检查出来的。每个阶段都能做五大过程组，所以实施阶段也可以做规划质量管理。
9，在xxx之前，不能开始一项活动，这xxx就是前提，属于强制依赖关系。而快速跟进是选择性依赖关系。所以这种制约因素，可以记录在假设日志里，包含前后的相关性。
10，项目目标是产品上市，涉及到这个项目的问题，会涉及项目目标不能达成，可能会失败，此时可以考虑上报项目发起人。
11，技术问题阻止交付，人员也要离职；参考资源管理计划只能解决人的问题，无法解决技术问题。所以整体来说审查整体的制约因素，评估计划的发布，再决定如何解决问题。
12，最常见的问题是什么工件将取代项目时间表。项目经理应该如何回应？待办事项列表跟需求范围有关系，跟进度没直接的关系。所以项目经理应查看冲刺计划和产品路线图。冲刺计划涵盖了时间进度。
13，“一些资源与由各自的业务单元发起的计划之外的其他项目共享”，资源和其他项目共享，就该先咨询其他项目的项目经理。
14，算法，属于技术问题，跟用户故事无关，算法属于执行层面由团队自组织决定。《创建一个新条目来确定合适的算法》属于一个spike，在某个迭代里做个刺探来决定。敏捷主管无法决定技术问题。
15，“难以访问”跟项目存储库是不是新不新没关系，最多是访问的版本不是新的。应该做好团队交叉培训知识共享。
16，“确保团队和项目目标一致”，是为了搞清楚目标是什么，而不是为了修改目标，目标记录在项目章程里。没必要讨论，我们不是为了修改。只要查看项目章程就可以满足题目。
17，“团队成员希望提高自己的引导技能”，说明团队成员希望自己去主持并引导会议，不涉及团队的技能不足，只是说没机会引导，不涉及培训。项目经理应该给团队机会。
18，冲突是分为积极和消极的，成功的冲突管理是可以提高生产力。pmpbok里没涉及结构性或者人际冲突。
19，沟通和协作，不涉及技能不足，不涉及团队的培训和知识转移。沟通有差距应该解决组织会议相互了解。
20，敏捷项目里，谁的需求是最重要的？客户。
21，在试图确定一个项目的领导风格时，应该先考虑组织文化。
22，“发起人一直要求最重要的项目里程碑的具体日期”，考察项目章程包括哪些内容，范围，需求，目标，成功标准和退出标准，审批计划和干系人，整体里程碑和进度计划，里程碑是一个时间点已经包括。
23，一个风险一旦上报之后，项目经理只能看高级别领导的决策，无法做更多的行动。

1，冲突才有冲突的解决方法。想法的分歧属于观点的争论，允许自组织团队自己解决。
项目经理介入：有人明确违反基本规则、冲突双方有来找项目经理投诉、冲突进一步升级、明确说团队已经无法协作等。
2，审计目标：识别做的好的和不好的、分享其他项目的良好实践、协助改进、积累经验、确认（变更有没有被正常执行）。
3，准备报告后，要进行汇报沟通，沟通是定制化需求量身定制，没有标准SOP操作程序。在完成报告前可以跟干系人开会了解需要什么内容，进行需求沟通分析。
4，Scrum敏捷过程采用故事点估算方法，也叫相对估算。
5，根本原因分析是问题发生之后做，不适合“如何预防”类问题。
6，潜在要发生的事情，是一个风险，没有明确要发生问题。
7，敏捷是固定的时间盒，不能调整。如果团队需要时间来培训，在固定时间内的产能就要降低。
8，干系人不允许推进项目的情况，“非常规策略”不能选择，属于不正常策略。
9，如何让干系人了解项目当前已经实现的价值？ 参加迭代演示。
10，已完成项目管理计划，确保获得干系人的支持，干系人的问题，引导参与获得支持，应管理干系人的参与，确保干系人或者其团队部门都能参会了解。
11，一位非常重要的专家不能继续工作，属于资源缺失，重点应该沟通资源的需求。
12，因xx原因导致改变了方向，意味着项目范围已经更改且明确，团队士气低落应该鼓励团队。如果范围不清晰则需要澄清范围。
13，敏捷项目，新功能，应该和PO审查信息安全问题，并识别风险。
14，认可与奖励的考点，就是激励，分有形和无形，要满足某个需求才算有效的奖励。项目经理如何使用奖励，最好的办法是听一下团队的意见。
15，沟通是信息的交换，信息的多、少、不懂算沟通。不能解决干系人的各种担忧，应该是想办法解决引导干系人参与。
16， 组织内获取资源：谈判，跟职业经理谈，和其他干系人谈等。
17，合同执行过程组收到重大差异，项目经理在最初该做什么？以前没差异，现在有了，应识别差异。
18，项目经理接收新项目，缺少绩效的记录，应该根据关键绩效指标KPIS来评估，符合客观事实。
19，商业价值发生变化，要重新审查商业价值，将调整后的商业价值重新评估并考虑。
20，项目启动需要开展的任务：制定项目章程、识别干系人。
21，干系人说工作不满足实际业务需求，首先要先跟该干系人确认未包含哪些功能，然后确认是否属实。
22，如何确保合规？咨询一下专家，不能确保最终合规。写到项目管理计划里，项目会按照项目管理计划执行，可以合规。在质量管理计划记录新设备的信息，不能确保。合规要求不仅仅和质量有关系，也可能跟需求有关系，所以不能仅仅关注质量管理计划。
23，促进新成员和干系人互动，首先要了解有哪些干系人，审核干系人登记册；然后看下如何跟干系人沟通，查看感谢人参与计划；最后安排和干系人的会议。
24，目的：为了发放更新后的会议决策，应该参考：沟通管理计划，信息的发放。
25，评估两个项目，这对组织的财务健康状况有帮助，换句话说就是，考察项目的财务指标：计算项目的内部收益率。
26，连续6周连续加班，法律上不允许，中国法律规定每月加班不得超过36小时。所以要优先考虑法律法规问题。
27，敏捷项目无法明确详细的项目范围，需求都在PB里，而不是在业务需求文件，所以产品待办列表PB可以用来解释项目范围。
28，自制外购分析有关的价值指标。PMBOK第六版P473：在自制或外购分析中，可以使用回收期、投资回报率(ROI)、内部报酬率(IRR)、现金流贴现、净现值(NPV)、收益成本(BCA)或其他分析技术，来确定某种货物或服务是应该在项目内部自制，还是从外部购买。
29，采取措施解决问题，但是问题依然存在，说明采取的措施有问题，应该考虑重新分析制定新的措施。记录在问题日志中没有必要，没有解决问题。
30，PMO要审计当前迭代的进度，要参加sprint冲刺评审会。回顾是总结经验教训的。发布评审未提过有这样名称的会议。
31，客户尽快发布产品，增量法才能尽快发布。迭代法是优化，获取反馈，不适合。
32，项目遇到技术问题，需要找干系人参会评审并确认，公司内部和管理层都无法代替最终的用户，所以最好的干系人是用户团队。
33，团队成员刚刚加入团队，就立即开始质疑当前项目主管的所有决定，这种做法是典型的违背的基本规则的情况，而不是普通的双方的冲突。跟当前主管也没关系。
34，如何监控合规性？项目审计，无论是安全合规还是质量合规。