2.6.2.1 需求

大部分项目工作都与沟通参与(特别是与使项目团队成员和其他干系人始终参与相关的工作)息息相关。如干系人绩效域所述,除了需要进行口头和书面沟通外,沟通还涉及正式和非正式沟通。可以在会议、对话中以及通过从电子存储库中提取信息的方式,来收集信息。一旦收集完毕,信息就会按照项目管理沟通计划的说明进行分发。
在日常工作中,有人会提出特别沟通请求,要求提供信息、演示文稿、报告和其他形式的材料。大量特别沟通请求可能表明,沟通规划不足以满足干系人的需要。在这种情况下,可能需要干系人进一步参与,以确保满足干系人的信息需求
引用
2.3.2 提出目标和反馈
具有此职能的人员提供客户和最终用户的观点、见解和清晰指导。客户和最终用户并非总是同义词。本标准对客户的定义是:提出项目申请或提供项目资金的个人或群体。最终用户是将直接使用项目可交付物的个人或群体。
项目需要客户和最终用户就项目需求、成果和期望作出明确指导。在适应型和混合型项目环境中,项目更需要获得持续反馈,因为项目团队正在探索和开发特定增量中的产品要素。在某些项目环境中,客户或最终用户会参与到项目团队,以便进行定期审查和反馈。在某些项目中,客户代表会加入项目团队的工作。对客户和最终用户意见和反馈的需要取决于项目性质以及所需的指导或指引。
2.3.6 提供业务方向和洞察
具有此职能的人员会指导并澄清项目方向或产品成果。它涉及根据商业价值、依赖关系以及技术或运营风险来确定需求或待办事项的优先级。具有此职能的人员向项目团队提供反馈,并为要开发或交付的下一个增量或要素设定方向。此职能涉及与其他干系人、客户及其项目团队互动,以定义产品方向。其目标是使项目可交付物的价值最大化。
在适应型和混合型环境中,可以使用特定的节奏提供方向和洞察。在预测型环境中,可以设定指定的检查点来呈现项目进展并提供有关项目进展的反馈。在某些情况下,业务方向可以与资金提供职能和资源提供职能相互影响。
3.1 成为勤勉、尊重和关心他人的管家

图 3-2. 成为勤勉、尊重和关心他人的管家
在不同的环境中,管家式管理 (stewardship) 的含义和应用会略有不同。管家式管理一方面涉及被委托看管某项事物,另一方面侧重于以负责任的方式规划、使用和管理资源,还有一方面是维护价值观和道德。
管家式管理包括在组织内部和外部的职责。在组织内,管家式管理包括:
▶ 运营时要做到与组织及其目标、战略、愿景、使命保持一致并维持其长期价值;
▶ 承诺并尊重项目团队成员的参与,包括薪酬、机会获得和公平对待;
▶ 勤于监督项目中使用的组织资金、材料和其他资源;
▶ 了解职权、担责和职责的运用是否适当(特别是身居领导岗位时)。组织外部的管家式管理包括在以下领域的职责:
▶ 环境可持续性以及组织对材料和自然资源的使用;
▶ 组织与外部干系人(例如其合作伙伴和渠道)的关系;
▶ 组织或项目对市场、社会和经营所在地区的影响;
▶ 提升专业化行业的实践水平。
管家式管理反映了对信任的理解和接受度以及产生和维持信任的行动和决定。管家既需遵守明确的职责,也需要遵守隐含的职责。这些职责可能包括以下方面:
▶ 诚信。管家在所有参与和沟通中都应做到诚实且合乎道德。管家需秉持最高标准,并反映组织员工所应坚守的价值观、原则和行为。管家作为楷模,并通过在其参与、工作活动和决策中践行和展现个人和组织价值观来建立信任。在项目管理背景下,这一职责通常要求管家建议团队成员、同职级人员和其他干系人考虑他们的言行、展现同理心、进行自我反思并乐于接受反馈。
▶ 关心。管家是其负责的组织事务的受托人,他们会认真监督这些事务。具有高绩效项目的专业人士总是会在严格规定的责任范围外也这样做。管家需密切关注这些事务,且需达到对个人事务相同的关心程度“关心”涉及与组织内部业务相关的事务。组织政策和原则应反映对环境和自然资源可持续利用的关心以及对全球公众状况的关切。项目带来的变化可能会有意想不到或不想要的后果。项目从业者应识别、分析和管理项目成果的潜在负面影响,以便干系人注意到并告知相关情况。“关心”包括营造透明的工作环境、开放的沟通渠道以及让干系人有机会在不受惩罚或不害怕遭到报复的情况下提出顾虑。
▶ 可信。管家需在组织内外准确地说明自己的身份、角色、所在项目团队及其职权。这种行为使人们能够了解个人在多大程度上可以投入资源、做出决策或批准某件事。可信还要求个人主动识别个人利益与其组织或客户利益之间的冲突。此类冲突可能会削弱信任和信心,导致不道德或非法行为,造成混乱或带来次优的成果。管家需保护项目免受此类失信行为的影响。
▶ 合规。管家需遵守其组织内外得到适当授权的法律、规则、法规和要求。但高绩效项目会寻求通过各种方法将合规性更充分地融入项目文化,从而与可能相互冲突的各种准则更好地保持一致性。
管家需努力遵守旨在保护他们及其组织、干系人和广大公众的准则。如果管家在行动或计划是否符合既定准则方面遇到了相互冲突的准则或问题,他们需要寻求适当的建议和指导。管家式管理需要以透明且可信赖的方式进行领导。项目会影响到交付项目的人员以及受项目可交付物和成果影响的人员的生活。项目可以产生某些效果,例如缓解交通堵塞、生产新药物或为人们创造互动机会。这些效果可能会产生负面的影响和后果,例如绿地减少、药物副作用或个人信息泄露。项目团队及其所在组织的领导应仔细考虑这些因素和影响,以便他们可以通过权衡组织和项目目标与全球干系人更大的需求和期望来做出负责任的决定。
越来越多的组织从整体角度看待业务,它们会同时而不是按顺序考虑财务、技术、社会和环境绩效。由于世界现在比以往任何时候都更加相互关联,而且面临有限的资源和共同的环境,因此管家式管理的决策会有超出项目之外的影响。
3.3 有效地干系人参与

图 3-4. 有效地干系人参与
干系人可能是能影响项目组合、项目集或项目的决策、活动或成果的个人、群体或组织,以及会受或自认为会受这些决策、活动或成果影响的个人、群体或组织。干系人还以积极或消极的方式直接或间接影响项目,及其绩效或成果。
干系人可以影响项目的许多方面,包括,但不限于:
▶ 范围 / 需求 — 通过表明需要增加、调整或删除范围和/或项目需求的要素;
▶ 进度 — 通过提出加快交付的想法,或者放慢或停止交付关键项目活动;
▶ 成本 — 通过帮助减少或取消计划支出,或者增加会提高成本或需要额外资源的步骤、需求或限制;
▶ 项目团队 — 通过限制或允许接触具备交付预期成果所需技能、知识和经验并可推动学习型文化的人员;
▶ 计划 — 通过为计划提供信息,或倡导对商定的活动和工作作出变更;
▶ 成果 — 通过开展或阻止实现为期望成果所需的工作;
▶ 文化 — 通过建立或影响甚至定义项目团队和更广泛组织参与的程度和特点;
▶ 收益实现 — 通过制定和确定长期目标,从而使项目交付预期的确定价值;
▶ 风险 — 通过界定项目的风险临界值,并参与后续的风险管理活动;
▶ 质量 — 通过识别和要求提供质量需求;
▶ 成功 — 通过定义成功因素并参与对成功的评估。
在项目的整个生命周期内,干系人可能会参与进来,也可能会退出。此外,随着时间的推移,干系人的利益、影响或作用可能也会有所变化。干系人(特别是那些影响力高且对项目持不赞同或中立观点的干系人)
需要有效地参与进来,以便项目团队了解他们的利益、顾虑和权利。然后,项目团队可以通过有效参与和支持来应对这些顾虑,这样就可能会成功地实现项目成果。
从项目开始到结束,识别、分析并主动争取干系人参与有助于项目取得成功。
项目团队是一组干系人。这些干系人会与其他干系人互动,以理解、思考、沟通并回应他们的利益、需要和意见。
有效果且有效率的参与和沟通包括确定干系人想要或应该进行参与的方式、时间、频率和情形。沟通是参与的关键部分,但深入的参与可让人了解他人的想法,吸收其他观点以及协同努力制定共同的解决方案。参与包括通过频繁的双向沟通建立和维持牢固的关系。它鼓励通过互动会议、面对面会议、非正式对话和知识共享活动进行协作。
干系人参与在很大程度上依赖于人际关系技能,包括积极主动、正直、诚实、协作、尊重、同理心和信心。这些技能和态度可以帮助每个人适应工作和彼此适应,从而增加成功的可能性。
参与有助于项目团队发现、收集和评估信息、数据和意见。这可形成共识和一致性,从而实现项目成果。此外,这些活动还有助于项目团队对项目进行裁剪,以识别、调整和应对不断变化的环境。
在整个项目进行期间,项目团队会积极让其他干系人参与,以最小化潜在消极影响并最大化积极影响。除了提高干系人满意度外,让干系人参与还使项目团队有机会取得更出色的项目绩效和成果。最后,其他干系人的参与有助于项目团队找到更能为更广泛的干系人接受的解决方案。
3.4 聚焦于价值

图 3-5. 聚焦于价值
价值(包括从客户或最终用户的角度看的成果)是项目的最终成功指标和驱动因素。价值聚焦于可交付物的成果。项目的价值可以表示为对发起组织或接收组织的财务贡献。价值也可以是对所取得的公共利益的测量,例如,社会收益或客户从项目结果中所感知到的收益。当项目是项目集的组件时,项目对项目集成果的贡献可以表示为价值。
许多项目(尽管不是所有项目)都是基于商业论证而启动。也可能由于任何确定的交付需要,或者修改流程、产品或服务(如合同、工作说明书或其他文件)的需要而启动项目。在所有情况下,项目的目的就是提供预期成果,该成果通过有价值的解决方案满足需要。商业论证可以包含有关战略一致性、风险敞口评估、经济可行性研究、投资回报率、预期关键绩效测量、评估和替代方法的信息。商业论证可以从定性或定量的方面,或者同时从这两方面来说明项目成果的预期价值贡献。商业论证至少包含以下支持性和相互关联的要素:
▶ 商业需要。商业为项目提供理由,并解释为什么开展该项目。它源于初步的业务需求,这些需求反映在项目章程或其他授权文件中。商业需要提供了有关商业目的和目标的详细信息,它可能针对执行组织、客户组织、组织的合伙方或公共福利。明确说明商业需要有助于项目团队了解未来状态的商业驱动因素,并使项目团队能够识别机会或问题,从而提高项目成果的潜在价值。
▶ 项目理由。项目理由与商业需要相关。它解释了为什么商业需要值得投资以及为什么在此时应该满足商业需要。项目理由会附有成本效益分析和假设条件。
▶ 商业战略。商业战略是开展项目的原因,所有需要都与实现价值的战略相关。
除了收益和可能的协议之外,商业需要、项目理由和商业战略一起为项目团队提供信息,使他们能够做出知情决策,以达到或超过预期的商业价值。
在整个项目期间,应清晰描述、以迭代方式评估并更新期望成果。在项目生命周期内,项目可能会发生变更,然后项目团队会作出应对调整。项目团队会根据期望的输出、基准和商业论证不断评估项目进展情况和方向,以确定该项目仍与商业需要保持一致,并将交付预期成果。另外,干系人可以更新商业论证以获取机会,或者将项目团队和其他干系人确定的问题最小化。如果项目或其干系人不再与商业需要保持一致,或者如果项目似乎不可能提供预期价值,则组织可以选择终止此项投入。
价值是指某种事物的作用、重要性或实用性。价值具有主观性,从某种意义上说,同一个概念对于不同的人和组织具有不同的价值。之所以会发生这种情况,是因为所谓的收益取决于组织战略,包含从短期财务收益、到长期收益、甚至是非财务要素。由于所有项目都有一系列干系人,因此必须考虑为每个干系人群体产生的不同价值,并将这些价值与整体价值进行平衡,同时优先考虑客户价值。
在某些项目的背景下,可能存在不同形式的价值工程,这些价值工程可以将客户、执行组织或其他干系人的价值最大化。这方面的一个示例包括在可接受的风险敞口的情况下交付所需的功能和质量水平,同时尽可能少地使用资源,并避免浪费。有时,特别是在没有预先确定范围的适应型项目中,项目团队可以与客户共同努力,确定哪些功能值得投资,哪些功能可能缺乏足够的价值,无需增加到输出之中,从而优化价值。
为了支持从项目中实现价值,项目团队可将重点从可交付物转到预期成果。这样做可以让项目团队实现项目的愿景或目标,而不是简单地创建特定可交付物。虽然可交付物可能会支持预期的项目成果,但它可能无法完全实现项目的愿景或目标。例如,客户可能需要某一特定的软件解决方案,因为他们认为该解决方案可以满足提高生产力这一商业需要。软件是项目的输出,但软件本身并不能实现预期的生产力成果。在这种情况下,增加一项新的可交付物,即提供使用软件的培训和教练,就可以实现更好的生产力成果。如果项目的输出未能提高生产力,干系人可能会认为项目已经失败。因此,项目团队和其他干系人都应该了解可交付物及其预期成果。
项目工作的价值贡献可能是一种短期或长期的测量。由于价值贡献可能与运营活动的贡献相混合,因此很难将其分开。当项目是项目集的一个组件时,也可能需要在项目集层级对价值作出评估,以便以适当的方式对项目进行指导。可靠的价值评估应考虑项目输出的全部背景和整个生命周期。虽然价值会随着时间的推移而实现,但有效的过程可以帮助早日实现收益。通过有效率且有效果地实施项目,项目团队可以展示或实现诸如优先交付、更好的客户服务或改善工作环境等成果。通过与负责将项目可交付物投入使用的组织领导者合作,项目领导者可以确保可交付物能够实现所计划的成果。
3.5 识别、评估和响应系统交互
项目生命周期项目阶段的类型和数量取决于许多变量,其中主要是交付节奏和开发方法(如上所述)。生命周期中阶段的示例包括:
可行性阶段。此阶段会确定商业论证是否有效以及组织是否有能力交付预期成果。
设计阶段。通过规划和分析,可以设计将要开发的项目可交付物。
构建阶段。通过整合的质量保证活动实施构建可交付物。
测试阶段。在移交、上线或客户验收之前,会对可交付物进行最终质量审查和检查。
部署阶段。项目可交付物投入使用,而且持续稳定、实现收益和组织变革管理所需的移交活动均已完成。
收尾阶段。项目收尾了,要存档项目知识和工件,解散项目团队成员,并关闭合同。
项目阶段通常设有阶段关口,以便在进入下一阶段之前检查是否已达到预期成果或满足当前阶段的退出标准。退出标准可能与可交付物、合同义务、满足特定绩效目标或其他有形措施的验收标准密切相关。
图 2-9 显示了各个阶段依次完成的生命周期。这种类型的生命周期与预测型开发方法非常匹配,因为每个阶段只进行一次,每个阶段都侧重于某一特定类型的工作。但有些情况(例如增加范围、需求变化或市场变化)则会导致某些阶段重复进行。

图 2-9. 预测型生命周期示例
图 2-10 显示了一个采用增量型开发方法的生命周期。本示例中显示了由计划、设计和构建组成的三次迭代。每个后续的构建都将在初始构建上增加功能。

图 2-10. 采用增量型开发方法的生命周期
图 2-11 显示了一个采用适应型开发方法的生命周期。在每次迭代(有时称为“冲刺”)结束时,客户会对具有功能性的可交付物进行审查。在审查时,关键干系人会提供反馈,项目团队会更新项目待办事项列表,以确定下一次迭代中特性和功能的优先级。

图 2-11. 采用适应型开发方法的生命周期
可对此方法做出调整,以便在持续交付情况下使用此方法,具体如第 2.3.2 节(交付节奏)所述。
有几种适应型方法论(包括敏捷方法)会进行基于工作流的进度规划,这种进度规划不会采用生命周期或阶段的概念。此举的一个目标是根据资源能力、材料和其他输入优化交付流程。另一个目标是最大限度地减少时间和资源浪费,并优化过程效率和可交付物的产出量。采用这些实践和方法的项目通常采用在精益和准时制(JIT)中使用的看板进度规划系统。
3.11 拥抱适应性和韧性

图 3-12. 拥抱适应性和韧性
大多数项目在某个阶段都会遇到挑战或障碍。如果项目团队开展项目的方法同时具备适应性和韧性,则有助于项目适应各种影响并蓬勃发展。适应性是指应对不断变化的情形的能力。韧性由两个具有互补性的特质组成:吸收冲击的能力和从挫折或失败中快速恢复的能力。适应性和韧性是任何开展项目的人员应具备的有益特征。
项目很少会按最初的计划执行。项目会受到内部和外部因素(新需求、问题、干系人影响等因素)影响,这些因素存在于一个有各种相互作用的系统中。项目中的某些要素可能会失败或达不到预期,这需要项目团队重新组合、重新思考和重新规划。例如,在基础设施项目中,法院在项目执行期间的裁决可能会导致设计和计划的变更。在技术项目中,技术方面的电脑化模型可能会显示各个组件可以正常协同工作,但它们在实际应用时却发生故障。在这两个案例中,项目团队都需要应对此情形,以便推进项目。有一种观点认为,项目应严格遵守早期阶段的计划和承诺,即使在出现新的或不可预见的因素之后亦是如此。这种观点对包括客户和最终用户在内的干系人是没有益处的,因为这束缚了产生价值的可能性。但是,应该从整体的角度做到适应性,例如应采用适当的变更控制过程,以避免诸如范围蔓延等问题。在项目环境中,支持适应性和韧性的能力包括:
▶ 较短的反馈循环,以便快速适应;
▶ 持续学习和改进;
▶ 拥有宽泛技能组合的项目团队,同时还有在每个所需技能领域具有广博知识的个人;
▶ 定期检查和调整项目工作,以识别改进机会;
▶ 多样化的项目团队,以获得广泛的经验;
▶ 开放和透明的规划,让内部和外部干系人参与;
▶ 小规模的原型法和实验,以测试想法和尝试新方法;
▶ 充分运用新的思考方式和工作方式的能力;
▶ 平衡工作速度和需求稳定性的过程设计;
▶ 组织的开放式对话;
▶ 具有宽泛的技能组合、文化和经验的多样性项目团队,同时还有各个所需技能领域的主题专家;
▶ 对过去相同或类似工作中所获学习成果的理解力;
▶ 预测多种潜在情景,并为多种可能的情况做好准备的能力和意愿;
▶ 将决策推迟到最后责任时刻;
▶ 管理层支持;
▶ 平衡速度和稳定性的开放式设计。
预期的成果而非可交付物能够促成解决方案,进而可利用比原始计划更好的结果。例如,项目团队可找到替代解决方案,以提供比原始定义的可交付物更优的成果。虽然探寻替代方案通常属于商业论证的范畴,但技术和其他能力的演变非常快,以至于在商业论证完成和项目收尾之间的任何时候都可能会出现解决方案。项目期间可能会出现适应项目的机会,届时项目团队应向项目发起人、产品负责人或客户说明为何要抓住这一机会。根据合同类型,因适应项目而进行的某些变更可能需要客户批准。在项目发起人、产品负责人或客户的支持下,项目团队应准备好调整其计划和活动以利用这一机会。
项目系统中的意外变更和情况也可能会带来机会。为了优化价值交付,项目团队应该针对变更和计划外事件运用问题解决和整体思维方法。发生计划外事件时,项目团队应寻找可能获得的潜在积极成果。
例如,将项目时间线后期发生的变更包含进来,这样就可以成为市场上第一个提供该功能的产品,从而增加竞争优势。
在项目中保持适应性和韧性,可使项目团队在内部和外部因素发生变化时聚焦于期望成果,这有助于他们从挫折中恢复过来。这些特征还有助于项目团队学习和改进,以便他们能够从失败或挫折中快速恢复,并继续在交付价值方面取得进展。
2.1.1.4 参与
干系人参与需要与干系人协作以介绍项目,启发他们的需求,管理期望、解决问题、谈判、优先级排序、处理难题,并做出决策。争取干系人参与需要运用软技能,如积极倾听、人际关系技能和冲突管理,以及创建愿景和批判性思维等领导技能。
与干系人的沟通可以通过书面或口头方式进行,可以是正式的,也可以是非正式的。表 2-1 中列出了每种沟通类型的示例。
表 2-1. 沟通类型

沟通方法包括推式沟通、拉式沟通和交互式沟通:
▶ 推式沟通。发送给干系人的沟通信息,如备忘录、电子邮件、状态报告、语音邮件等。推式沟通可用于与单个干系人或一组干系人进行单向沟通。推式沟通会妨碍立即判定反应和评估理解情况的能力,因此,应该谨慎使用推式沟通。
▶ 拉式沟通。干系人所寻求的信息,例如,项目团队成员在内部网中查找沟通政策或模板、运行互联网搜索和使用在线存储库。拉式沟通可用于间接察觉干系人的顾虑。
参与比推式沟通或拉式沟通更深入。参与是交互式沟通。它包括与一个或多个干系人交换信息,例如对话、电话、会议、头脑风暴和产品演示等。
通过各种形式的沟通,快速反馈循环可提供有用信息,以便:
▶ 确认干系人获知该消息的程度。
▶ 确定干系人是否同意该消息。
▶ 识别接收方发现的具有细微差别或其他非预期的消息。
▶ 获得其他有用的洞察。
2.1.2 与其他绩效域的相互作用
干系人渗透到项目的各个方面。他们会为项目团队定义需求和范围,并对其进行优先级排序。他们会参与并制定规划。他们会确定项目可交付物和项目成果的验收和质量标准。大部分的项目工作都围绕着争取干系人参与以及与干系人进行沟通而展开。在整个项目过程中或在项目结束时,他们会使用项目可交付物并影响项目成果的实现。
某些干系人可以帮助减少项目中存在的不确定性的数量,而其他干系人则可能导致不确定性增加。客户、高层管理人员、项目管理办公室领导或项目集经理等干系人将重点关注项目及其可交付物绩效的测量。这些相互作用只是干系人绩效域如何与其他绩效域整合和交织的示例,它们并不包含所有绩效域中对干系人考虑相互作用的全部方式。
2.2.1.2 分布式管理和领导力
有时项目管理活动由项目管理团队所有成员共同实施,而项目团队成员则负责完成工作。还有一些情况下,项目团队可能会通过自组织来完成项目。在这些情况下,不会指定项目经理,而是让项目团队中的某个人充当促进沟通、协作和参与的引导者。此角色可能会由项目团队成员轮流担任。
服务型领导力(Servant leadership)这种领导风格聚焦于了解并满足团队成员的需要及其发展情况,以便尽可能促成最高的项目团队绩效。服务型领导者强调通过聚焦于解决以下问题来培养项目团队成员,使其发挥最大潜能:
▶ 项目团队成员个人是否在成长?
▶ 项目团队成员是否在变得更健康、更明智、更自由、更自主?
▶ 项目团队成员是否更有可能成为服务型领导者?
服务型领导者使项目团队在可能的情况下进行自组织,并通过向项目团队成员提供适当的决策机会来提高自主性。服务型领导力行为包括:
▶ 消除障碍。由于是项目团队创造了大部分商业价值,因此,服务型领导者的关键角色是通过消除进展中的障碍因素来最大化地交付商业价值。这包括解决问题和消除可能妨碍项目团队工作的障碍。通过解决或缓解这些障碍因素,项目团队可以更快地向企业交付价值。
▶ 避免分心。服务型领导者会使项目团队免受内部和外部分心之事影响,这些分心之事会使项目团队偏离当前目标,时间碎片化会降低生产率,因此使项目团队免受非关键外部需求影响有助于项目团队保持专注。
▶ 鼓励和发展机会。服务型领导者还提供相关工具和鼓励,让项目团队保持满意度且工作富有成效。
了解激励项目团队成员个人的因素,并想方设法奖励他们的出色工作,这有助于使项目团队成员保持满意。
2.3.4.1 产品、服务或结果
与产品、服务或结果的性质相关的许多变量会影响开发方法。以下列表概述了在选择开发方法时要考虑的一些变量。
▶ 创新程度。在充分了解范围和需求的情况下,项目团队以前曾完成的工作且能够提前规划的可交付物非常适合采用预测型方法。创新程度高或项目团队没有做过的可交付物更适合采用更多适应性的方法。
▶ 需求确定性。当需求变得众所周知且易于定义时,预测型方法非常适合。而当需求不确定、易变或复杂且预期在整个项目期间会发生演变时,更具有适应性的方法可能更适合。
▶ 范围稳定性。如果可交付物的范围稳定且不可能发生变化,则预测型方法非常有用。如果范围预期会有许多变更,开发方法频谱图上更靠近适应型方法这一端的会很有用。
▶ 变更的难易程度。这与需求确定性和范围稳定性相关。如果可交付物的性质使得管理和合并变更较为困难,那么预测型方法就是最佳的。对于容易适应变更的可交付物,可以采用更具适应性的方法。
▶ 交付选项方案。如第 2.3.2 节(“交付节奏”)中所述,可交付物的性质以及能否以组件形式交付将影响开发方法。可以分组块开发和/或交付的产品、服务或结果选用增量型方法、迭代型方法或适应型方法皆可。有些大型项目可以采用预测型方法进行规划,但其中有些组块可以增量型开发和交付。
▶ 风险。存在固有高风险的产品需要在选择开发方法之前进行分析。某些高风险产品可能需要大量前期规划和严格的流程减少威胁。基于学习利用新出现的机会或减少威胁的敞口,其他产品可以通过模块化构建,以及调整设计和开发来减轻风险。
▶ 安全需求。具有严格安全需求的产品通常采用预测型方法,因为需要进行大量的预先规划,以确保所有安全需求都得到识别、规划、创建、整合和测试。
▶ 法规。对受到严格法规监管的环境,由于有所需的流程、文档和演示的需要,可能要求采用预测型方法。
2.3.5 生命周期和阶段的定义
项目生命周期项目阶段的类型和数量取决于许多变量,其中主要是交付节奏和开发方法(如上所述)。生命周期中阶段的示例包括:
可行性阶段。此阶段会确定商业论证是否有效以及组织是否有能力交付预期成果。
设计阶段。通过规划和分析,可以设计将要开发的项目可交付物。
构建阶段。通过整合的质量保证活动实施构建可交付物。
测试阶段。在移交、上线或客户验收之前,会对可交付物进行最终质量审查和检查。
部署阶段。项目可交付物投入使用,而且持续稳定、实现收益和组织变革管理所需的移交活动均已完成。
收尾阶段。项目收尾了,要存档项目知识和工件,解散项目团队成员,并关闭合同。
项目阶段通常设有阶段关口,以便在进入下一阶段之前检查是否已达到预期成果或满足当前阶段的退出标准。退出标准可能与可交付物、合同义务、满足特定绩效目标或其他有形措施的验收标准密切相关。
图 2-9 显示了各个阶段依次完成的生命周期。这种类型的生命周期与预测型开发方法非常匹配,因为每个阶段只进行一次,每个阶段都侧重于某一特定类型的工作。但有些情况(例如增加范围、需求变化或市场变化)则会导致某些阶段重复进行。

图 2-9. 预测型生命周期示例
图 2-10 显示了一个采用增量型开发方法的生命周期。本示例中显示了由计划、设计和构建组成的三次迭代。每个后续的构建都将在初始构建上增加功能。

图 2-10. 采用增量型开发方法的生命周期
图 2-11 显示了一个采用适应型开发方法的生命周期。在每次迭代(有时称为“冲刺”)结束时,客户会对具有功能性的可交付物进行审查。在审查时,关键干系人会提供反馈,项目团队会更新项目待办事项列表,以确定下一次迭代中特性和功能的优先级。

图 2-11. 采用适应型开发方法的生命周期
可对此方法做出调整,以便在持续交付情况下使用此方法,具体如第 2.3.2 节(交付节奏)所述。
有几种适应型方法论(包括敏捷方法)会进行基于工作流的进度规划,这种进度规划不会采用生命周期或阶段的概念。此举的一个目标是根据资源能力、材料和其他输入优化交付流程。另一个目标是最大限度地减少时间和资源浪费,并优化过程效率和可交付物的产出量。采用这些实践和方法的项目通常采用在精益和准时制(JIT)中使用的看板进度规划系统。
2.3.6 协调交付节奏、开发方法和生命周期
我们将重温第 2.3.3 节中描述的社区中心示例,以揭示交付节奏、开发方法和生命周期是如何融合在一起的。在该示例中,共有四种产品和服务:建筑物、社区行动巡查 (CAP) 培训、老年人服务和网站。表 2-4 描述了交付节奏和开发方法。
表 2-4. 交付节奏和开发方法

根据这些信息,潜在的生命周期可能为:
启动阶段。此阶段的进入标准是:商业论证已获批准,而且项目章程已获审批。这一阶段将制定高层级路线图,确定初步的资金需求,定义项目团队和资源需求,制定里程碑进度计划,及采购战略规划。这些可交付物应在退出启动阶段之前完成。退出标准将在初始阶段关口审查会议上进行审查。
规划阶段。在这一阶段,示例中建筑物的高层级信息将被分解为各个详细的计划CAP 培训的详细设计文件将编制完成。并将完成对面向老年人的产品/服务的分析,与差距分析。还将创建网站的初始线框图。这些可交付物应在退出规划阶段之前完成。退出标准将在规划阶段关口审查会议上进行审查。
开发阶段。此阶段将与测试阶段和部署阶段重叠,因为可交付物有着不同的交付节奏和不同的方法。在此将提前交付网站的部分内容,以便向公众通报社区中心的进展情况。一些老年人服务和CAP 培训的活动可能会在社区中心开放之前开始。在进入测试阶段之前,每项可交付物都可能受到单独的审查。
测试阶段。此阶段将与开发阶段和部署阶段重叠。测试的类型取决于可交付物。这一阶段包括对建筑物的检查、对 CAP 课程的测试交付、对老年人服务的小规模试验以及在网站每个版本的测试环境中运行。在进入部署阶段之前,每项可交付物都将经过应用的测试。
部署阶段。此阶段将与开发和测试阶段重叠。网站的首次部署可能在项目早期进行。随着更多可交付物可以使用,此阶段中的活动将重复进行。在社区中心开放运营的时候,项目将进行最终部署。
社区中心开放后,对网站和老年人服务进行持续更新将成为运营活动的一部分。
收尾阶段。随着可交付物的完成,此阶段会定期进行。在初始网站部署后,项目人员(包括承包商)将会被解散,每项可交付物的回顾或经验教训总结也将完成。当整个项目完成时,将获得各个阶段关口审查的信息,并对比基准来完成项目绩效的总体评价。在最终收尾之前,将对项目章程和商业论证进行审查,以确定可交付物是否实现了预期的收益和价值。
图 2-12 显示了社区中心项目可能的生命周期。启动和计划阶段是按顺序进行的。开发、测试和部署这几个阶段可能会相互重叠,因为不同的可交付物将在不同的时间进行开发、测试和部署,而某些可交付物会进行多次交付。该图更详细地展示了开发阶段,以说明不同的时间安排和交付节奏。测试阶段的节奏将遵循开发阶段的节奏。交付将在部署阶段显示。

图 2-12. 社区中心项目生命周期
询问生命周期中各个阶段的名称并非所有项目从业者都能区分清楚开发方法和生命周期。在一些从业者谈到开发方法时,会说一个项目遵循敏捷生命周期。一些从业者将预测型方法称为“瀑布式方法”。适应型开发方法也可称为演进的方法。
由于项目管理在不断发展,因此所用的语言也在不断演变。要想了解某人所指的到底是哪种方法,最好要确定其可交付物的开发方式,并向其询问生命周期中各个阶段的名称。这有助于构建项目框架并了解人们是如何使用术语的。
2.3.7 与其他绩效域的相互作用
开发方法和生命周期绩效域与干系人绩效域、规划绩效域、不确定性绩效域、交付绩效域、项目工作绩效域和团队绩效域相互作用。所选的生命周期会影响进行规划的方式。预测型生命周期会提前进行大部分规划工作,然后继续使用滚动式规划和渐进明细来重新规划。随着威胁和机会的发生,计划也会得到更新。
开发方法和交付节奏是减少项目不确定性的一种方法。如果一个可交付物存在要满足监管要求相关的大量风险,则可能会选择一种预测型方法来增加额外测试、文档编写以及健全的流程和程序。如果一个可交付物存在要与干系人验收相关的大量风险,则可能会选择一种迭代方法,并向市场发布最小可行产品,以便在开发其他特性和功能之前获得反馈。
在考虑交付节奏和开发方法时,开发方法和生命周期绩效域与交付绩效域有很多重叠。交付节奏是确保价值交付与商业论证和收益实现计划保持一致的主要驱动因素之一。启发产品需求并满足交付绩效域所述的质量要求对开发方法有着重大影响。
在项目团队能力和项目团队领导力技能方面,团队绩效域与开发方法和生命周期绩效域会相互作用。项目团队的工作方式和项目经理的风格会因开发方法的不同而有很大差异。采用预测型方法时,通常需要更加重视预先规划、测量和控制。在开发方法频谱图另一端,适应型方法(特别是在使用敏捷方法时)需要更多的服务型领导风格,而且可能会形成自我管理的项目团队。
2.4.2 规划的变量
由于每个项目都是独特的,因此规划的数量、时间安排和频率各不相同。影响项目规划方式的变量包括(但不限于):
开发方法。开发方法会影响如何规划、规划多少及何时实施规划。范例包括:
▹ 生命周期早期进行规划或组织的特定阶段。在这些情况下,大部分规划都是预先进行的。在整个项目期间,最初的计划会渐进明细地制定,但对原来的范围没有什么改变。
▹ 一种预先进行高层级规划的方法,随后是使用原型的设计阶段。在项目团队和干系人对设计表示同意后,项目团队将完成更详细的规划。
▹ 项目团队实施迭代的适应型方法。一些规划会提前进行,以制定发布计划,而进一步的规划会在每个迭代开始时进行。
项目可交付物。通常需要以特定方式规划项目可交付物。建筑项目需要进行大量的前期规划,以便对设计、审批、材料采购、物流和交付做出说明。产品开发或高技术项目可以采用持续性和适应性的规划,以便根据干系人的反馈和技术进步进行演变和变更。
组织需求。组织治理、政策、程序、流程和文化可能会要求项目经理提供特定的规划工件。
市场条件。产品开发项目可能会在竞争激烈的环境中进行。在这种情况下,项目团队可以进行最低限度的前期规划,因为重点是加快投入市场的速度。过量的规划必然造成延迟的成本会超过潜在返工的风险。
法律或法规限制。监管机构或法规可能要求必须先提供特定的规划文件,然后才能得到进行实施的相关授权或者获得批准向市场发布项目可交付物。
2.4.2.3 进度
本节中描述的方法不适合于上述特定类别;但它们是用于项目的多种目的的常用方法。
影响地图。影响地图是一种战略规划方法,在产品开发期间作为组织的可视化路线图。
建模。建模是创建对系统、解决方案或可交付物(例如原型、示意图或故事板)的简化表示法的过程。通过确定信息中的差距、沟通错误的方面或额外需求,建模能有助于进一步分析。
净推荐值 (NPS )。客户将某组织的产品或服务推荐给他人的意愿的一种测量指数。该数值是被用作衡量客户对组织产品或服务的总体满意度,以及客户对品牌的忠诚度的指标。
优先级模型。优先级模型是用于确定项目组合、项目集、项目的组件以及需求、风险、特性或其他产品信息的优先级的方法。例如多标准加权分析和 MoSCoW(“必须有”“应该有”“可以有”和“不会有”)方法。
时间盒。时间盒是工作将在其间完成的较短的固定期间,如 1 周、2 周或 1 个月。
2.5.2 平衡竞争性制约因素
成功领导项目包括了解与工作相关的制约因素。制约因素可能会采取固定交付日期、遵守法规、预先确定的预算、质量政策、三重底线考虑因素等形式。在整个项目期间,制约因素可能会发生变化。新的干系人需求可能需要延展进度和增加预算。削减预算可能需要放宽质量要求或缩小范围。
应平衡这些不断变化的制约因素,同时保持干系人的满意度,这是一项持续进行的项目活动。有时,这可能包括与客户、发起人或产品负责人开会,以提出备选方案和说明其含义。有时,决策和潜在偏差可能在项目团队的职权范围内,他们可以权衡利弊,交付最终结果。无论哪种情况,这种平衡活动在整个项目期间都会持续开展。
2.5.4 项目沟通和参与
大部分项目工作都与沟通和参与(特别是与使项目团队成员和其他干系人始终参与相关的工作)息息相关。如干系人绩效域所述,除了需要进行口头和书面沟通外,沟通还涉及正式和非正式沟通。可以在会议、对话中以及通过从电子存储库中提取信息的方式,来收集信息。一旦收集完毕,信息就会按照项目管理沟通计划的说明进行分发。
在日常工作中,有人会提出特别沟通请求,要求提供信息、演示文稿、报告和其他形式的材料。大量特别沟通请求可能表明,沟通规划不足以满足干系人的需要。在这种情况下,可能需要干系人进一步参与,以确保满足干系人的信息需求。
2.6.2.2 范围定义
随着需求被识别,满足这些需求的范围也应被定义。范围是项目所提供的产品、服务和结果的总和。随着范围被定义,还需要识别更多的需求。因此,与需求一样,范围可以预先被定义好,也可以随着时间的推移而演变,或可以被发现。
范围分解。可以使用范围说明书来阐明范围,以识别与项目关联的主要可交付物以及每个可交付物的验收标准。还可以通过使用工作分解结构 (WBS) 将范围分解为较低层级的细节,从而详细说明范围。WBS 是对项目团队为实现项目目标、创建所需可交付物,而需要实施的全部工作范围的层级分解。该层级往下的每一个层级代表着关于可交付物的更详细的信息以及生成可交付物所需的工作。
详细说明范围的另一种方法是在敏捷章程、路线图或作为产品层级结构的一部分来确定项目的各个主题。这些代表着大量用户价值的主题可表示为用户故事,该用户故事与诸如功能、数据源,或安全级别等常见因素相关。为了完成这些主题,项目团队会开发史诗故事。史诗故事是一种逻辑容器,用于容纳因太大而无法在一个迭代中完成的较大的用户故事。史诗故事可以分解为多个特性,这些特性是一组通常被描述为简短的短语或功能的相关需求,代表着产品的特定行为。每个特性都有多个用户故事。用户故事是向特定用户提供的成果的简要描述,而且确保可以通过对话澄清细节。项目团队会在负责的最后责任时刻定义故事细节,以避免在范围发生变更时造成规划浪费。故事可清晰且简洁地描述从最终用户的角度编写的需求。
完成可交付物。根据所使用的方法,有不同的方式来描述组件或项目的完成情况:
验收或完成的标准。在客户验收可交付物之前,或在项目被视为完成之前需要满足的标准通常会记录在范围说明书中。
技术绩效测量指标。产品的技术规范可能记录在单独的规范文件中,也可能记录为 WBS 的扩展。这一扩展称为 WBS 字典,它详细说明了 WBS 中每项可交付物(工作包)的信息。
完成的定义。可将完成的定义与适应型方法一起使用,特别是在软件开发项目中。它是为了考虑可交付物能供客户使用,而须达到的所有标准的检查清单。
2.6.2.3 完成的目标不断移动
在不确定和快速变化的环境中运行的项目面临着“足够好可以发布”或“已完成”的目标可能会发生变化的情况。在竞争对手频繁发布新产品的市场中,新的发布中计划的特性可能会有所更新。同样,新的技术趋势(例如移动设备或可穿戴设备)可能会触发方向变化或引入新的需求。
在这些环境中,正在交付或“已完成”的项目目标的定义正在不断移动。项目团队会跟踪计划的项目目标实现率(相对于进度完成率)。完成项目耗费的时间越长,与“完成”的项目目标的距离就越远。这有时被称为“完成漂移”。
图 2-21 显示了一个开发新智能手表的场景。初始进度计划显示,开发具有一组初始功能和特性的手表需要 12 个月。随着竞争对手类似产品的上市,在这组初始功能和特性的基础上不断扩增,以便紧跟市场变化,这将上市日期推迟至第 14 个月。第 13 个月,另一个竞争对手上市了一款功能更多的产品。增加这些功能会将上市日期延迟到第 16 个月。项目团队将在某个时点决定是否发布产品(即使它没有最新特性),或者在上市之前继续对这些特性做出更新。

图 2-21. 开发智能手表的场景
在更加稳定的环境中运行的项目通常会面临“范围蔓延”。在这种情况下,将接受额外的范围或需求,而不对相应的进度、预算或资源需要等做出调整。为了应对范围蔓延,项目团队会使用变更控制系统,在该系统中评估所有变更,以了解变更为项目带来的潜在价值,及实现该价值所需的潜在资源、时间和预算。然后,项目团队将这些变更提交给项目治理机构、产品负责人或高管发起人,以待其正式批准。
2.6.3 质量
交付不仅仅只是范围和需求。范围和需求聚焦于需要交付的内容。质量聚焦于需要达到的绩效水平。质量需求可能会反映在完成标准、完成的定义、工作说明书或需求文件中。
与质量相关的很多成本都是由发起组织承担的,并反映在政策、程序和工作过程中。例如,治理如何执行工作的组织政策和规定工作过程的程序,通常是组织质量政策的一部分。尽管管理费用、培训和过程审计的成本是由项目使用的,但它们却由组织承担。在各个项目中,必须在过程和产品的质量需要与满足这些需要的相关成本之间取得平衡。
2.6.3.1 质量成本
与产品或可交付物相关的属性包括但不限于:
▶ 合规性/关键性。什么程度的过程严格性和质量保证是合适的?
▶ 产品/可交付物的类型。产品是否为人所知且为有形之物,例如像一幢建筑那样易于识别和描述?或者是无形之物,例如软件或者新药设计?
▶ 行业市场。项目产品或可交付物服务于哪个市场?该市场是否受到严格监管,发展迅速或缓慢?竞争对手和所在企业的情况如何?
▶ 技术。技术是稳定且成熟,或是发展迅速且存在过时的风险?
▶ 时间框架。项目时间框架很短(数周或数月)还是很长(数年)?
▶ 需求的稳定性。核心需求出现变更的可能性有多大?
▶ 安全性。产品业务的要素是否属于保密或机密信息?
▶ 增量交付。这是项目团队可以用增量方式开发并获得干系人反馈的东西,还是在接近完成之前难以评估的东西?
2.8.3.2 重新构建
交付不仅仅只是范围和需求。范围和需求聚焦于需要交付的内容。质量聚焦于需要达到的绩效水平。质量需求可能会反映在完成标准、完成的定义、工作说明书或需求文件中。
与质量相关的很多成本都是由发起组织承担的,并反映在政策、程序和工作过程中。例如,治理如何执行工作的组织政策和规定工作过程的程序,通常是组织质量政策的一部分。尽管管理费用、培训和过程审计的成本是由项目使用的,但它们却由组织承担。在各个项目中,必须在过程和产品的质量需要与满足这些需要的相关成本之间取得平衡。
2.8.5 风险
从产品或可交付物的角度看,不确定性绩效域与规划绩效域、项目工作绩效域、交付绩效域和测量绩效域相互作用。随着规划的进行,可将减少不确定性和风险的活动纳入计划。这些工作是在交付绩效域中执行的。测量可以表明随着时间的推移风险级别是否有所变化。
项目团队成员和其他干系人是不确定性的主要信息来源。在应对各种形式的不确定性方面,他们可以提供信息、建议和协助。
生命周期和开发方法的选择将影响不确定性的应对方式。在范围相对稳定的预测型项目中,可以使用进度和预算中的储备来应对风险。在采用适应型方法的项目中,需求可能会演变,在系统如何互动或干系人如何反应方面可能存在模糊性,项目团队可以调整计划,以反映对不断演变情况的理解,还可以使用储备来抵消已发生的风险的影响。
2.8.5.1 威胁

图 3-4. 有效地干系人参与
干系人可能是能影响项目组合、项目集或项目的决策、活动或成果的个人、群体或组织,以及会受或自认为会受这些决策、活动或成果影响的个人、群体或组织。干系人还以积极或消极的方式直接或间接影响项目,及其绩效或成果。
干系人可以影响项目的许多方面,包括,但不限于:
▶ 范围 / 需求 — 通过表明需要增加、调整或删除范围和/或项目需求的要素;
▶ 进度 — 通过提出加快交付的想法,或者放慢或停止交付关键项目活动;
▶ 成本 — 通过帮助减少或取消计划支出,或者增加会提高成本或需要额外资源的步骤、需求或限制;
▶ 项目团队 — 通过限制或允许接触具备交付预期成果所需技能、知识和经验并可推动学习型文化的人员;
▶ 计划 — 通过为计划提供信息,或倡导对商定的活动和工作作出变更;
▶ 成果 — 通过开展或阻止实现为期望成果所需的工作;
▶ 文化 — 通过建立或影响甚至定义项目团队和更广泛组织参与的程度和特点;
▶ 收益实现 — 通过制定和确定长期目标,从而使项目交付预期的确定价值;
▶ 风险 — 通过界定项目的风险临界值,并参与后续的风险管理活动;
▶ 质量 — 通过识别和要求提供质量需求;
▶ 成功 — 通过定义成功因素并参与对成功的评估。
在项目的整个生命周期内,干系人可能会参与进来,也可能会退出。此外,随着时间的推移,干系人的利益、影响或作用可能也会有所变化。干系人(特别是那些影响力高且对项目持不赞同或中立观点的干系人)
需要有效地参与进来,以便项目团队了解他们的利益、顾虑和权利。然后,项目团队可以通过有效参与和支持来应对这些顾虑,这样就可能会成功地实现项目成果。
从项目开始到结束,识别、分析并主动争取干系人参与有助于项目取得成功。
项目团队是一组干系人。这些干系人会与其他干系人互动,以理解、思考、沟通并回应他们的利益、需要和意见。
有效果且有效率的参与和沟通包括确定干系人想要或应该进行参与的方式、时间、频率和情形。沟通是参与的关键部分,但深入的参与可让人了解他人的想法,吸收其他观点以及协同努力制定共同的解决方案。参与包括通过频繁的双向沟通建立和维持牢固的关系。它鼓励通过互动会议、面对面会议、非正式对话和知识共享活动进行协作。
干系人参与在很大程度上依赖于人际关系技能,包括积极主动、正直、诚实、协作、尊重、同理心和信心。这些技能和态度可以帮助每个人适应工作和彼此适应,从而增加成功的可能性。
参与有助于项目团队发现、收集和评估信息、数据和意见。这可形成共识和一致性,从而实现项目成果。此外,这些活动还有助于项目团队对项目进行裁剪,以识别、调整和应对不断变化的环境。
在整个项目进行期间,项目团队会积极让其他干系人参与,以最小化潜在消极影响并最大化积极影响。除了提高干系人满意度外,让干系人参与还使项目团队有机会取得更出色的项目绩效和成果。最后,其他干系人的参与有助于项目团队找到更能为更广泛的干系人接受的解决方案。
2.8.6 与其他绩效域的相互作用
从产品或可交付物的角度看,不确定性绩效域与规划绩效域、项目工作绩效域、交付绩效域和测量绩效域相互作用。随着规划的进行,可将减少不确定性和风险的活动纳入计划。这些工作是在交付绩效域中执行的。测量可以表明随着时间的推移风险级别是否有所变化。
项目团队成员和其他干系人是不确定性的主要信息来源。在应对各种形式的不确定性方面,他们可以提供信息、建议和协助。
生命周期和开发方法的选择将影响不确定性的应对方式。在范围相对稳定的预测型项目中,可以使用进度和预算中的储备来应对风险。在采用适应型方法的项目中,需求可能会演变,在系统如何互动或干系人如何反应方面可能存在模糊性,项目团队可以调整计划,以反映对不断演变情况的理解,还可以使用储备来抵消已发生的风险的影响。
3.1 概述
裁剪是对有关项目管理方法、治理和过程深思熟虑后作出调整,使之更适合特定环境和当前工作。
在项目环境中,裁剪会考虑开发方法、过程、项目生命周期、可交付物以及与其共同参与工作人员的选择。裁剪过程受《项目管理标准》[1] 中的指导性项目管理原则、组织价值观和组织文化的驱动。例如,如果核心的组织价值观是“以客户为中心”,那么为启发需求和确认范围而选择的活动就要倾向于采用以客户为中心的方法。这种方法符合“有效地干系人参与”这一原则。同样,在项目的整个生命周期,风险偏好较低的组织可能有许多流程和程序来指导项目。而在同一市场上运营但风险承受能力高的类似公司可能会有较少的流程和程序。在这两个示例中,尽管各个组织的偏好、流程和程序各不相同,但它们都遵守“优化风险应对”这一原则。
使用裁剪需要谨慎选择和调整多个项目因素,无论是否使用“裁剪”标签皆是如此。
剪裁的替代方案是使用未经修改的框架或方法论。有许多方法论可以描述项目中使用的过程、阶段、方法、工件和模板。这些方法论及其组件不是根据组织环境定制的。
它们中的大多数都有明确的指导说明,它指出不应只是严格遵守,而是要经过一个裁剪过程,以便根据项目的特定类型、规模和复杂性确定哪些要素最有用。可是一些经验不足的从业者试图完完全全地应用该方法论,而不考虑项目规模、复杂性、持续时间或组织环境。
进行裁剪时需要了解项目背景、目的和运行环境。项目的运行环境非常复杂,需要平衡下列潜在的互相矛盾的要求,包括但不限于:
▶ 尽快交付;
▶ 最小化项目成本;
▶ 优化所交付的价值;
▶ 创建高质量的可交付物和成果;
▶ 遵守监管标准;
▶ 满足不同干系人的期望;
▶ 适应变化。
需要理解、评估和平衡这些因素,以便为项目创造切实可行的运行环境。
有些情况可能会限制项目团队调整其方法的程度,例如,当组织政策要求使用特定方法或合同强制规定了某种方法时。
3.2 为什么要裁剪?
裁剪旨在更好地满足组织、运行环境和项目的需要。许多变量都是裁剪过程的考虑因素,包括项目的重要性和所涉及干系人的数量。以这些变量为例,关键项目(如建造核反应堆)所需的严谨、制衡和报告的要求显然要远远高于建造新办公楼。
同样,对于一个由 200 人组成的项目团队来说,一个由 10 人组成的项目团队所需的沟通和工作协调也是不够的。过程太少会忽略可支持有效项目管理的关键活动,而如果使用的过程多于所需数量,则引发成本高昂和浪费。因此,裁剪有助于对运行环境和项目需求进行适当管理。
用于交付项目的结构既可以规模很大也可以很小,既可以非常严密也可以是轻量级,既可以是稳健型的也可以是简单的。没有一种单一的方法可以一直应用于所有项目。相反,裁剪应反映每个项目的规模、持续时间和复杂性,并应适应组织所在的行业、组织文化和项目管理成熟度。
裁剪可为组织带来直接和间接的收益。这些属性包括但不限于:
▶ 帮助对方法进行裁剪的项目团队成员,可以做出更多承诺;
▶ 以客户为本(因为客户需要是组织发展的重要影响因素);
▶ 更有效地利用项目资源。
3.3.2 过程
针对选定生命周期的过程裁剪和开发方法包括要确定对哪些部分或要素实施以下操作:
▶ 增加,以实现所需的严格性、覆盖范围,或应对独特的产品或运营环境的状况等(例如,对安全性要求比较高的项目要增加独立检查这一环节);
▶ 修改,以更好地满足项目或项目团队的需求(例如,修改项目文档的格式,以照顾视力较差的项目团队成员);
▶ 取消,以减少成本或人力投入,因为相对于它所增加的价值,这些成本或投入没有必要或不经济(例如,对一个集中办公、具有良好沟通的小型项目团队,可以取消会议记录);
▶ 混合,通过混合或合并各种要素带来额外的收益或价值(例如,将组织管理中的欣赏式探询寻法添加至预测型项目管理的经验教训会议中,以帮助促进更好的协作);
▶ 调整,以协调各种要素,从而形成一致的定义、理解和应用(如许多学科都有与风险管理相关的标准和实践,这些标准和实践彼此之间存在很大差异,需要进行一致性调整)。例如,在涉及多个学科的项目团队中,不同学科可能存在特定要素(如与同一焦点领域有关的各自语言、工具以及实践)。
3.4.3.1 产品/可交付物
与产品或可交付物相关的属性包括但不限于:
▶ 合规性/关键性。什么程度的过程严格性和质量保证是合适的?
▶ 产品/可交付物的类型。产品是否为人所知且为有形之物,例如像一幢建筑那样易于识别和描述?或者是无形之物,例如软件或者新药设计?
▶ 行业市场。项目产品或可交付物服务于哪个市场?该市场是否受到严格监管,发展迅速或缓慢?竞争对手和所在企业的情况如何?
▶ 技术。技术是稳定且成熟,或是发展迅速且存在过时的风险?
▶ 时间框架。项目时间框架很短(数周或数月)还是很长(数年)?
▶ 需求的稳定性。核心需求出现变更的可能性有多大?
▶ 安全性。产品业务的要素是否属于保密或机密信息?
▶ 增量交付。这是项目团队可以用增量方式开发并获得干系人反馈的东西,还是在接近完成之前难以评估的东西?
3.4.3.2 项目团队
Allan Drexler 和 David Sibbet 开发了团队绩效模型,共有七个步骤。第 1 步至第 4 步描述了建立项目团队过程中的各个阶段,第 5 步至第 7 步则涵盖了项目团队的可持续性和绩效。
▶ 第 1 步 : 确定方向“确定方向”回答了为什么这个问题。在这一阶段,项目团队会了解项目的目的和使命。这通常发生在开工会议上,或者会记录在商业论证、项目章程或精益创业画布中。
▶ 第 2 步 : 建立信任“建立信任”回答了谁这个问题。这一阶段阐明了谁会加入项目团队以及每个人会带来什么样的技能和能力。它还可以包括关于可能未加入项目团队但对项目团队有影响的关键干系人的信息。
▶ 第 3 步 : 澄清目标“澄清目标”回答了什么这个问题。在这一阶段,项目团队详细阐述了高层级的项目信息。这可能包括进一步了解干系人的期望、需求、假设条件和可交付物的验收标准。
▶ 第 4 步 : 承诺“承诺”解决了如何这个问题。在这一阶段,项目团队开始定义实现目标的计划。这可以包括里程碑进度计划、发布计划、高层级预算、资源需求等。
▶ 第 5 步 : 实施。高层级计划会分解为更详细的层级,例如详细的进度计划或待办事项列表。项目团队开始共同努力生成可交付物。
▶ 第 6 步 : 高绩效。项目团队合作一段时间后,项目团队成员的绩效达到了很高的水平。他们可以很好地协同工作,无需太多监督,并且项目团队会产生协同效应。
▶ 第 7 步 : 重新开始“重新开始”是应对项目团队或项目变更的阶段。可交付物、干系人、环境、项目团队领导或团队成员资格可能会发生变化。这会使项目团队考虑过去的行为和行动是否仍然足够,或者团队是否需要返回到以前的某一阶段,以重新设立期望和合作方式。
3.5.6 交付
▶ 组织是否拥有正式或非正式的需求管理系统?
▶ 组织是否拥有正式或非正式的确认和控制相关政策、程序和指南?
▶ 组织有哪些质量政策和程序?组织使用哪些质量工具、技术和模板?
▶ 是否存在必须遵守的行业质量标准?需要考虑哪些政府、法律或法规方面的制约因素?
▶ 项目中是否存在需求不稳定的领域?如果是,应对需求不稳定的最佳方法是什么?
▶ 如何在项目管理或产品开发的要素中对可持续性因素加以考虑?
4.2.5.2 Stacey 矩阵
Ralph Stacey 开发的 Stacey 矩阵类似于 Cynefin 框架,但它从两个维度来确定项目的相对复杂性(a)针对可交付物的需求的相对不确定性,以及 (b) 将用于创建可交付物的技术的相对不确定性。基于这些维度的相对不确定性,项目被分为简单型、繁杂型、复杂型或混乱型。复杂程度是影响项目裁剪方法和实践的一个因素。
4.2.6.2 Drexler/Sibbet 团队绩效模型
Allan Drexler 和 David Sibbet 开发了团队绩效模型,共有七个步骤。第 1 步至第 4 步描述了建立项目团队过程中的各个阶段,第 5 步至第 7 步则涵盖了项目团队的可持续性和绩效。
▶ 第 1 步 : 确定方向“确定方向”回答了为什么这个问题。在这一阶段,项目团队会了解项目的目的和使命。这通常发生在开工会议上,或者会记录在商业论证、项目章程或精益创业画布中。
▶ 第 2 步 : 建立信任“建立信任”回答了谁这个问题。这一阶段阐明了谁会加入项目团队以及每个人会带来什么样的技能和能力。它还可以包括关于可能未加入项目团队但对项目团队有影响的关键干系人的信息。
▶ 第 3 步 : 澄清目标“澄清目标”回答了什么这个问题。在这一阶段,项目团队详细阐述了高层级的项目信息。这可能包括进一步了解干系人的期望、需求、假设条件和可交付物的验收标准。
▶ 第 4 步 : 承诺“承诺”解决了如何这个问题。在这一阶段,项目团队开始定义实现目标的计划。这可以包括里程碑进度计划、发布计划、高层级预算、资源需求等。
▶ 第 5 步 : 实施。高层级计划会分解为更详细的层级,例如详细的进度计划或待办事项列表。项目团队开始共同努力生成可交付物。
▶ 第 6 步 : 高绩效。项目团队合作一段时间后,项目团队成员的绩效达到了很高的水平。他们可以很好地协同工作,无需太多监督,并且项目团队会产生协同效应。
▶ 第 7 步 : 重新开始“重新开始”是应对项目团队或项目变更的阶段。可交付物、干系人、环境、项目团队领导或团队成员资格可能会发生变化。这会使项目团队考虑过去的行为和行动是否仍然足够,或者团队是否需要返回到以前的某一阶段,以重新设立期望和合作方式。
4.2.7.4 过程组
项目管理过程可以按逻辑分组,分为项目管理输入、工具和技术以及输出,为了满足组织、干系人和项目的需要会对它们进行裁剪。
过程组不是项目阶段。在项目生命周期的每个阶段内,各个过程组会相互作用。所有这些过程都有可能在一个阶段内发生。在一个阶段或生命周期内,各个过程可能会迭代发生。过程迭代的次数和过程间的相互作用因具体项目的需要而有所不同。
采用基于过程的方法的项目可以将以下五个过程组作为组织结构:
▶ 启动。定义一个新项目或现有项目的一个新阶段,授权开始该项目或阶段的一组过程。
▶ 规划。明确项目范围,完善目标,为实现目标制定行动方案的一组过程。
▶ 执行。完成项目管理计划中确定的工作,以满足项目需求的一组过程。
▶ 监控。跟踪、审查和调整项目进展与绩效的一组过程,该过程识别任何计划需要变更的领域,并启动相应变更。
▶ 收尾。正式完成或结束项目、阶段或合同时所执行的过程。
这些过程组与交付方法、应用领域(例如市场营销、信息服务和会计)或行业(例如建筑、航空航天和电信)相互独立。在基于过程的方法中,一个过程的输出通常成为另一个过程的输入,或者成为项目或项目阶段的可交付物。例如,在规划过程组中生成的项目管理计划和项目文档(例如风险登记册、假设日志等)是执行过程组的输入,在执行过程组中会对相关工件进行更新。
4.4.4 其他方法
本节中描述的方法不适合于上述特定类别;但它们是用于项目的多种目的的常用方法。
影响地图。影响地图是一种战略规划方法,在产品开发期间作为组织的可视化路线图。
建模。建模是创建对系统、解决方案或可交付物(例如原型、示意图或故事板)的简化表示法的过程。通过确定信息中的差距、沟通错误的方面或额外需求,建模能有助于进一步分析。
净推荐值 (NPS )。客户将某组织的产品或服务推荐给他人的意愿的一种测量指数。该数值是被用作衡量客户对组织产品或服务的总体满意度,以及客户对品牌的忠诚度的指标。
优先级模型。优先级模型是用于确定项目组合、项目集、项目的组件以及需求、风险、特性或其他产品信息的优先级的方法。例如多标准加权分析和 MoSCoW(“必须有”“应该有”“可以有”和“不会有”)方法。
时间盒。时间盒是工作将在其间完成的较短的固定期间,如 1 周、2 周或 1 个月。
4.5 跨绩效域应用的方法
在每个绩效域中,不同的方法可能更有用。虽然交付方法、产品和组织环境的需求将决定哪些方法最适合于特定项目,但某些绩效域更有可能使用特定方法。表 4-2 列出了每种方法最有可能使用的绩效域;但项目经理和/或项目团队负有为其项目选择合适方法的最终责任。
表 4-2. 每个绩效域中可能使用方法的映射

4.6.2 日志和登记册
日志和登记册用于记录项目不断演变的方面。它们会在整个项目期间得到更新。日志和登记册这两个词有时可以互换使用。我们经常看到用风险登记册或风险日志这两个词是指同一个工件。
假设日志。假设条件是没有证据或证明即被认为正确、真实或确定的因素。制约因素是对管理项目、项目集、项目组合或过程的方案进行限制的因素。假设日志记录了整个项目期间的所有假设条件和制约因素。
待办事项列表。待办事项列表是待完成工作的有序列表。项目可能有产品待办事项列表、需求待办事项列表、障碍因素待办事项列表等。待办事项列表中的事项会被确定优先级。然后为即将到来的迭代安排优先级高的工作。
变更日志。变更日志是项目过程中提交的变更及其当前状态的综合清单。变更可以是对任何正式受控的可交付物、项目管理计划组件或项目文件的修改。
问题日志。问题是可以对项目目标产生影响的当前条件或情形。问题日志会被用于记录和监督与尚未解决的问题相关的信息。问题将被分配给责任方进行跟进和解决。
经验教训登记册。经验教训登记册可被用于记录在某一项目、阶段或迭代期间所获知识的项目文件,以便未来可将这些知识用于提高团队和组织的绩效。
风险调整待办事项列表。风险调整待办事项列表包含了产品所需工作,以及应对威胁和机会的行动。
风险登记册。风险登记册是记录风险管理过程输出的存储文件。风险登记册中的信息可以包括相关管理风险的负责人,概率、影响、风险评分、计划的风险应对,和用来获得关于单个风险的高层级理解的其他信息。
干系人登记册。干系人登记册会记录与项目干系人有关的信息,其中包括对项目干系人的评估和分类。
4.6.3 计划
沟通规划会与干系人识别、分析、优先级排序和参与的内容有所重叠,这些内容会在干系人绩效域(第 2.1 节)中描述。沟通在争取干系人有效参与方面是最重要的因素。为项目规划沟通时需要考虑以下因素:
▶ 谁需要信息?
▶ 每个干系人需要哪些信息?
▶ 为什么要与干系人共享信息?
▶ 提供信息的最佳方式是什么?
▶ 何时以及多久需要一次信息?
▶ 谁拥有所需要的信息?
可能存在不同类别的信息,例如内部信息和外部信息,敏感信息和公开信息,或者一般信息和详细信息。分析干系人、信息需求和信息类别为制定项目的沟通过程和计划奠定了基础。
附录X2 发起人
在不确定和快速变化的环境中运行的项目面临着“足够好可以发布”或“已完成”的目标可能会发生变化的情况。在竞争对手频繁发布新产品的市场中,新的发布中计划的特性可能会有所更新。同样,新的技术趋势(例如移动设备或可穿戴设备)可能会触发方向变化或引入新的需求。
在这些环境中,正在交付或“已完成”的项目目标的定义正在不断移动。项目团队会跟踪计划的项目目标实现率(相对于进度完成率)。完成项目耗费的时间越长,与“完成”的项目目标的距离就越远。这有时被称为“完成漂移”。
图 2-21 显示了一个开发新智能手表的场景。初始进度计划显示,开发具有一组初始功能和特性的手表需要 12 个月。随着竞争对手类似产品的上市,在这组初始功能和特性的基础上不断扩增,以便紧跟市场变化,这将上市日期推迟至第 14 个月。第 13 个月,另一个竞争对手上市了一款功能更多的产品。增加这些功能会将上市日期延迟到第 16 个月。项目团队将在某个时点决定是否发布产品(即使它没有最新特性),或者在上市之前继续对这些特性做出更新。

图 2-21. 开发智能手表的场景
在更加稳定的环境中运行的项目通常会面临“范围蔓延”。在这种情况下,将接受额外的范围或需求,而不对相应的进度、预算或资源需要等做出调整。为了应对范围蔓延,项目团队会使用变更控制系统,在该系统中评估所有变更,以了解变更为项目带来的潜在价值,及实现该价值所需的潜在资源、时间和预算。然后,项目团队将这些变更提交给项目治理机构、产品负责人或高管发起人,以待其正式批准。
X4.2 全球市场变化
三种全球趋势正在颠覆传统的商业模式并使产品和服务发生转变(参见图 X4-1)。

图 X4-1. 影响产品管理的全球商业趋势
▶ 以客户为中心。以客户为中心会颠覆组织开发产品并将产品推向客户的传统模式。如今,组织正在发生变化,以便更好地理解、服务和维持客户忠诚度(参见图 X4-2)。当今的技术可以捕获一系列客户数据和需求,组织可分析这些数据和需求并将它们用于潜在的产品增强、交叉销售机会和新产品创意等方面。

图 X4-2. 组织与其客户之间不断变化的关系
▶ 软件增强的价值。软件及其所能提供的功能已成为当今一系列产品和服务的关键差异化竞争优势。三十年前,软件主要是在专用计算机上运行。十年前,由于增强的无线和卫星通信系统,软件已嵌入车辆和家庭控制系统。现在,即使是最普通的设备也运行着软件,这些软件可以增加新功能并捕获使用情况的数据。大多数组织至少通过网站和应用程序以电子方式开展部分交易业务。由于需要不断升级和维护这些系统,这些服务只有在产品或服务停用时才算真正完成开发。
▶ 持续供应和支付。既定经济模式的变化正在使许多组织发生转型。单笔交易服务正被连续供应和支付所取代。范例包括:
▹ 出版。自助出版、直接发行和电子书籍,允许在出版后不断完善和发展。
▹ 金融。基于对所交付价值的评估,从当地分行获得资金转向小额贷款(分批提供小额资金)。
▹ 初创公司。随着零工经济和定制化市场的增长,如今的初创公司和小企业数量比以往任何时候都要多。与传统模式相比,工作更分散、更碎片化和不稳定。
▹ 媒体。不再从集中的专营店购买 DVD 和 CD,取而代之的是持续付费来获得收益的订阅服务的兴起。