六、规划绩效域
-
制定项目章程
制定项目章程是编写一份正式批准项目并授权项目经理在项目活动中使用组织资源的文件的过程。
-
输入：商业文件（商业论证，效益管理计划）；协议（来自甲方）；事业环境因素；组织过程资产。
-
商业文件 - 商业论证
指文档化的经济可行性研究报告，用来对尚缺乏充分定义的所选方案的收益进行有效性论证，是启动后续项目管理活动的依据。
项目经理如果可能应该积极参与并与商业分析师合作，以便对项目的假设条件和制约因素有深刻的了解。
-
商业文件 - 效益管理计划
项目效益管理计划描述了项目实现效益的方式和时间，以及应制定的效益衡量机制。
项目效益指为发起组织和项目预期受益方创造价值的行动、行为、产品、服务或成果的结果。项目生命周期早期应确定目标收益，并据此制定效益管理计划。描述了效益的关键要素，制定该计划是一项迭代活动。由高层尤其是发起人制定的用于保证组织，高层尤其是发起人利益的一个计划，项目经理通常无权修改。
-
协议
协议用于定义启动项目的初衷。
为外部客户做项目时，通常就以合同的形式出现。合同是对双方都有约束力的协议。它强制卖方提供规定的产品、服务或成果，强制买方向卖方支付相应的报酬。
-
-
工具：专家判断；数据收集（头脑风暴，焦点小组，访谈）；人际关系与团队技能（冲突管理，引导，会议管理）；会议。
-
专家判断
是指基于某应用领域、知识领域、学科和行业等的专业知识而做出的，关于当前活动的合理判断。
这些专业知识可来自具有专业学历、知识、技能、经验或培训经历的任何小组或个人。
-
数据收集 - 头脑风暴
头脑风暴用于在短时间内获得大量创意，适用于团队环境，需要引导者进行引导。
头脑风暴由两个部分构成：创意产生和创意分析。
-
数据收集 - 焦点小组
焦点小组是召集预定的相关方和主题专家，了解他们对所讨论的产品、服务或成果的期望和态度。
由一位受过训练的主持人引导大家进行互动式讨论。焦点小组往往比"一对一"的访谈更热烈。
焦点小组，一般由8~12人组成。
-
数据收集 - 访谈
访谈是通过与相关方直接交谈，来获取信息。
向被访者提出预设和即兴的问题，并记录他们的回答。
访谈经常是一个访谈者和一个被访者之间的"一对一"谈话，但也可以包括多个访谈者和/或多个被访者。
访谈有经验的项目参与者、发起人和其他高管，以及主题专家，有助于识别和定义所需产品可交付成果的特征和功能。
访谈也可用于获取机密信息。
-
人际关系与团队技能 - 冲突管理
是指处理或解决项目中某些关系难以协调而导致的矛盾计划和行为对抗。
-
人际关系与团队技能 - 引导
引导是指有效引导团队活动成功以达成决定、解决方案或结论的能力。
引导者确保参与者有效参与，互相理解，考虑所有意见，按既定决策流程全力支持得到的结论或结果，以及所达成的行动计划和协议在之后得到合理执行。
-
人际关系与团队技能 - 会议（管理）
项目会议可包括虚拟（网络）或面对面会议，且可用文档协同技术进行辅助，包括电子邮件信息和项目网站。
在规划沟通管理过程中，需要与项目团队展开讨论，确定最合适的项目信息更新和传递方式，以及回应各相关方的信息请求的方式。
-
-
输出：项目章程；假设日志。
-
项目章程
项目章程是由项目发起人发布的，正式批准项目成立，并授权项目经理动用组织资源开展项目活动的文件（拟任项目经理变为项目经理）。它记录着项目和项目交付预期的产品、服务或成果的所有高层级信息。有了它发起人能为项目获取资金和提供资源。
-
假设日志
在项目启动之前编制商业论证时，识别高层级的战略和运营假设条件与制约因素。
这些假设条件与制约因素应纳入项目章程。并最后归为项目文件中。
-
-
规划绩效域
在整个项目期间，规划组织、详细制定和协调项目工作。
规划绩效域：规划绩效域涉及为交付项目可交付物和项目成果所需的与初始、持续进行和演变的组织和协调相关的活动和功能。
-
有效执行此绩效域将产生以下预期效果：
项目以有条理，协调一致和经过周密考虑的方式推进。
有一种交付项目成果的整体方法。
对不断演变的信息做出了详细说明，以生成开展项目所寻求获得的可交付物和项目成果。
规划所花费的时间适合于相关情况。
规划信息足以管理干系人期望。
根据新出现的和不断变化的需要或条件，在整个项目期间有一个对计划进行调整的过程。
-
以下定义与规划绩效域相关：
- 估算。对某一变量的可能数值或结果的定量评估，如项目成本、资源、人力投入或持续时间。
- 准确度。在质量管理体系中，"准确度"是指对正确程度的评估。
- 精确度。在质量管理体系中，"精确度"是指对精准程度的评估。
- 赶工。通过增加资源，以最小的成本代价来压缩进度工期的一种方法。
- 快速跟进。一种进度压缩方法，将正常情况下按顺序进行的活动或阶段改为至少部分按并行方式开展。
- 预算。经批准的对整个项目、任一工作分解结构（WBS）组件或任一进度活动所做的估算。
-
规划概述
- 规划的目的是积极主动地制定一种方法来创建项目可交付物。项目可交付物会推动项目所要取得成果。高层级规划可以在项目批准授权之前开始。项目团队会逐步制定初始项目文件，例如愿景陈述、项目章程、商业论证或类似文件，以识别或定义实现预期成果的相互合作的方法。
- 规划就是要在项目活动进入执行前回答 做什么，花多少钱，何时完成 这三个方面的问题，无论是项目整体层面还是具体活动细节层面都是如此，但是不同的项目生命周期类型和开发类型对规划的要求，详细程度等都有不同。
- 除了财务影响之外，在初步规划中考虑社会和环境影响的做法越来越普遍（有时称为三重底线）。这可能会采取产品生命周期评估（即评估产品、过程或系统的潜在环境影响）的形式。产品生命周期评估为产品和过程的设计提供信息。它会考虑材料和过程有关可持续性、有害毒性和环境的影响。
-
关键名词解释 - 赶工，快速跟进
-
赶工。通过增加资源，以最小的成本代价来压缩进度工期的一种技术。如果可以优选赶工胜过快速跟进。
赶工的例子包括：批准加班、增加额外资源或支付加急费用，来加快关键路径上的活动。赶工只适用于那些通过增加资源就能缩短持续时间的，且位于关键路径上的活动。但赶工并非总是切实可行的，因它可能导致风险和/或成本的增加。
-
快速跟进。将正常情况下按顺序进行的活动或阶段改为至少是部分并行开展。不能追赶错过的里程碑，风险比赶工更大。
快速跟进可能造成返工和风险增加，所以它只适用于能够通过并行活动来缩短关键路径上的项目工期的情况。以防进度加快而使用提前量通常增加相关活动之间的协调工作，并增加质量风险。快速跟进还有可能增加项目成本。
-
-
关键名词解释 - 估算
估算一般用于进度，成本。有如下几种估算方法：
-
类比估算：类比估算是一种使用相似活动或项目的历史数据，来估算当前活动或项目的持续时间或成本的技术。类比估算以过去类似项目的参数值（如持续时间、预算、规模、重量和复杂性等）为基础，来估算未来项目的同类参数或指标。
优点：类比估算通常成本较低，耗时较少。缺点：准确性也较低。成本最低，用时最短，准确性最差，一般用于项目启动或者商业论证阶段。
-
参数估算：参数估算是一种基于历史数据和项目参数，使用某种算法来计算成本或持续时间的估算技术。准确性取决于参数模型的成熟度和基础数据的可靠性。且参数进度估算可以针对整个项目或项目中的某个部分，并可以与其他估算方法联合使用。
活动历时=成果数量*生产率/可用资源数量。成本用时精确度一般都中等，结果严重依赖数据质量和模型有效性。可以在项目的各个阶段使用，但是不适用于缺乏历史数据的项目。
-
自下而上估算：是一种估算项目持续时间或成本的方法，通过从下到上逐层汇总，WBS组成部分的估算而得到项目估算。如果无法以合理的可信度对活动持续时间进行估算，则应将活动中的工作进一步细化，然后估算具体的持续时间，接着再汇总这些资源需求估算，得到每个活动的持续时间。活动之间可能存在或不存在会影响资源利用的依赖关系；如果存在，就应该对相应的资源使用方式加以说明，并记录在活动资源需求中。
成本最高，耗时最长，精确度也最高，一般用于最终编制项目的时间基准、成本基准等阶段使用。
-
三点式估算：起源于计划评审技术PERT。使用三点式估算有助于界定活动持续时间的近似区间，一般用于缺乏精确模型的局部估算场景。
以时间估算为例：最可能时间；最乐观时间；最悲观时间。三点估算默认我们想要得到概率中间值即期望值。
-
-
进度
进度计划是执行项目活动的模型，包括持续时间、依赖关系和其他规划信息。进度规划时可以采用预测型方法遵循以下分步过程：
① 将项目范围分解为具体活动。
② 按顺序排列相关活动。
③ 估算完成活动所需的人力投入、持续时间、人员和实物资源。
④ 根据可用性为活动分配人员和资源。
⑤ 调整顺序、估算和资源，直至达成一致同意的进度计划。
-
预算
- 估算信息会被应用于项目成本，以制定成本估算。然后会将估算汇总，以制定成本基准。成本基准通常在整个项目进度中分配，以反映将于何时产生成本。这种实践做法使项目经理能够在特定预算期内核准的资金与所计划的工作之间取得平衡。如果某个预算期有资金限制，则可能需要重新安排工作，以符合这些限制。风险事件。
- 项目预算应包括应急储备，以应对不确定性。之所以留出应急储备，是为了实施风险应对或为了应对与范围内工作有关的意外活动。
- 管理储备可由项目、发起人、产品负责人或项目集和项目组合层级的项目管理办公室（PMO）管理，具体取决于组织的政策和组织结构。
- 项目中的预算包括：资源，采购，风险，质量四个来源和组成部分。
-
项目团队的组成和结构
- 规划项目团队组成时，首先要确定完成项目工作所需的技能组合。这不仅需要评估技能，还需要评估熟练程度和类似项目方面的经验年限。带来的收益与其将会产生的成本进行权衡。
- 使用内部项目团队成员与获取组织外部人员的成本结构各不相同。
- 在针对项目团队进行规划时，项目经理会考虑项目团队在同一地点开展工作的能力和必要性。可以在同一个房间工作的小型项目团队能够利用渗透式沟通，并能在问题出现时就将问题解决。一些项目团队的成员位于不同地点。项目团队成员可能位于不同的城市、时区或国家/地区。项目团队成员通过虚拟方式开展工作，需要花费更多时间通过技术手段将人们连接起来。
-
沟通
- 沟通规划会与干系人识别、分析、优先级排序和参与的内容有所重叠，这些内容会在干系人绩效域中描述。沟通在争取干系人有效参与方面是最重要的因素。
- 可能存在不同类别的信息，例如内部信息和外部信息，敏感信息和公开信息，或者一般信息和详细信息。
- 分析干系人、信息需求和信息类别为制定项目的沟通过程和计划奠定了基础。
-
实物资源
- 实物资源适用于人员以外的任何资源。实物资源可以包括材料、设备、软件、测试环境、许可证等。实物资源规划涉及估算以及供应链、物流和管理。拥有大量实物资源的项目（例如工程和建筑项目）将需要为采购活动指定计划，以获取资源。这可能与使用基本订购协议一样简单，也可能与管理、协调和整合多项大型采购活动一样复杂。规划实物资源包括考虑到材料交付、移动、存储和处置的提前期，以及跟踪从抵达现场到交付集成产品的材料库存的手段。其项目需要大量实物材料的项目团队，会从战略角度思考和规划从订单到交付再到使用的时间安排。这可能包括评估批量订购对比存储成本、全球物流、可持续性，以及将实物资产与项目的其余部分进行整合管理。
-
采购
- 采购可以在项目期间的任何时候进行。但预先规划有助于设定期望，确保采购过程顺序进行。一旦了解了高层级范围，项目团队就会进行自制或外购分析。这包括确定将在内部开发的可交付物和服务，以及将从外部资源购买的可交付物和服务。这些信息会影响项目团队和进度计划。合同签订专业人士需要事先了解所需货物类型、何时需要这些货物以及所采购货物或服务所需的任何技术规范。
-
规划采购知识点补充 - 采购的分类和特点
与采购过程相关的重大法律义务和惩罚，通常超出大多数其他的项目管理过程。通常情况下，项目经理无权签署对组织有约束力的法律协议，但应该对采购过程有足够了解，以便做出与合同及合同关系相关的明智决定。
-
在小型组织或初创企业，以及未设置购买、合同或采购部门的组织，项目经理可以拥有采购职权，能够直接谈判并签署合同（分散式采购）
在更成熟的组织中，由专设部门开展实际的采购和合同签署工作，即采购、谈判和签署合同（集中式采购）
-
规划采购知识点补充二 - 采购经典步骤
① 准备采购工作说明书（SOW）或工作大纲（TOR）；
② 准备高层级的成本估算，制定预算；
③ 发布招标广告；
④ 确定合格卖方的短名单；
⑤ 准备并发布招标文件；
⑥ 由卖方准备并提交建议书；
⑦ 对建议书开展技术（包括质量）评估；
⑧ 对建议书开展成本评估；
⑨ 准备最终的综合评估报告（包括质量和成本），选出中标建议书；
⑩ 结束谈判，买方和卖方签署合同。
-
规划采购知识点补充三 - 规划采购的结果
① 采购管理计划
② 采购策略
③ 招标文件
④ 采购工作说明书
⑤ 供方选择标准
⑥ 自制或外购决策
⑦ 独立成本估算
-
规划采购知识点补充四 - 合同类型
- 总价类
- 成本补偿类
- 工料类
-
变更
整个项目期间会发生很多变更，某些变更是因发生风险事件或项目环境变化而导致的，有些则是基于对需求的深入了解，而其他变更则是由于客户请求或其他原因造成的。因此，项目团队应制定相关流程，以便在整个项目期间可以调整计划。这可能包括采取变更控制流程、重新确定待办事项列表的优先级排序，或者重新确定项目基准等形式。具有合同要素的项目可能需要遵循已定义的合同变更流程。
-
变更控制流程（预测型适用）
① 在变更正式提出前，针对干系人的变更意向进行沟通，了解真实变更意图分析变更 合规性，可行性，有效性
② 由干系人正式提出变更请求，然后全程在变更日志中予以登记和更新。项目团队针对变更所影响的范围进度成本等基准进行分析得出可行方案和意见
③ 如果不涉及基准，项目章程，合同，管理储备，一般可以由PM负责审批。如果涉及则由CCB（变更控制委员会）进行审批
④ 根据CCB的决定进行批准的变更实施
⑤ 更新相关变更后的项目基准和文件
⑥ 总结经验教训
合同变更需客户批准，涉及章程需发起人批准，涉及紧急情况，需走紧急变更流程（权变）。
-
度量指标
规划、交付和测量工作之间存在自然的联系。这种联系就是度量指标。制定度量指标包括设定临界值，指明工作绩效是否符合预期，是否有与预期绩效正向或负向偏离的趋势，或者是否不可接受。决定测量什么和多久测量一次，最好的说法是"只测量重要的东西"。
与产品相关的度量指标仅适用于正在开发的可交付物。与进度和预算绩效相关的度量指标通常由组织标准驱动，并与基准或者经批准版本的进度或预算（实际结果将与它们进行比较）相关。
作为规划的一部分，将制定绩效的度量指标、基准和临界值，以及任何测试和评估的流程和程序，用于根据项目可交付物的规格来测量绩效。作为测量绩效域的一部分，度量指标、基准和测试都被用作评估实际绩效偏差的依据。
-
一致性
- 在整个项目期间，规划活动和工件需要保持整合。这意味着，范围和质量要求方面的绩效规划与以下内容保持一致：交付承诺、分配的资金、资源的类型和可用性、项目固有的不确定性以及干系人的需要。项目团队可能需要额外的计划工件，具体取决于项目类型。例如，物流计划需要与材料和交付需求整合，测试计划需要与质量和交付需求保持一致，等等。关项目的工作和组织业务的工作的需要保持一致。一个项目的工作通常与一个项目集或发布中的其他项目并行实施。一个项目中工作的时间安排应与相大型项目可以将规划工件合并到一个整合的项目管理计划中。对于较小的项目，详细的项目管理计划将是低效的。无论规划的时间安排、频率和程度如何，项目的各个方面都需要保持一致且相互整合。
七、项目范围管理
项目范围管理包括确保项目做且只做所需的全部工作，以成功完成项目的各个过程。
-
范围管理核心概念
力求避免发生未计划的工作，主要需要避免镀金和范围蔓延。
镀金：以讨好相关方为目的，项目团队未经控制地主动完成额外工作。
范围蔓延：在客户或发起方的要求下，团队未经控制地完成额外工作。
额外工作：无法纳入绩效。
-
规划范围管理
规划范围管理是为记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程。
-
输入
1.项目章程
2.项目管理计划
- 质量管理计划
- 项目生命周期描述
- 开发方法
3.事业环境因素
4.组织过程资产
-
工具
1.专家判断
2.数据分析
- 备选方案分析
3.会议
-
输出
1.范围管理计划
范围管理计划是项目管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围。
-
范围管理计划要对将用于下列工作的管理过程做出规定：
制定项目范围说明书；
根据详细项目范围说明书创建WBS；
确定如何审批和维护范围基准；
正式验收已完成的项目可交付成果。
根据项目需要，范围管理计划可以是正式或非正式的，非常详细或高度概括的。
2.需求管理计划
需求管理计划是项目管理计划的组成部分，描述将如何分析、记录和管理项目和产品需求。
有些组织称之为"商业分析计划"。
-
需求管理计划的主要内容包括：
如何规划、跟踪和报告各种需求活动；
配置管理活动；
需求优先级排序过程；
测量指标及使用这些指标的理由；
反映哪些需求属性将被列入跟踪矩阵的跟踪结构。
-
-
收集需求
收集需求是为实现目标而确定、记录并管理相关方的需要和需求的过程。
-
输入
1.项目章程
2.项目管理计划
- 范围管理计划
- 需求管理计划
- 相关方参与计划
3.项目文件
- 假设日志
- 经验教训登记册
- 相关方登记册
4.商业文件
- 商业论证
5.协议
6.事业环境因素
7.组织过程资产
-
工具
1.专家判断
2.数据收集
- 头脑风暴 访谈 焦点小组
- 问卷调查 标杆对照
3.数据分析
- 文件分析
4.决策
-
投票 多标准决策分析
多标准决策分析可用于识别关键事项和合适的备选方案，并通过一系列决策排列出备选方案的优先顺序。先对标准排序和加权；再应用于所有备选方案，计算出各个备选方案的数学得分；然后根据得分对备选方案排序。
5.数据表现
-
亲和图 思维导图
亲和图用来对大量创意进行分组的技术，以便进一步审查和分析。可以对潜在缺陷成因进行分类，展示最应关注的领域。
6.人际关系与团队技能
-
名义小组技术 观察/交谈 引导
名义小组技术是用于促进头脑风暴的一种技术，通过投票排列最有用的创意，以便进一步展示头脑风暴或优先排序。
观察和交谈是指直接查看个人在各自的环境中如何执行工作（或任务）和实施流程。当产品使用者难以或不愿清晰说明他们的需求时，就特别需要通过观察来了解他们的工作细节。
引导与主题研讨会结合使用，把相关方召集在一起定义产品需求，适合引导技能的情景包括：联合应用开发；质量功能展开；用户故事。
7.系统交互图
- 系统交互图是范围模型的一个例子，它是对产品范围的可视化描述，显示业务系统（过程、设备、计算机系统等）及其与人和其他系统（行动者）之间的交互方式。
8.原型法
- 关键词 渐进明细 风险减轻
- 原型法是指在实际制造预期产品之前，先造出该产品的模型，并据此征求对需求的早期反馈。
-
输出
1.需求文件
- 需求文件描述各种单一需求将如何满足与项目相关的业务需求。所有的相关方提出的需求都应在需求文件中登记，但是未必体现在需求跟踪矩阵中。
2.需求跟踪矩阵
- 需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。必然要做，纳入范围基准。
-
-
定义
- 为实现目标而确定、记录并管理相关方的需要和需求的过程。
-
理解
- 区分：需要和需求
- 需要：相关方对希望达成目标的表述
- 需求：相关方实际需要解决的痛点
-
作用
- 为定义产品范围和项目范围奠定基础
-
发生时机
- 仅开展一次或仅在项目的预定义点开展
- 瀑布型仅立项及变更时开展
- 有迭代时每迭代开始时展开
-
参与方
- 项目经理主导，但可能不会参与到每个具体的调研工作中
- 项目管理团队，或者如果存在预分配的一线团队成员，开展实质性工作
- 面向所有相关方进行收集
-
什么是需求
- 需求是指根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力。
- 它包括发起人、客户和其他相关方的已量化且书面记录的需要和期望。
- 应该足够详细地探明、分析和记录这些需求，将其包含在范围基准中，并在项目执行开始后对其进行测量。
- 需求将成为工作分解结构（WBS）的基础，也构成为成本、进度、质量和采购规划的基础。
- S（Specific，独特性）M（Measurable，可测量）A（Attalnable，可达成）R（Relevant，相关性）T（Time-bound，时间期限）
-
定义范围
定义范围是制定项目和产品详细描述的过程。
-
输入
1.项目章程
2.项目管理计划
- 范围管理计划
3.项目文件
- 假设日志
- 需求文件
- 风险登记册
4.事业环境因素
5.组织过程资产
-
工具
1.专家判断
2.数据分析
- 备选方案生成
3.决策
- 多标准决策分析
4.人际关系与团队技能
- 引导
5.产品分析
- 产品分析可用于定义产品和服务，包括针对产品或服务提问并回答，以描述要交付的产品的用途、特征及其他方面。
- 每个应用领域都有一种或几种普遍公认的方法，用以把高层级的产品或服务描述转变为有意义的可交付成果。
- 产品分析技术包括（但不限于）：产品分解；需求分析；系统分析；系统工程；价值分析；价值工程。
-
输出
1.项目范围说明书
- 项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述：产品范围描述；项目的可交付成果；验收标准；项目的除外责任。
2.项目文件更新
- 假设日志
- 需求文件
- 需求跟踪矩阵
- 相关方登记册
-
-
创建工作分解结构（WBS）
- 定义
- 把项目可交付成果和项目工作分解成较小、更易于管理的组件的过程。
- 理解
- 根据项目规模对比和团队能力，将全部范围拆解成易于管理预算、进度的工作包
- WBS是对项目工作的组织，形成的WBS代表团队对项目工作组织形式的共识
- WBS词典是对WBS条目所代表的工作的展开描述
- 作用
- 为所要交付的内容提供架构
- 发生时机
- 仅开展一次或仅在项目的预定义点开展，预测型生命周期随范围定义完成展开
- 迭代型每次迭代开始前完成
- 参与方
- 项目经理领导本项工作的开展，项目团队负责完成WBS条目的拆解和说明
- 相关方承诺对工作结果的支持
- 范围基准
- 范围基准是经过批准的范围说明书、WBS和相应的WBS词典，只有通过正式的变更控制程序才能进行变更，它被用作比较的基础。
- 范围基准是项目管理计划的组成部分，包括：项目范围说明书；WBS，控制账户，规划包，工作包；WBS词典。
- 定义
-
确认范围
确认范围是正式验收已完成的项目可交付成果的过程。
-
输入
1.项目管理计划
- 范围管理计划
- 需求管理计划
- 范围基准
2.项目文件
- 经验教训登记册
- 质量报告
- 需求文件
- 需求跟踪矩阵
3.核实的可交付成果
4.工作绩效数据
-
工具
1.检查
2.决策
- 投票
-
输出
1.验收的可交付成果
2.工作绩效信息
3.变更请求
4.项目文件更新
- 经验教训登记册
- 需求文件
- 需求跟踪矩阵
-
检查
- 检查是指检验工作产品，以确定是否符合书面标准。
- 可以检查单个活动的成果，也可以检查项目的最终产品。
- 检查也可称为审查、同行审查、审计或巡检等，而在某些应用领域，这些术语的含义比较狭窄和具体。
-
-
控制范围
控制范围是监督项目和产品的范围状态，管理范围基准变更的过程。
-
输入
1.项目管理计划
- 范围管理计划
- 需求管理计划
- 变更管理计划
- 配置管理计划
- 范围基准
- 绩效测量基准
2.项目文件
- 经验教训登记册
- 需求文件
- 需求跟踪矩阵
3.工作绩效数据
4.组织过程资产
-
工具
1.数据分析
- 偏差分析
- 趋势分析
-
输出
1.工作绩效信息
2.变更请求
3.项目管理计划更新
- 范围管理计划
- 范围基准
- 进度基准
- 成本基准
- 绩效测量基准
4.项目文件更新
- 经验教训登记册
- 需求文件
- 需求跟踪矩阵
-
八、项目进度管理
项目进度管理包括为管理项目按时完成所需的各个过程。
-
进度管理的核心概念
项目进度计划提供详尽的计划，说明项目如何以及何时交付项目范围中定义的产品、服务和成果，是一种用于沟通和管理相关方期望的工具，为绩效报告提供了依据。
-
规划进度管理
规划进度管理是为规划、编制、管理、执行和控制项目进度而制定政策、程序和文档的过程。
-
输入
1.项目章程
2.项目管理计划
- 范围管理计划
- 开发方法
3.事业环境因素
4.组织过程资产
-
工具
1.专家判断
2.数据分析
-
备选方案分析
备选方案分析是一种对已识别的可选方案进行评估的技术，用来决定选择哪种方案或使用何种方法来执行项目工作。
很多活动有多个备选的实施方案，例如使用能力或技能水平不同的资源、不同规模或类型的机器、不同的工具（手工或自动），以及关于资源自制、租赁或购买的决策。
备选方案分析有助于提供在定义的制约因素范围内执行项目活动的最佳方案。
3.会议
-
-
输出
1.进度管理计划
**进度计划**- 进度管理计划是项目管理计划的组成部分，为编制、监督和控制项目进度建立准则和明确活动。
- 规定：项目进度模型制定；进度计划的发布和迭代长度；准确度，计量单位；组织程序链接；项目进度模型维护；控制临界值，绩效测量规则，确定完成百分比的规则；进度绩效测量指标；报告格式。
-
-
定义活动
定义活动是识别和记录为完成项目可交付成果而须采取的具体行动的过程。
-
输入
1.项目管理计划
- 进度管理计划
- 范围基准
2.事业环境因素
3.组织过程资产
-
工具
1.专家判断
2.分解
3.滚动式规划
- 滚动式规划是一种迭代的规划技术，即详细规划近期要完成的工作，同时在较高层级上粗略规划远期工作。
- 是一种渐进明细的规划方式，适用于工作包、规划包以及采用敏捷或瀑布式方式的发布规划。
- 近细远粗，近多远少。
4.会议
-
输出
1.活动清单
- 是一份包含项目所需的全部进度活动的综合清单。
- 活动清单包括每个活动的标识及工作范围详述，使项目团队成员知道需要完成什么工作。
- 每个活动都应该有一个独特的名称。
- 对于使用滚动式规划或敏捷技术的项目，活动清单会在项目进展过程中得到定期更新。
2.活动属性
- 活动属性是指每项活动所具有的多重属性，用来扩充对活动的描述，活动属性随时间演进。
- 在项目初始阶段，活动属性包括唯一活动标识（ID）、WBS标识和活动标签或名称；
- 在活动属性编制完成时，活动属性可能包括活动描述、紧前活动、紧后活动、逻辑关系、提前量和滞后量、资源需求、强制日期、制约因素和假设条件；
- 活动属性可用于识别开展工作的地点、编制开展活动的项目日历，以及相关的活动类型。活动属性还可用于编制进度计划。根据活动属性，可在报告中以各种方式对计划进度活动进行选择、排序和分类。
3.里程碑清单
- 里程碑是项目中的重要时点或事件
- 里程碑清单列出了所有项目里程碑，并指明每个里程碑是强制性的（比如合同要求的）还是选择性的（比如根据历史信息确定的）
- 强制性里程碑都是必须做的，比如，甲乙双方约定的结款条件。而选择性里程碑一般都是为了满足管理需要而设置的，比如一个长周期的项目中可交付成果在最后才产出，为了项目不至于在中途失控而无法察觉，可以设置若干检查点来检查约定的进度内容，尽管此时可交付成果还没有产生
- 里程碑的持续时间为零，因为他们代表的是一个重要时间点或事件。但是注意里程碑是跟着某个活动的结束或者某个活动的开始走的，如果移动了一些活动安排，里程碑也会相应地跟着移动。
4.变更请求
5.项目管理计划更新
- 进度基准
- 成本基准
-
-
定义
- 识别和记录为完成项目可交付成果而须采取的具体行动的过程
-
理解
- 工作包不是项目推进中的最小颗粒
- 进一步拆解工作包，拆出活动，和步骤（如可能）
-
作用
- 将工作包分解为进度活动，作为对项目工作进行进度估算、规划、执行、监督和控制的基础
-
发生时机
- 在整个项目期间开展
- 由于项目渐进明细，活动的定义可能会进行优化和完善
-
参与方
- 项目经理带领，项目团队和主题专家主要完成
- 可能需要其他相关方参与意见
-
活动类型
- 独立型活动（如，写程序）
- 依附型活动（如，测试）
- 支持型活动（如，程序员鼓励师）
-
排列活动顺序
排列活动顺序是识别和记录项目活动之间的关系的过程，定义逻辑顺序，以便在既定的所有项目制约因素下获得最高的效率。
-
输入
1.项目管理计划
- 进度管理计划
- 范围基准
2.项目文件
- 活动属性
- 活动清单
- 假设日志
- 里程碑清单
3.事业环境因素
4.组织过程资产
-
工具
1.紧前关系绘图法
- 紧前关系绘图法是创建进度模型的一种技术，用节点表示活动，用一种或多种逻辑关系连接活动，以显示活动的实施顺序。（适合工作安排，不适合汇报）
- 箭线绘图法，活动在线上，圆圈内代表状态。适合关注项目状态变化的场景。（适合汇报，不适合工作安排）
2.确定和整合依赖关系
强制性依赖关系
选择性依赖关系
外部依赖关系
内部依赖关系
3.提前量和滞后量
- 提前量是相对于紧前活动，紧后活动可以提前的时间量
- 滞后量是相对于紧前活动，紧后活动需要推迟的时间量
- 两者用于化解活动与活动之间的风险
4.项目管理信息系统
-
输出
1.项目进度网络图
项目进度网络图是表示项目进度活动之间的逻辑关系（也叫依赖关系）的图形。
项目进度网络图可手工或借助项目管理软件来绘制，可包括项目的全部细节，也可只列出一项或多项概括性活动。
项目进度网络图应附有简要文字描述，说明活动排序所使用的基本方法。
2.项目文件更新
- 活动属性
- 活动清单
- 假设日志
- 里程碑清单
-
-
定义
- 识别和记录项目活动之间的关系的过程
-
理解
- 确认活动间是否有先后顺序关系，包括跨工作包的活动
- 通过历史记录或者相关标准，确认需要调整的时间量
- 指出这些关系之间是否必须被遵守
-
作用
- 定义工作之间的逻辑顺序，以便在既定的所有项目制约因素下获得最高的效率
-
发生时机
- 在整个项目期间开展
- 瀑布或迭代增量中，调整网络图
- 敏捷中，调整待办列表优先级
-
参与方
- 项目经理主导，项目团队、主题专家开展实质性工作
- 相关方意见可能影响过程结果
-
估算活动持续时间
估算活动持续时间是根据资源估算的结果，估算完成单项活动所需工作时段数的过程。
-
输入
1.项目管理计划
- 进度管理计划
- 范围基准
2.项目文件
- 活动属性
- 活动清单
- 假设日志
- 经验教训登记册
- 里程碑清单
- 项目团队派工单
- 资源分解结构
- 资源日历
- 资源需求
- 风险登记册
3.事业环境因素
4.组织过程资产
-
工具
1.专家判断
2.类比估算
3.参数估算
4.三点估算
5.自上而下估算
6.数据分析
备选方案分析
-
储备分析
储备分析用于确定项目（进度和费用管理）所需的应急储备量和管理储备。
应急储备与"已知 - 未知"风险相关。
管理储备与"未知 - 未知"风险相关。
7.决策
8.会议
-
输出
1.持续时间估算
- 持续时间估算是对完成某项活动、阶段或项目所需的工作时段数的定量评估，其中并不包含任何滞后量，但可指出一定的变动区间。
2.估算依据
-
进度
持续时间估算所需的支持信息的数量和种类，因应用领域而异。不论其详细程度如何，支持性文件都应该清晰、完整地说明持续时间估算是如何得出的。
3.项目文件更新
- 活动属性
- 假设日志
- 经验教训登记册
-
-
定义
- 根据资源估算的结果，估算完成单项活动所需工作时段数的过程
-
理解
- 注意这类情况产生会导致前面的活动处于pending状态，直到后面的活动完成后才能继续完成本项活动
- 仅根据已知条件对单个活动时间估算，不进行调整
-
作用
- 确定完成每个活动所需花费的时间量
-
发生时机
- 在整个项目期间开展
- 随渐进明细，估算会逐渐提高精确度
- 敏捷中，后续迭代规划时任务才能彻底确定，以估算持续时间
-
参与方
- 项目经理组织，项目团队成员和主题专家完成实质性工作
- 其它相关方也可能提出意见
-
制定进度计划
制定进度计划是分析活动顺序、持续时间、资源需求和进度制约因素，创建进度模型，从而落实项目执行和监控的过程。
-
输入
1.项目管理计划
- 进度管理计划
- 范围基准
2.项目文件
- 活动属性
- 活动清单
- 假设日志
- 估算依据
- 持续时间估算
- 经验教训登记册
- 里程碑清单
- 项目进度网络图
- 项目团队派工单
- 资源日历
- 资源需求
- 风险登记册
3.协议
4.事业环境因素
5.组织过程资产
-
工具
1.进度网络分析
- 进度网络分析是创建项目进度模型的一种综合技术：关键路径法；资源优化技术；建模技术；储备分析：当多个路径在同一时间点汇聚或分叉时，评估汇总进度储备的必要性，以减少出现进度落后的可能性；审查网络，看看关键路径是否存在高风险活动或具有较多提前量的活动，是否需要使用进度储备或执行风险应对计划来降低关键路径的风险。
- 进度网络分析是一个反复进行的过程，一致持续到创建出可行的进度模型。
2.关键路径法
-
关键路径法用于在进度模型中估算项目最短工期，确定逻辑网络路径的进度灵活性大小。
在不考虑任何资源限制的情况下（或者说资源限制已经被解除了）
综合应用顺推与逆推
计算出所有活动的最早开始、最早结束、最晚开始和最晚完成日期
-
关键路径：网络图中最长工期的那条路线，决定项目最短的完成时间
在关键路径上的进度活动叫"关键活动"
-
关键路径与次关键路径：关键路径是进度网络图当中总时间最长的那条路径（注意不一定是活动最多的），关键路径上的总浮动时间最少，通常为零。
长度与关键路径最为接近的那条路径称之为次关键路径，网络图中可能有多条次关键路径。如关键路径缩短，或次关键路径延长，那次关键路径就会变成关键路径。两者的长度越是接近，项目的风险就越大。
所以要压缩一个项目的时间不仅仅压缩关键路径就可以解决的，而可能要一并压缩次关键路径。项目经理应该把精力放在关键路径和次关键路径上，以确保项目的完工日期不被拖延。
-
总浮动时间与自由浮动时间：在任一网络路径上，进度活动可以从最早开始日期推迟或延迟的时间，而不至于延误项目完成日期或违反进度制约因素，就是总浮动时间或进度灵活性。
自由浮动时间：不影响后续活动的前提下，可以浮动的时间，可以是一个活动也可以是一个网络路径上某几个活动，但不是整个网络路径，否则就成总浮动时间了。
关键路径的"总浮动时间"为零。
关键路径的总浮动时间为负。说明持续时间和逻辑关系违反了决定最晚结束的强制日期。
关键路径的总浮动时间为正。说明逆推使用的强制日期晚于正推得出的最早结束日期。
3.资源优化
-
资源平衡
为了在资源需求与资源供给之间取得平衡，根据资源制约因素对开始日期和完成日期进行调整的一种技术。手段是利用或者移动资源。
如果共享资源或关键资源只在特定时间可用，数量有限，或被过度分配，如一个资源在同一时段内被分配至两个或多个活动，就需要进行资源平衡。牺牲进度获取资源合理使用。
也可以为保持资源使用量处于均衡水平而进行资源平衡（不要让忙的忙死，闲的闲死）。资源平衡往往导致关键路径改变。而可以用浮动时间平衡资源。如果充分利用闲置资源反而可能提前进度。
在项目进度计划期间，关键路径可能发生变化。
-
资源平滑
对进度模型中的活动进行调整，从而使项目资源需求不超过预定的资源限制的一种技术。手段是利用或者移动活动。
相对于资源平衡而言，资源平滑不会改变项目关键路径，完工日期也不会延迟。
活动只在其自由和总浮动时间内延迟，但资源平滑技术可能无法实现所有资源的优化。
移峰填谷
4.数据分析
- 假设情景分析
- 模拟
5.提前量和滞后量
6.进度压缩
-
赶工
通过增加资源，以最小的成本代价来压缩进度工期的一种技术。如果可以优先赶工胜过快速跟进。
-
快速跟进
将正常情况下按顺序进行的活动或阶段改为至少是部分并行开展。不能追赶错过的里程碑。
7.项目管理信息系统
8.敏捷发布规划
- 敏捷发布规划基于项目路线图和产品发展愿景，提供了高度概括的发布进度时间轴（通常是3到6个月）。
- 敏捷发布规划还确定了发布的迭代或冲刺次数，使产品负责人和团队能够决定需要开发的内容，并基于业务目标、依赖关系和障碍因素确定达到产品放行所需的时间。
- 对客户而言，产品功能就是价值，因此，该时间轴定义了每次迭代结束时交付的功能，提供了更易于理解的项目进度计划，而这些就是客户真正需要的信息。
-
输出
1.进度基准
- 进度基准是经过批准的进度模型，只有通过正式的变更控制程序才能进行变更，用作与实际结果进行比较的依据。
- 经相关方接受和批准，进度基准包含基准开始日期和基准结束日期。
- 在监控过程中，将用实际开始和完成日期与批准的基准日期进行比较，以确定是否存在偏差。进度基准是项目管理计划的组成部分。
2.项目进度计划
- 项目进度计划是进度模型的输出，展示各个活动之间相互管理的活动标注了计划日期、持续时间、里程碑和所需资源等。
- 呈现方式：横道图（甘特图），里程碑图，项目进度网络图。
3.进度数据
- 项目进度模型中的进度数据是用以描述和控制进度计划的信息集合。
- 进度数据至少包括进度里程碑、进度活动、活动属性，以及已知的全部假设条件与制约因素，而所需的其他数据因应用领域而异。
- 进度数据还可包括资源直方图、现金流预测，以及订购与交付进度安排等其他相关信息。
4.项目日历
- 在项目日历中规定可以开展进度活动的可用工作日和工作班次，它把可用于开展进度活动的时间段与不可用的时间段区分开来。
- 在一个进度模型中，可能需要采用不止一个项目日历来编制项目进度计划，因为有些活动需要不同的工作时段。
5.变更请求
6.项目管理计划更新
- 进度管理计划
- 成本基准
7.项目文件更新
- 活动属性
- 假设日志
- 持续时间估算
- 经验教训登记册
- 资源需求
- 风险管理册
-
-
定义
- 分析活动顺序、持续时间、资源需求和进度制约因素，创建进度模型，从而落实项目执行和监控的过程
-
理解
- 模型：把WBS、估算活动持续时间、提前滞后量，通过进度工具（如project）使用选定的进度方法（如关键路径法）填成完整的进度框架（如六格网络图）形成的成果
- 六格网络图经过信息精简，和日期带入，形成进度计划
-
作用
- 为完成项目活动而制定具有计划日期的进度模型
-
发生时机
- 在整个项目期间开展
- 当项目推进、项目管理计划发生变化、风险情况发生变化等情况时，都需要更新进度模型，从而调整进度计划
-
参与方
- 项目经理带领项目团队开展工作
- 主要相关方提供建议和要求
-
控制进度
控制进度是监督项目状态，以更新项目进度和管理进度基准变更的过程。
-
输入
1.项目管理计划
- 进度管理计划
- 进度基准
- 范围基准
- 绩效测量基准
2.项目文件
- 经验教训登记册
- 项目日历
- 项目进度计划
- 资源日历
- 进度数据
3.工作绩效数据
4.组织过程资产
-
工具
1.数据分析
挣值分析
-
迭代燃尽图
用于追踪迭代未完项中尚待完成的工作。
它基于迭代规划中确定的工作，分析与理想燃尽图的偏差。
可使用预测趋势线来预测迭代结束时可能出现的偏差，以及在迭代期间应该采取的合理行动。
在燃尽图中，先用对角线表示理想的燃尽情况，再每天画出实际剩余工作，最后基于剩余工作计算出趋势线以预测完成情况。
绩效审查
趋势分析
偏差分析
假设情景分析
2.关键路径法
3.项目管理信息系统
4.资源优化
5.提前量和滞后量
6.进度压缩
-
输出
1.工作绩效信息
2.进度预测
- 根据已有的信息和知识，对项目未来的情况和事件进行的估算或预计。
- 随着项目执行，应该基于工作绩效信息，更新和重新发布预测。
- 这些信息基于项目的过去绩效，并取决于纠正或预防措施所期望的未来绩效，可能包括挣值绩效指数，以及可能在未来对项目造成影响的进度储备信息。
3.变更请求
4.项目管理计划更新
- 进度管理计划
- 进度基准
- 成本基准
- 绩效测量基准
5.项目文件更新
- 假设日志
- 估算依据
- 经验教训登记册
- 项目进度计划
- 资源日历
- 风险登记册
- 进度数据
-
- 定义
- 监督项目状态，以更新项目进度和管理进度基准变更的过程
- 理解
- 不是所有变化都是变更
- 如果需要变更，需通过整体变更控制
- 填写进展，与基准比对以形成进度绩效，符合条件时提出变更
- 作用
- 监督项目状态，以更新项目进度和管理进度基准变更的过程
- 发生时机
- 在整个项目期间开展
- 参与方
- 项目经理与项目团队一起执行
- PMO及相关职能部门可能提供支持或分担职能
九、项目成本管理
-
生命周期成本
- 生命周期成本：包括了产品建设成本以及项目产品交给客户之后运行过程中的成本等。
- 生命周期成本和价值工程方法：辅助决策，用来降低成本和工期，提升项目可交付成果的质量和性能。
-
全生命周期成本
- 前期成本
- 内部项目：调研、论证、评估等
- 外部项目：投标、竞标等
- 建设成本
- 需求确认、设计、制作、测试、采购、管理等
- 使用成本
- 使用、维护、支持、修理、升级等
- 弃置成本
- 处置等
- 前期成本
-
成本的概念
- 沉没成本。已花费的成本。在决定是否继续一个出了问题的项目时不应该考虑沉没成本。
- 机会成本。如选择另一个项目而放弃这个项目的收益所引发的成本。
- 收益递减率。你投入的东西越多，你从中得到的也就越少。例如，一项任务资源增两倍，也无法在一半时间里完成任务。（三个和尚的故事）
- 折旧。大型资产价值随时间的损失。折旧分两类，直线折旧和加速折旧。直线折旧在税负方面比较不利。
- 价值工程。优化产品和（或）项目管理生命成本、节省时间、增加利润、提高质量等的一种创造性方法。价值工程方法适用新的产品，而价值分析适用老的产品。
- 学习曲线。这个概念认为，随着工人对生产过程中涉及的活动的熟练程度的提高，生产率也会相应也提高。
-
规划成本管理
规划成本管理是确定如何估算、预算、管理、监督和控制项目成本的过程。
-
输入
1.项目章程
2.项目管理计划
- 进度管理计划
- 风险管理计划
3.事业环境因素
4.组织过程资产
-
工具
1.专家判断
2.数据分析
3.会议
-
输出
1.成本管理计划
成本管理计划是项目管理计划的组成部分，描述将如何规划、安排和控制项目成本。成本管理过程及其工具与技术应记录在成本管理计划中。
-
例如，在成本管理计划中规定：
计量单位。精确度。准确度。组织程序链接。控制临界值。
绩效测量规则。
定义WBS中用于绩效测量的控制账户。
确定拟用的EVM技术（如加权里程碑法、固定公式法、完成百分比法等）。
报告格式。
其它细节。
-
-
定义
- 确定如何估算、预算、管理、监督和控制项目成本的过程。
-
理解
- 如何制定任务估算和项目预算？方法、依据、计价单位、精确度
- 监控方式？统计频率、统计形式
- 管控要求？容许偏差、调整方式
-
作用
- 在整个项目期间为如何管理项目成本提供指南和方向
-
发生时机
- 仅开展一次或仅在项目的预定义点开展
- 在项目开始时确定，或在环境发生重大变动（如财务制度调整、出台财务法规）时重新开展
-
参与方
- 项目经理牵头，项目团队参与，主题专家提供指导和帮助
- PMO能够从历史资料、方法论选择与裁剪、文件格式等方面提供支持
-
估算成本
估算成本是对完成项目工作所需资源成本进行近似估算的过程。
-
输入
1.项目管理计划
- 成本管理计划
- 质量管理计划
- 范围基准
2.项目文件
- 经验教训登记册
- 项目进度计划
- 资源需求
- 风险登记册
3.事业环境因素
4.组织过程资产
-
工具
1.专家判断
2.类比估算
3.参数估算
4.自下而上估算
5.三点估算
6.数据分析
备选方案分析
-
储备分析
储备分析用于确定项目（进度和费用管理）所需的应急储备和管理储备。
应急储备与"已知—未知"风险相关。
管理储备与"未知—未知"风险相关。
-
质量成本
与质量有关的质量成本（COQ）包含以下一种或多种成本：预防成本。评估成本。失败成本（内部/外部）。
7.项目管理信息系统
8.决策
- 投票
-
输出
1.成本估算
- 成本估算包括对完成项目工作可能需要的成本、应对已识别风险的应急储备，以及应对计划外工作的管理储备的量化估算。
- 成本估算应覆盖项目所使用的全部资源。
- 如果间接成本也包含在项目估算中，则可在活动层次或更高层次上计列间接成本。
2.估算依据
- 成本估算所需的支持信息的数量和种类，因应用领域而异，不论其详细程度如何，支持性文件都应该清晰、完整地说明成本估算是如何得出的。
3.项目文件更新
- 假设日志
- 经验教训登记册
- 风险登记册
-
-
定义
- 对完成项目工作所需资源成本进行近似估算的过程
-
理解
- 根据活动资源需求和持续时间，估算活动成本
- 也有可能是根据某些约束把预算限制分配到各个活动
- 说明得到结果的方式和估算信心，估算的准确程度可能是渐进明细的
-
作用
- 确定项目所需的资金
-
发生时机
- 根据需求在整个项目期间定期开展
- 至少在项目开始时进行一次
- 变更发生活动变化，或者风险调整时需要重估成本
-
参与方
- 项目经理主导，项目团队和主题专家完成实质性工作
- 供应商为分包部分提供了报价
-
成本估算的准确度
- 成本估算的准确度随着项目进展不断提升。
- 一个项目中可以使用多种估算方式，在不同阶段使用，比如在开始阶段使用类比，在规划阶段使用参数和自下而上，在部分缺乏明确信息的细节使用三点估算。
-
制定预算
制定预算是汇总所有单个活动或工作包的估算成本，建立一个经批准的成本基准的过程。
-
输入
1.项目管理计划
- 成本管理计划
- 资源管理计划
- 范围基准
2.项目文件
- 估算依据
- 成本估算
- 项目进度计划
- 风险登记册
3.商业文件
- 商业论证
- 效益管理计划
4.协议
5.事业环境因素
6.组织过程资产
-
工具
1.专家判断
2.成本汇总
3.数据分析
- 储备分析
4.历史信息审核
有助于进行参数估算或类比估算。
历史信息可包括各种项目特征（参数），它们用于建立数学模型预测项目总成本。
-
类比和参数模型的成本及准确性取决于：
用来建立模型的历史信息准确；
模型中的参数易于量化；
模型可以调整，以便对大项目、小项目和各项目阶段都适用。
5.资金限制平衡
- 应该根据对项目资金的任何限制，来平衡资金支出。
- 可能导致调整工作的进度计划，以平衡资金支出水平。
- 可以通过在项目进度计划中添加强制日期来实现。
6.融资
- 融资是指为项目获取资金。
- 长期的基础设施、工业和公共服务项目通常会寻求外部融资。
- 如果项目使用外部资金，出资实体可能会提出一些必须满足的要求。
-
输出
1.成本基准
- 成本基准是经过批准的、按时间段分配的项目预算，不包括任何管理储备，只有通过正式的变更控制程序才能变更，用作与实际结果进行比较的依据。
- 成本基准是不同进度活动经批准的预算的总和。
2.项目资金需求
- 根据成本基准，确定总资金需求和阶段性（如季度或年度）资金需求。
- 成本基准中既包括预计支出及预计债务。
- 总资金需求等于成本基准加管理储备。
3.项目项目文件更新
- 成本估算
- 项目进度计划
- 风险登记册
-
-
定义
- 汇总所有单个活动或工作包的估算成本，建立一个经批准的成本基准的过程
-
理解
- 把单个活动的估算，汇集成整体项目估算
- 添加活动水平以上的储备，并根据预算约束调整整体估算
- 除了制定成本基准，还要考虑管理储备金，以备超支时资金断链
-
作用
- 确定可据以监督和控制项目绩效的成本基准
-
发生时机
- 仅开展一次或仅在项目的预定义点开展
- 项目开始时制定一次成本基准；发生责任团队传递时可能要重订成本基准；风险评审基准和储备
-
参与方
- 项目经理主导，项目团队、主题专家参与
- 供应商、资金渠道等相关方对本过程有重大影响
-
控制成本
控制成本是监督项目状态，以更新项目成本和管理成本基准变更的过程。
-
输入
1.项目管理计划
- 成本管理计划
- 成本基准
- 绩效测量基准
2.项目文件
- 经验教训登记册
3.项目资金需求
4.工作绩效数据
5.组织过程资产
-
工具
1.专家判断
2.数据分析
-
挣值分析
PV（Planned Value）：完成计划工作量的预期值；来源：成本基准（WBS，时间计划）
AC（Actual Cost）：所完成工作的实际支出成本；来源：实际统计
EV（Earned Value）：实际完成工作量的预期值；来源：已经完成的工作原计划的预算
BAC（Budget cost at completion）：项目的总计划价值，完工预算
-
偏差分析
偏差分析审查目标绩效与实际绩效之间的差异（或偏差），可涉及持续时间估算、成本估算、资源使用、资源费率、技术绩效和其他测量指标。
偏差分析用于将基准与实际结果进行比较，以确定偏差是否处于临界值区间内或是否有必要采取纠正或预防措施。
趋势分析
储备分析
3.完工尚需绩效指数
- 完工尚需绩效指标（TCPI）
- 是一种为了实现特定的管理目标，剩余资源的使用必须达到的成本绩效指标，是完成剩余工作所需的成本与剩余预算之比。
- 大于1.0=预计难以完成；等于1.0=预计正好完成；小于1.0=预计轻易完成。
4.项目管理信息系统
-
-
输出
1.工作绩效信息
2.成本预测
3.变更请求
4.项目管理计划更新
- 成本管理计划
- 成本基准
- 绩效测量基准
5.项目文件更新
- 假设日志
- 估算依据
- 成本估算
- 经验教训登记册
- 风险登记册
-
十、敏捷专题
-
敏捷是什么
- 敏捷不是一个流程或者方法
- 敏捷不是一套固定模板
- 敏捷不是一种可以直接重用的方法
- 敏捷是一种为了适应不断变化的需求，以人为核心，通过迭代增量等方式的开发方法。其本质是一种实践。
-
敏捷的三根支柱
敏捷是基于经验型的方法，并不依赖于预测，其成功依赖于三根支柱：
- 透明性：信息透明
- 经常性检查：获得反馈（短反馈）
- 适应：根据反馈快速调整并作出改变
-
瀑布 VS 敏捷
传统项目管理 敏捷项目管理 流程 顺序、线性 迭代、并行 需求与范围 相对明确 随时变化 计划 完善的计划 渐进明细 流程文档 详尽的 足够的 交付 一次性交付 持续性交付 管理风格 领导式 仆人式 -
敏捷软件开发宣言
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：
个体和互动 高于 流程和工具
可用的软件 高于 详尽的文档
客户合作 高于 合作谈判
响应变化 高于 遵循计划
也就是说，尽管右项有其价值，我们更重视左项的价值。
-
敏捷原则
1.我们最重要的目标，是通过持续不断地尽早交付有价值的软件使客户满意。
2.欣然面对需求变更，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌握变化。
3.经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
4.业务人员和开发人员必须相互合作，一起工作，项目中的每一天都不例外。
5.激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
6.不论团队内外，传递消息效果最好效率也最高的方式是面对面的交谈。
7.可工作的软件是进度的首要度量标准。
8.敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
9.坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
10.以简洁为本，它是极力减少不必要工作量的艺术。
11.最好的架构、需求和设计出自自组织团队。
12.团队定期地反思如何能提高成效，并依次调整自身的举止表现。
-
Minimally Marketable Feature（可以解耦）
- Minimally：Requires a mutual agreement of DoD
- Feature: Something that is perceived as value by user
- Marketable: Provides singnificant value to the customer
-
客户价值排序
-
Simple Scheme
- 简单优先级排序 -- 直接设定优先级，比如优先级 1, 2, 3
- 前提：对每个优先级的定义明确的优先级说明与定义，否则会出现全部是高优先级的列表
-
MoSCoW 方法（从客观角度分析需求）
- Must Have：必须有，基础性功能，缺少会让系统不可用/无价值
- Should Have：应该有，重要功能， 使系统可以正常使用；如果缺乏会导致系统使用成本过高
- Could Have：可以有，系统增值功能
- Would Have But Not This Time：这次没有，其实是永远都没有
-
100 - Point Method
经常用在用例（User Case）为代表的功能排序
-
做法：
1.每个干系人分配100点
2.用100点对其认为重要的功能投票
3.100点可以任意使用，不做任何限制
-
Kano 分析（从主观角度分析需求）
-
Kano 模型定义了三个层次的需求
1.基本型需求（基本因素）
2.期望型需求（绩效因素）
3.兴奋型需求（激励因素）
这是一种对客户需求和绩效指标分类的定性分析模型
理解客户需求和满意度的关系，有助于建立提高客户满意度的发布计划
-
-
-
风险管理
- 同 PMBOK 对风险的管理
- 将风险事项当作需求（负向价值需求），将可以主动应对的风险与正常需求同时进行排序
- 风险处理顺序
- 高风险高价值：优先处理
- 低风险高价值：其次处理
- 低风险低价值：最后处理
- 高风险低价值：不予处理
-
打造敏捷团队
自组织团队 -- 建立自组织团队：
- 敏捷特征适合建立自组织团队
- 目标明确
- 共同达到目标
- 每个人天赋容易被激发
- 作法
- 忘记 Title，接受 Role
- 给予明确目标
- 反馈机制
- 团队协作
- 授权：计划、估算、对项目全权负责
- 提升团队主观能动性
自组织团队 -- 特征：
- 分散式管理，扁平化组织
- 自适应，不断适应改变的环境，自我调整
- 面对面沟通
- 反馈环
- 具有弹性
自组织团队 -- 环境因素影响：
- 信息：提供数据的团队，其成员需要胜任计划和执行的工作
- 基础设备：合适的物理空间、技术设备和金钱
- 教育：团队需要培训、教练和技术支援
- 奖励：以正向反馈刺激团队
自组织团队 -- 规模：
- 5 ~ 9 人：规模小到足够敏捷，同时大到能完成复杂工作
- 少于 3 个人：团队交互较少，生产力增长有限，且会受限于人员技能限制，导致无法正常交付增量产品
- 大于 9 人：沟通途径（n*(n-1)/2）过大，沟通成本过高
- 产品负责人和敏捷教练不在人数内
分布式团队：
- 在全球化的环境，很多项目都存在于文化多样性的环境中。理解并利用文化差异，了解各自的沟通偏好和风格，更有可能创建一个互相信任和共赢的氛围
- 非常有效的一个方式是组织面对面的 kick-of meeting，甚至有条件的话包括 kick-off events（如每个迭代开始时）
- 安排地理上分散的团队在早期在一起工作，有利于后期的有效沟通
- 敏捷特征适合建立自组织团队
-
适应性计划
适应性计划的必要性：
- 项目的不确定性
- 敏捷项目是以价值为驱动
- 风险需要降低
- 环境不断的变化：市场、技术、外部因素
敏捷计划 VS 瀑布计划：
- 敏捷关注真实需求，体现出渐进明细
- 敏捷计划关注于整个项目生命周期
- 敏捷计划需要及时对中期计划进行调整
敏捷计划层次 - 敏捷愿景（全生命周期）
敏捷计划层次 - 产品路线图（1 年）：
- 定义：产品负责人拥有，是产品需求高层次概述，常用作特性优先级排序、特性归类和粗略时间框架确定的工具。
敏捷计划层次 - 发布（6 个月）：
- 定义：发布计划是一个高层级计划，通常覆盖 3 ~ 9 个月，帮助客户和敏捷团队决定每个项目的时间范围或者每个阶段内的工作内容。
-
发布计划随着开发的进行不断调整
- 工作内容
- 时间
-
注意点：
- 先规划几个迭代 -- 不做过多预言性工作
- 不涉及资源调整，只关注实际资源
敏捷计划层次 - 迭代（2 ~ 4 周）
定义：与发布计划很类似，但时间更短，可以看作是发布计划在某个迭代中的细化
迭代计划聚焦于：本次迭代的故事的详细任务以及任务下发
-
计划方式：
- 基于迭代速度
- 基于团队承诺
-
基于迭代速度
1.调整用户故事优先级：Product Backlog
2.预测迭代速度
3.识别迭代目标
4.选择用户故事 -- 与迭代目标一致
5.拆分用户故事为任务
6.估算任务
-
基于团队承诺
1.调整用户故事优先级：Product Backlog
2.识别迭代目标
3.通过优先级，针对某个 User Story 进行承诺，在本迭代中团队是否可以完成，若可以完成，则将 User Story 纳入本次迭代计划；否则换一个更小的 User Story 重复上述工作
4.重复上述工作，知道团队不可用再承诺任何 User Story
-
敏捷计划的工具
- 时间盒
- 渐进明细
- 最小可售功能（MMF）
- 最小可用产品（MVP）
- 基于价值的分析
- 定义愿景
-
用户故事（User Story）
- 用户故事是由 Product Owner 编写的，描述对用户有价值的功能。
- 三要素
- 角色：谁
- 功能：要什么
- 价值：为什么要
-
Scrum
Scrum 是一种基于迭代的敏捷方式，有固定的交付周期和迭代周期。
Scrum 角色：Product Owner、Scrum Master、Development Team。
-
Product Owner
- 对 Product Backlog 负责（交付价值）
- 创建产品条目
- 对产品条目进行排序
- 澄清需求
-
Scrum Master
- 对过程负责（不对解决方案负责，也不对人负责）
- 确保 Scrum 被正确理解及贯彻
- 教练以及问题解决
- 清除障碍
- 保护团队
- 促进各项活动开展
-
Development Team
- 完成 Sprint Backlog
- 自组织
- 估算
- 更新信息发射源
- 报告
- ETC
-
KANBAN
KANBAN 采用精益的理念，目的是消除浪费，提高效率。
KANBAN 是一种基于流的敏捷方式，没有固定的交付周期和迭代周期，即来即做，即做即走，可以提高交付频率和交付效率。需要不断找出并解决瓶颈（短板）。
-
KANBAN 的原则
- 可视化工作流
- 限制在制品数量
- 管理工作流
- 保证流程规范清楚明确
- 加强合作
-
Scrum VS Kanban
Scrum Kanban 设置时间盒 时间盒是可选的 团队预先选择每个冲刺的工作 预先选择工作是可选的 Cross-Function Team 除了 Cross-Function，专家团队也是可选的 间接限制 WIP（时间盒） 直接限制 WIP（时间盒） 必须要有估算（不用精确） 估算是可选的 每个 Sprint 中不能改变工作 随时可以增加工作量，只要容量允许（WIP 限定） 一个 Sprint Backlog 由一个研发 Team 负责 一个 Kanban 可以由多个 Team 分享 Scrum board 会在每个冲刺之间重置 Kanban board 是可选的 - WIP：work in progress，半成品。
-
极限编程（EXtreme Programming）
- XP，我们一般称为极限编程，是最轻量级的开发流程。
- 最主要的精神是：在客户有系统需求时，给予及时满意的可执行程序，所以最适合需求快速变动的项目。
- 它强调：客户所要的是 workable 的执行代码，所以把与撰写程序无关的工作降至最低，并要求客户与开发人员最好以 side-by-side 的方式一起工作。
