2.4.7 变更
引用
2.2 组织治理系统
治理系统与价值交付系统协同运作,可实现流畅的工作流程、管理问题并支持决策。治理系统提供了一个框架,其中包含指导活动的职能和流程。治理框架可以包括监督、控制、价值评估、各组件之间的整合以及决策能力等要素。
治理系统提供了一个整合结构,用于评估与环境和价值交付系统的任何组件相关的变更、问题和风险。这些组件包括项目组合目标、项目集收益和项目生成的可交付物。
项目可以在一个项目集或项目组合内运作,也可以作为一个独立的活动进行。在一些组织中,项目管理办公室可能会为项目组合内的项目集和项目提供支持。项目治理包括定义用于批准变更和做出与项目相关的其他业务决策的职权。项目治理与项目集和/或组织治理保持一致。
3.3 有效地干系人参与
图 3-4. 有效地干系人参与
干系人可能是能影响项目组合、项目集或项目的决策、活动或成果的个人、群体或组织,以及会受或自认为会受这些决策、活动或成果影响的个人、群体或组织。干系人还以积极或消极的方式直接或间接影响项目,及其绩效或成果。
干系人可以影响项目的许多方面,包括,但不限于:
▶ 范围 / 需求 — 通过表明需要增加、调整或删除范围和/或项目需求的要素;
▶ 进度 — 通过提出加快交付的想法,或者放慢或停止交付关键项目活动;
▶ 成本 — 通过帮助减少或取消计划支出,或者增加会提高成本或需要额外资源的步骤、需求或限制;
▶ 项目团队 — 通过限制或允许接触具备交付预期成果所需技能、知识和经验并可推动学习型文化的人员;
▶ 计划 — 通过为计划提供信息,或倡导对商定的活动和工作作出变更;
▶ 成果 — 通过开展或阻止实现为期望成果所需的工作;
▶ 文化 — 通过建立或影响甚至定义项目团队和更广泛组织参与的程度和特点;
▶ 收益实现 — 通过制定和确定长期目标,从而使项目交付预期的确定价值;
▶ 风险 — 通过界定项目的风险临界值,并参与后续的风险管理活动;
▶ 质量 — 通过识别和要求提供质量需求;
▶ 成功 — 通过定义成功因素并参与对成功的评估。
在项目的整个生命周期内,干系人可能会参与进来,也可能会退出。此外,随着时间的推移,干系人的利益、影响或作用可能也会有所变化。干系人(特别是那些影响力高且对项目持不赞同或中立观点的干系人)
需要有效地参与进来,以便项目团队了解他们的利益、顾虑和权利。然后,项目团队可以通过有效参与和支持来应对这些顾虑,这样就可能会成功地实现项目成果。
从项目开始到结束,识别、分析并主动争取干系人参与有助于项目取得成功。
项目团队是一组干系人。这些干系人会与其他干系人互动,以理解、思考、沟通并回应他们的利益、需要和意见。
有效果且有效率的参与和沟通包括确定干系人想要或应该进行参与的方式、时间、频率和情形。沟通是参与的关键部分,但深入的参与可让人了解他人的想法,吸收其他观点以及协同努力制定共同的解决方案。参与包括通过频繁的双向沟通建立和维持牢固的关系。它鼓励通过互动会议、面对面会议、非正式对话和知识共享活动进行协作。
干系人参与在很大程度上依赖于人际关系技能,包括积极主动、正直、诚实、协作、尊重、同理心和信心。这些技能和态度可以帮助每个人适应工作和彼此适应,从而增加成功的可能性。
参与有助于项目团队发现、收集和评估信息、数据和意见。这可形成共识和一致性,从而实现项目成果。此外,这些活动还有助于项目团队对项目进行裁剪,以识别、调整和应对不断变化的环境。
在整个项目进行期间,项目团队会积极让其他干系人参与,以最小化潜在消极影响并最大化积极影响。除了提高干系人满意度外,让干系人参与还使项目团队有机会取得更出色的项目绩效和成果。最后,其他干系人的参与有助于项目团队找到更能为更广泛的干系人接受的解决方案。
3.4 聚焦于价值
图 3-5. 聚焦于价值
价值(包括从客户或最终用户的角度看的成果)是项目的最终成功指标和驱动因素。价值聚焦于可交付物的成果。项目的价值可以表示为对发起组织或接收组织的财务贡献。价值也可以是对所取得的公共利益的测量,例如,社会收益或客户从项目结果中所感知到的收益。当项目是项目集的组件时,项目对项目集成果的贡献可以表示为价值。
许多项目(尽管不是所有项目)都是基于商业论证而启动。也可能由于任何确定的交付需要,或者修改流程、产品或服务(如合同、工作说明书或其他文件)的需要而启动项目。在所有情况下,项目的目的就是提供预期成果,该成果通过有价值的解决方案满足需要。商业论证可以包含有关战略一致性、风险敞口评估、经济可行性研究、投资回报率、预期关键绩效测量、评估和替代方法的信息。商业论证可以从定性或定量的方面,或者同时从这两方面来说明项目成果的预期价值贡献。商业论证至少包含以下支持性和相互关联的要素:
▶ 商业需要。商业为项目提供理由,并解释为什么开展该项目。它源于初步的业务需求,这些需求反映在项目章程或其他授权文件中。商业需要提供了有关商业目的和目标的详细信息,它可能针对执行组织、客户组织、组织的合伙方或公共福利。明确说明商业需要有助于项目团队了解未来状态的商业驱动因素,并使项目团队能够识别机会或问题,从而提高项目成果的潜在价值。
▶ 项目理由。项目理由与商业需要相关。它解释了为什么商业需要值得投资以及为什么在此时应该满足商业需要。项目理由会附有成本效益分析和假设条件。
▶ 商业战略。商业战略是开展项目的原因,所有需要都与实现价值的战略相关。
除了收益和可能的协议之外,商业需要、项目理由和商业战略一起为项目团队提供信息,使他们能够做出知情决策,以达到或超过预期的商业价值。
在整个项目期间,应清晰描述、以迭代方式评估并更新期望成果。在项目生命周期内,项目可能会发生变更,然后项目团队会作出应对调整。项目团队会根据期望的输出、基准和商业论证不断评估项目进展情况和方向,以确定该项目仍与商业需要保持一致,并将交付预期成果。另外,干系人可以更新商业论证以获取机会,或者将项目团队和其他干系人确定的问题最小化。如果项目或其干系人不再与商业需要保持一致,或者如果项目似乎不可能提供预期价值,则组织可以选择终止此项投入。
价值是指某种事物的作用、重要性或实用性。价值具有主观性,从某种意义上说,同一个概念对于不同的人和组织具有不同的价值。之所以会发生这种情况,是因为所谓的收益取决于组织战略,包含从短期财务收益、到长期收益、甚至是非财务要素。由于所有项目都有一系列干系人,因此必须考虑为每个干系人群体产生的不同价值,并将这些价值与整体价值进行平衡,同时优先考虑客户价值。
在某些项目的背景下,可能存在不同形式的价值工程,这些价值工程可以将客户、执行组织或其他干系人的价值最大化。这方面的一个示例包括在可接受的风险敞口的情况下交付所需的功能和质量水平,同时尽可能少地使用资源,并避免浪费。有时,特别是在没有预先确定范围的适应型项目中,项目团队可以与客户共同努力,确定哪些功能值得投资,哪些功能可能缺乏足够的价值,无需增加到输出之中,从而优化价值。
为了支持从项目中实现价值,项目团队可将重点从可交付物转到预期成果。这样做可以让项目团队实现项目的愿景或目标,而不是简单地创建特定可交付物。虽然可交付物可能会支持预期的项目成果,但它可能无法完全实现项目的愿景或目标。例如,客户可能需要某一特定的软件解决方案,因为他们认为该解决方案可以满足提高生产力这一商业需要。软件是项目的输出,但软件本身并不能实现预期的生产力成果。在这种情况下,增加一项新的可交付物,即提供使用软件的培训和教练,就可以实现更好的生产力成果。如果项目的输出未能提高生产力,干系人可能会认为项目已经失败。因此,项目团队和其他干系人都应该了解可交付物及其预期成果。
项目工作的价值贡献可能是一种短期或长期的测量。由于价值贡献可能与运营活动的贡献相混合,因此很难将其分开。当项目是项目集的一个组件时,也可能需要在项目集层级对价值作出评估,以便以适当的方式对项目进行指导。可靠的价值评估应考虑项目输出的全部背景和整个生命周期。虽然价值会随着时间的推移而实现,但有效的过程可以帮助早日实现收益。通过有效率且有效果地实施项目,项目团队可以展示或实现诸如优先交付、更好的客户服务或改善工作环境等成果。通过与负责将项目可交付物投入使用的组织领导者合作,项目领导者可以确保可交付物能够实现所计划的成果。
3.11 拥抱适应性和韧性
图 3-12. 拥抱适应性和韧性
大多数项目在某个阶段都会遇到挑战或障碍。如果项目团队开展项目的方法同时具备适应性和韧性,则有助于项目适应各种影响并蓬勃发展。适应性是指应对不断变化的情形的能力。韧性由两个具有互补性的特质组成:吸收冲击的能力和从挫折或失败中快速恢复的能力。适应性和韧性是任何开展项目的人员应具备的有益特征。
项目很少会按最初的计划执行。项目会受到内部和外部因素(新需求、问题、干系人影响等因素)影响,这些因素存在于一个有各种相互作用的系统中。项目中的某些要素可能会失败或达不到预期,这需要项目团队重新组合、重新思考和重新规划。例如,在基础设施项目中,法院在项目执行期间的裁决可能会导致设计和计划的变更。在技术项目中,技术方面的电脑化模型可能会显示各个组件可以正常协同工作,但它们在实际应用时却发生故障。在这两个案例中,项目团队都需要应对此情形,以便推进项目。有一种观点认为,项目应严格遵守早期阶段的计划和承诺,即使在出现新的或不可预见的因素之后亦是如此。这种观点对包括客户和最终用户在内的干系人是没有益处的,因为这束缚了产生价值的可能性。但是,应该从整体的角度做到适应性,例如应采用适当的变更控制过程,以避免诸如范围蔓延等问题。在项目环境中,支持适应性和韧性的能力包括:
▶ 较短的反馈循环,以便快速适应;
▶ 持续学习和改进;
▶ 拥有宽泛技能组合的项目团队,同时还有在每个所需技能领域具有广博知识的个人;
▶ 定期检查和调整项目工作,以识别改进机会;
▶ 多样化的项目团队,以获得广泛的经验;
▶ 开放和透明的规划,让内部和外部干系人参与;
▶ 小规模的原型法和实验,以测试想法和尝试新方法;
▶ 充分运用新的思考方式和工作方式的能力;
▶ 平衡工作速度和需求稳定性的过程设计;
▶ 组织的开放式对话;
▶ 具有宽泛的技能组合、文化和经验的多样性项目团队,同时还有各个所需技能领域的主题专家;
▶ 对过去相同或类似工作中所获学习成果的理解力;
▶ 预测多种潜在情景,并为多种可能的情况做好准备的能力和意愿;
▶ 将决策推迟到最后责任时刻;
▶ 管理层支持;
▶ 平衡速度和稳定性的开放式设计。
预期的成果而非可交付物能够促成解决方案,进而可利用比原始计划更好的结果。例如,项目团队可找到替代解决方案,以提供比原始定义的可交付物更优的成果。虽然探寻替代方案通常属于商业论证的范畴,但技术和其他能力的演变非常快,以至于在商业论证完成和项目收尾之间的任何时候都可能会出现解决方案。项目期间可能会出现适应项目的机会,届时项目团队应向项目发起人、产品负责人或客户说明为何要抓住这一机会。根据合同类型,因适应项目而进行的某些变更可能需要客户批准。在项目发起人、产品负责人或客户的支持下,项目团队应准备好调整其计划和活动以利用这一机会。
项目系统中的意外变更和情况也可能会带来机会。为了优化价值交付,项目团队应该针对变更和计划外事件运用问题解决和整体思维方法。发生计划外事件时,项目团队应寻找可能获得的潜在积极成果。
例如,将项目时间线后期发生的变更包含进来,这样就可以成为市场上第一个提供该功能的产品,从而增加竞争优势。
在项目中保持适应性和韧性,可使项目团队在内部和外部因素发生变化时聚焦于期望成果,这有助于他们从挫折中恢复过来。这些特征还有助于项目团队学习和改进,以便他们能够从失败或挫折中快速恢复,并继续在交付价值方面取得进展。
3.12 为实现预期的未来状态而驱动变革
图 3-13. 为实现预期的未来状态而驱动变革
在当今的商业环境中保持相关性是所有组织面临的根本挑战。要做到具有相关性,必须对干系人的需要和期望作出响应。这就需要为干系人的利益不断评估产品/服务,对变革作出快速响应,并担当变革推动者。项目经理应具备独特的能力,让组织做好变革的准备。根据项目本身的定义,项目会创造新的事物:它们是变革推动者。
变革管理或使能(enablement)是一种综合的、周期性的和结构化的方法,可使个人、群体和组织从当前状态过渡到实现期望收益的未来状态。它不同于项目变更控制,后者是一个过程,通过该过程,项目团队可以识别和记录项目的文件、可交付物或基准的修改,然后批准或拒绝这些修改。
组织中的变革可能源自内部,例如需要新的能力或应对绩效差距。变革也可能源自外部,例如技术进步、人口结构变化或社会经济压力。任何类型的变革都涉及到经历变革的群体以及与其互动的行业某种程度的适应或接受。
变革可能由干系人实施并对其产生影响。推动干系人变革是促进项目提供所需可交付物和预期成果的一部分。
在组织中推动变革可能充满挑战,这有多种原因,比如有些人可能天生就抵制变革或厌恶风险,又如所处环境可能表现出保守的文化。有效的变革管理采用激励型策略,而不是强制型策略。参与和双向沟通可营造出这样的一种环境,即变革会得到采用和接受,或者从抵制变革的用户那里识别出一些需要解决的有效问题。
项目团队成员和项目经理可与有关干系人共同合作,解决抵制、疲劳和变革吸收的问题,以提高客户或项目可交付物接收者成功采纳或接受变革的可能性。这包括在项目早期沟通与变革相关的愿景和目的,以争取各方对变革的认同。在整个项目期间,应向组织内所有层级的人员说明变革的收益和对工作过程的影响。
同样重要的是,使变革的速度适应干系人和环境接受变革的意愿、成本和能力。如果试图在太短的时间内进行过多的变革,则可能会因变革饱和而受到抵制。即使干系人一致认为变革将产生更多价值或增强成果,他们仍往往难以采取能够交付更高收益的行动。为了促进收益实现,项目还可能会开展一些活动,以便在变革实施后使其得到强化,从而避免人们回到初始的状态。
认识并解决干系人在整个项目生命周期内接受变革的需要,有助于将由此产生的变革整合到项目工作中,从而使成功取得的成果更有可能。
有关组织变革管理的更多信息,可参阅《组织变革管理:实践指南》[4]。
2.3.4.1 产品、服务或结果
与产品、服务或结果的性质相关的许多变量会影响开发方法。以下列表概述了在选择开发方法时要考虑的一些变量。
▶ 创新程度。在充分了解范围和需求的情况下,项目团队以前曾完成的工作且能够提前规划的可交付物非常适合采用预测型方法。创新程度高或项目团队没有做过的可交付物更适合采用更多适应性的方法。
▶ 需求确定性。当需求变得众所周知且易于定义时,预测型方法非常适合。而当需求不确定、易变或复杂且预期在整个项目期间会发生演变时,更具有适应性的方法可能更适合。
▶ 范围稳定性。如果可交付物的范围稳定且不可能发生变化,则预测型方法非常有用。如果范围预期会有许多变更,开发方法频谱图上更靠近适应型方法这一端的会很有用。
▶ 变更的难易程度。这与需求确定性和范围稳定性相关。如果可交付物的性质使得管理和合并变更较为困难,那么预测型方法就是最佳的。对于容易适应变更的可交付物,可以采用更具适应性的方法。
▶ 交付选项方案。如第 2.3.2 节(“交付节奏”)中所述,可交付物的性质以及能否以组件形式交付将影响开发方法。可以分组块开发和/或交付的产品、服务或结果选用增量型方法、迭代型方法或适应型方法皆可。有些大型项目可以采用预测型方法进行规划,但其中有些组块可以增量型开发和交付。
▶ 风险。存在固有高风险的产品需要在选择开发方法之前进行分析。某些高风险产品可能需要大量前期规划和严格的流程减少威胁。基于学习利用新出现的机会或减少威胁的敞口,其他产品可以通过模块化构建,以及调整设计和开发来减轻风险。
▶ 安全需求。具有严格安全需求的产品通常采用预测型方法,因为需要进行大量的预先规划,以确保所有安全需求都得到识别、规划、创建、整合和测试。
▶ 法规。对受到严格法规监管的环境,由于有所需的流程、文档和演示的需要,可能要求采用预测型方法。
2.4.2 规划的变量
由于每个项目都是独特的,因此规划的数量、时间安排和频率各不相同。影响项目规划方式的变量包括(但不限于):
▶ 开发方法。开发方法会影响如何规划、规划多少及何时实施规划。范例包括:
▹ 生命周期早期进行规划或组织的特定阶段。在这些情况下,大部分规划都是预先进行的。在整个项目期间,最初的计划会渐进明细地制定,但对原来的范围没有什么改变。
▹ 一种预先进行高层级规划的方法,随后是使用原型的设计阶段。在项目团队和干系人对设计表示同意后,项目团队将完成更详细的规划。
▹ 项目团队实施迭代的适应型方法。一些规划会提前进行,以制定发布计划,而进一步的规划会在每个迭代开始时进行。
▶ 项目可交付物。通常需要以特定方式规划项目可交付物。建筑项目需要进行大量的前期规划,以便对设计、审批、材料采购、物流和交付做出说明。产品开发或高技术项目可以采用持续性和适应性的规划,以便根据干系人的反馈和技术进步进行演变和变更。
▶ 组织需求。组织治理、政策、程序、流程和文化可能会要求项目经理提供特定的规划工件。
▶ 市场条件。产品开发项目可能会在竞争激烈的环境中进行。在这种情况下,项目团队可以进行最低限度的前期规划,因为重点是加快投入市场的速度。过量的规划必然造成延迟的成本会超过潜在返工的风险。
▶ 法律或法规限制。监管机构或法规可能要求必须先提供特定的规划文件,然后才能得到进行实施的相关授权或者获得批准向市场发布项目可交付物。
2.4.2.1 交付
随着市场从单一项目交付模式转向持续交付模式,一些组织正在寻找交付单一产品、变更或服务的临时性项目结构的替代方案。其实,它们正在寻找的是交付结构,该交付结构非常注重以客户为中心,认识到技术的快速发展,并与忠诚客户的持续服务和收入流保持一致。
为了价值交付,这些因素引起人们对产品管理生命周期的兴趣增加,并向其转变。产品管理采用更长生命周期的视角,包括支持和维持同一团队,并与其共同持续发展。稳定的团队在复杂而独特的领域中尤为重要,例如具有嵌入式软件的这类系统中,知识转移既耗时又昂贵。将关注点转向产品管理正在促使一些项目导向型组织调整其交付模式。
2.4.9 一致性
转向长期运作、基于产品的环境的组织可以利用多种策略来调整和协调产品管理。三种策略包括但不限于(另请参见图 X4-3):
图 X4-3. 针对持续价值交付的支持策略
▶ 建立稳定的团队。不要在初始开发完成后就解散团队,而是利用该团队与指定的产品负责人或该团队中可反映客户观点的人一起维持和发展产品。这就消除了知识转移的需要,并减轻了由于失去隐性知识而导致未来的产品增强被延迟的风险。
长期团队比短期团队还能更好地增强市场意识、客户洞察力和客户同理心。这有助于维持以客户为中心和客户忠诚度,并建立竞争优势。当人们知道他们将负责维护和增强某一产品时,他们不太可能走捷径来准备产品发布。因此,长期服务的团队比开发后即移交产品的团队,更能提升产品的质量、可维护性和可扩展性。这些因素反过来又有助于创造价值并持续价值交付。
在客户现场开发和部署初始产品的合作伙伴或承包商,他们应该进行有效的变更管理,以确保客户能够在产品移交后有能力维护产品。作为移交规划的一部分,可能要包括关于在接收组织内建立一个团队的讨论,以便在产品的整个生命周期内支持和发展产品。
▶ 增量式的指导和提供资金。应考虑更频繁的(如每季度一次)评审,并为下一个季度提供资金,而不是按预先确定的项目期限或年度预算提供资金。如能更频繁地进行评估和提供资金,企业就能更加密切地控制总体进展、方向和决策。
与风险投资类似,对交付的价值进行定期评审可将资金直接投向提供预期价值的产品,并减少或缩减对业绩不佳的举措的投资。这种提供资金模式使各组织能够寻求新的市场机会并利用成功开展的工作,同时对不可避免的新举措失败的百分比,降低风险敞口。
▶ 利用项目集管理结构。与支持以客户为中心的产品的稳定团队合作的从业者,可以应用项目集管理结构来管理长期运作的举措。项目集可很好地适应市场变化并聚焦于客户收益。它们的运作时间也通常比单个项目更长。
《项目集管理标准》可应对优先级排序的持续变更,具体如下“项目和项目集之间的主要区别在于,项目集内部认识到,随着组件的成果分别实现,可能需要自适应地优化交付收益的策略。交付项目集收益的最佳机制最初可能模糊不清或不确定。”
对许多管理产品交付的组织而言,接受这种对前期不确定性、适应需要、聚焦于收益和更长的时间框架,可能使项目集比项目更适合。
许多传统的产品行业(如基础设施、航空航天和汽车)都使用项目集管理指南和框架。这些行业利用项目集来统一方向和整合各个组件的活动(项目集、子项目集和项目的活动)。例如,针对整个生命周期内最大化平台投资回报率的功能,拥有技术平台的组织可以使用项目集管理和产品管理进行优先级排序和监督。稳定且有连续性的开发团队能够开展以客户为中心的增值特性和功能的工作。然后,项目团队对设备升级,并与新系统或增强后的系统相连接。运营团队可以对用户接口问题进行故障排除,并帮助客户适应新的特性。当组织中已经存在项目集结构时,转向这些产品管理结构并不要求每个人形成新的思维方式或采用新的工作方式。
表 X4-2. 项目、项目集和产品的独特特征
对项目管理和产品管理采用整合视角的组织,可将审视项目集管理框架作为基石,进而从中受益。项目集接受前期不确定性、适应需要、聚焦于收益和更长的时间框架,能够与产品思维更好地保持一致性。
2.5.6.2 签订合同
最后,双方达成协议并签订合同。签订合同工具的类型取决于采购规模、工作范围的稳定性以及各组织的风险承受力。
对于某些可交付物采用适应型方法,而其他可交付物采用预测型方法的项目,总体合同可以使用主协议,适应性工作可以放在附录或增补中。这样一来,如果变更发生在适应性范围中,而不会对总体合同造成影响。
一旦选定供应商,就会对项目计划和文件进行更新,以包含供应商日期、资源、成本、质量要求、风险等。从这时起,供应商将成为项目干系人。在整个项目期间,干系人绩效域和测量绩效域中的信息将适用于供应商。
采购可以在项目期间的任何时候进行。所有采购活动都将被整合进项目运行之中。
2.5.7 监督新工作和变更
适应型项目中,可以预期到工作会有所演变和调整。因此,可以根据需要将新工作增加到产品待办事项列表中。但是,如果增加的工作多于正在完成的工作,或者增加的工作与正在完成的工作数量相同,项目将继续进行而不会结束。对于增加范围、对预算的影响以及项目团队成员可用性,项目经理会与产品负责人合作,管理这方面的期望。产品负责人会持续对项目待办事项列表进行优先级排序,以便完成优先级高的事项。如果进度或预算受到限制,当优先级最高的事项交付完毕,产品负责人即可认为项目已完成。
在预测型项目中,项目团队会积极管理工作变更,以确保范围基准中仅包含已批准的变更。然后,对范围的任何变更都将伴随对人员、资源、进度和预算的适当变更。范围变更可能会增加不确定性;因此,任何变更请求都应伴随对因范围扩大或变更而造成的任何新风险的评估。项目经理应与变更控制委员会和变更的请求者合作,通过变更控制流程指导变更请求。已批准的变更会被整合到适用的项目规划文件、产品待办事项列表和项目范围中,也会与适合的干系人沟通这些变更。
2.6.2.2 范围定义
随着需求被识别,满足这些需求的范围也应被定义。范围是项目所提供的产品、服务和结果的总和。随着范围被定义,还需要识别更多的需求。因此,与需求一样,范围可以预先被定义好,也可以随着时间的推移而演变,或可以被发现。
▶ 范围分解。可以使用范围说明书来阐明范围,以识别与项目关联的主要可交付物以及每个可交付物的验收标准。还可以通过使用工作分解结构 (WBS) 将范围分解为较低层级的细节,从而详细说明范围。WBS 是对项目团队为实现项目目标、创建所需可交付物,而需要实施的全部工作范围的层级分解。该层级往下的每一个层级代表着关于可交付物的更详细的信息以及生成可交付物所需的工作。
详细说明范围的另一种方法是在敏捷章程、路线图或作为产品层级结构的一部分来确定项目的各个主题。这些代表着大量用户价值的主题可表示为用户故事,该用户故事与诸如功能、数据源,或安全级别等常见因素相关。为了完成这些主题,项目团队会开发史诗故事。史诗故事是一种逻辑容器,用于容纳因太大而无法在一个迭代中完成的较大的用户故事。史诗故事可以分解为多个特性,这些特性是一组通常被描述为简短的短语或功能的相关需求,代表着产品的特定行为。每个特性都有多个用户故事。用户故事是向特定用户提供的成果的简要描述,而且确保可以通过对话澄清细节。项目团队会在负责的最后责任时刻定义故事细节,以避免在范围发生变更时造成规划浪费。故事可清晰且简洁地描述从最终用户的角度编写的需求。
▶ 完成可交付物。根据所使用的方法,有不同的方式来描述组件或项目的完成情况:
▹ 验收或完成的标准。在客户验收可交付物之前,或在项目被视为完成之前需要满足的标准通常会记录在范围说明书中。
▹ 技术绩效测量指标。产品的技术规范可能记录在单独的规范文件中,也可能记录为 WBS 的扩展。这一扩展称为 WBS 字典,它详细说明了 WBS 中每项可交付物(工作包)的信息。
▹ 完成的定义。可将完成的定义与适应型方法一起使用,特别是在软件开发项目中。它是为了考虑可交付物能供客户使用,而须达到的所有标准的检查清单。
2.6.2.3 完成的目标不断移动
在不确定和快速变化的环境中运行的项目面临着“足够好可以发布”或“已完成”的目标可能会发生变化的情况。在竞争对手频繁发布新产品的市场中,新的发布中计划的特性可能会有所更新。同样,新的技术趋势(例如移动设备或可穿戴设备)可能会触发方向变化或引入新的需求。
在这些环境中,正在交付或“已完成”的项目目标的定义正在不断移动。项目团队会跟踪计划的项目目标实现率(相对于进度完成率)。完成项目耗费的时间越长,与“完成”的项目目标的距离就越远。这有时被称为“完成漂移”。
图 2-21 显示了一个开发新智能手表的场景。初始进度计划显示,开发具有一组初始功能和特性的手表需要 12 个月。随着竞争对手类似产品的上市,在这组初始功能和特性的基础上不断扩增,以便紧跟市场变化,这将上市日期推迟至第 14 个月。第 13 个月,另一个竞争对手上市了一款功能更多的产品。增加这些功能会将上市日期延迟到第 16 个月。项目团队将在某个时点决定是否发布产品(即使它没有最新特性),或者在上市之前继续对这些特性做出更新。
图 2-21. 开发智能手表的场景
在更加稳定的环境中运行的项目通常会面临“范围蔓延”。在这种情况下,将接受额外的范围或需求,而不对相应的进度、预算或资源需要等做出调整。为了应对范围蔓延,项目团队会使用变更控制系统,在该系统中评估所有变更,以了解变更为项目带来的潜在价值,及实现该价值所需的潜在资源、时间和预算。然后,项目团队将这些变更提交给项目治理机构、产品负责人或高管发起人,以待其正式批准。
2.6.3.1 质量成本
与产品或可交付物相关的属性包括但不限于:
▶ 合规性/关键性。什么程度的过程严格性和质量保证是合适的?
▶ 产品/可交付物的类型。产品是否为人所知且为有形之物,例如像一幢建筑那样易于识别和描述?或者是无形之物,例如软件或者新药设计?
▶ 行业市场。项目产品或可交付物服务于哪个市场?该市场是否受到严格监管,发展迅速或缓慢?竞争对手和所在企业的情况如何?
▶ 技术。技术是稳定且成熟,或是发展迅速且存在过时的风险?
▶ 时间框架。项目时间框架很短(数周或数月)还是很长(数年)?
▶ 需求的稳定性。核心需求出现变更的可能性有多大?
▶ 安全性。产品业务的要素是否属于保密或机密信息?
▶ 增量交付。这是项目团队可以用增量方式开发并获得干系人反馈的东西,还是在接近完成之前难以评估的东西?
2.6.3.2 变更成本
发现缺陷的时间越晚,纠正缺陷的成本就越高。这是因为设计和开发工作通常已经基于有缺陷的组件而进行。此外,随着生命周期的进展,活动的调整成本有所增加,因为更多的干系人会受到影响。变更成本曲线可以描述这种现象(见图 2-22)。
图 2-22. 变更成本曲线
为了应对变更成本曲线的影响,项目团队会设计项目过程,以便将质量纳入进来。这种方法可以包括质量分析师与设计师和工程师合作,了解并确定如何在项目生命周期的每个步骤以最佳方式达到质量要求。积极主动地开展质量工作有助于避免较高的变更成本,该成本与解决生命周期后期发现的质量问题相关。与解决影响数百个单元的组件问题或者召回影响数千客户的产品相比,解决两名工程师之间的设计问题要更快、更具成本效率。
2.7.1.2 有效度量指标
项目测量指标有助于项目团队实现项目目标。然而,会存在一些与测量有关的陷阱。认识到这些陷阱有助于最小化其负面影响。
▶ 霍桑效应 (Hawthorne effect)。霍桑效应指出,测量某种事物的行动会对行为产生影响。因此,制定度量指标时要慎重。例如,仅测量项目团队可交付物的输出,会鼓励项目团队专注于创建更多数量的可交付物,而不是专注于提供更高客户满意度的可交付物。
▶ 虚荣指标 (Vanity metric)。似乎会显示某些结果但不提供决策所需有用信息的测量指标。测量网站的页面访问量不如测量新访问者的数量有用。
▶ 士气低落。如果设定了无法实现的测量指标和目标,项目团队的士气可能会因持续未能达到目标而下降。设定拓展性目标和激励人心的测量指标是可以接受的,但人们也希望看到他们的辛勤工作得到认可。不现实或无法实现的目标可能适得其反。
▶ 误用度量指标。尽管存在用于测量绩效的度量指标,人们可能会扭曲测量指标或专注于错误的事情。范例包括:
▹ 专注不太重要的度量指标,而不是最重要的度量指标;
▹ 专注于做好短期测量指标的工作,而以牺牲长期度量指标为代价;
▹ 为了改进绩效指标,开展易于完成的无序活动。
▶ 确认偏见。作为人类,我们倾向于寻找并看到支持我们原有观点的信息。这可能会导致我们对数据作出错误解释。
▶ 相关性与因果关系对比。解释测量数据的一个常见错误是将两个变量之间的相关性与一个变量导致了另一个变量的因果性混淆起来。例如,看到项目进度落后且预算超支,可能就会推断是预算超支导致了进度问题。这并非真实情况,而且也并非进度落后导致了预算超支。相反,可能还有其他相关因素未考虑进来,例如估算技能、管理变更的能力和积极地管理风险。
我们除了警惕与不适当的测量指标相关的危险外,了解与度量指标相关的陷阱有助于我们制定有效的度量指标。
2.7.4 测量陷阱
项目测量指标有助于项目团队实现项目目标。然而,会存在一些与测量有关的陷阱。认识到这些陷阱有助于最小化其负面影响。
▶ 霍桑效应 (Hawthorne effect)。霍桑效应指出,测量某种事物的行动会对行为产生影响。因此,制定度量指标时要慎重。例如,仅测量项目团队可交付物的输出,会鼓励项目团队专注于创建更多数量的可交付物,而不是专注于提供更高客户满意度的可交付物。
▶ 虚荣指标 (Vanity metric)。似乎会显示某些结果但不提供决策所需有用信息的测量指标。测量网站的页面访问量不如测量新访问者的数量有用。
▶ 士气低落。如果设定了无法实现的测量指标和目标,项目团队的士气可能会因持续未能达到目标而下降。设定拓展性目标和激励人心的测量指标是可以接受的,但人们也希望看到他们的辛勤工作得到认可。不现实或无法实现的目标可能适得其反。
▶ 误用度量指标。尽管存在用于测量绩效的度量指标,人们可能会扭曲测量指标或专注于错误的事情。范例包括:
▹ 专注不太重要的度量指标,而不是最重要的度量指标;
▹ 专注于做好短期测量指标的工作,而以牺牲长期度量指标为代价;
▹ 为了改进绩效指标,开展易于完成的无序活动。
▶ 确认偏见。作为人类,我们倾向于寻找并看到支持我们原有观点的信息。这可能会导致我们对数据作出错误解释。
▶ 相关性与因果关系对比。解释测量数据的一个常见错误是将两个变量之间的相关性与一个变量导致了另一个变量的因果性混淆起来。例如,看到项目进度落后且预算超支,可能就会推断是预算超支导致了进度问题。这并非真实情况,而且也并非进度落后导致了预算超支。相反,可能还有其他相关因素未考虑进来,例如估算技能、管理变更的能力和积极地管理风险。
我们除了警惕与不适当的测量指标相关的危险外,了解与度量指标相关的陷阱有助于我们制定有效的度量指标。
2.7.7 与其他绩效域的相互作用
测量绩效域与规划绩效域、项目工作绩效域和交付绩效域相互作用,因为计划构成了将交付和计划进行比较的基础。测量绩效域可以通过提供最新信息来支持作为规划绩效域一部分的活动,从而使经验教训能够反映针对更新计划的有利或不利信息。在项目团队成员制定计划并创建可测量的可交付物时,团队绩效域和干系人绩效域会相互作用。
当不可预测的事件发生时(无论是积极事件还是消极事件),它们会影响项目绩效,从而影响项目的测量和度量指标。应对已发生的不确定事件造成的变更包括了更新受此影响的测量。不确定性绩效域中的活动(例如识别风险和机会)可以根据绩效测量启动。
作为项目工作的一部分,应与项目团队和其他干系人合作,以便制定度量指标、收集数据、分析数据、做出决策并报告项目状态。
2.8.5.1 威胁
图 3-4. 有效地干系人参与
干系人可能是能影响项目组合、项目集或项目的决策、活动或成果的个人、群体或组织,以及会受或自认为会受这些决策、活动或成果影响的个人、群体或组织。干系人还以积极或消极的方式直接或间接影响项目,及其绩效或成果。
干系人可以影响项目的许多方面,包括,但不限于:
▶ 范围 / 需求 — 通过表明需要增加、调整或删除范围和/或项目需求的要素;
▶ 进度 — 通过提出加快交付的想法,或者放慢或停止交付关键项目活动;
▶ 成本 — 通过帮助减少或取消计划支出,或者增加会提高成本或需要额外资源的步骤、需求或限制;
▶ 项目团队 — 通过限制或允许接触具备交付预期成果所需技能、知识和经验并可推动学习型文化的人员;
▶ 计划 — 通过为计划提供信息,或倡导对商定的活动和工作作出变更;
▶ 成果 — 通过开展或阻止实现为期望成果所需的工作;
▶ 文化 — 通过建立或影响甚至定义项目团队和更广泛组织参与的程度和特点;
▶ 收益实现 — 通过制定和确定长期目标,从而使项目交付预期的确定价值;
▶ 风险 — 通过界定项目的风险临界值,并参与后续的风险管理活动;
▶ 质量 — 通过识别和要求提供质量需求;
▶ 成功 — 通过定义成功因素并参与对成功的评估。
在项目的整个生命周期内,干系人可能会参与进来,也可能会退出。此外,随着时间的推移,干系人的利益、影响或作用可能也会有所变化。干系人(特别是那些影响力高且对项目持不赞同或中立观点的干系人)
需要有效地参与进来,以便项目团队了解他们的利益、顾虑和权利。然后,项目团队可以通过有效参与和支持来应对这些顾虑,这样就可能会成功地实现项目成果。
从项目开始到结束,识别、分析并主动争取干系人参与有助于项目取得成功。
项目团队是一组干系人。这些干系人会与其他干系人互动,以理解、思考、沟通并回应他们的利益、需要和意见。
有效果且有效率的参与和沟通包括确定干系人想要或应该进行参与的方式、时间、频率和情形。沟通是参与的关键部分,但深入的参与可让人了解他人的想法,吸收其他观点以及协同努力制定共同的解决方案。参与包括通过频繁的双向沟通建立和维持牢固的关系。它鼓励通过互动会议、面对面会议、非正式对话和知识共享活动进行协作。
干系人参与在很大程度上依赖于人际关系技能,包括积极主动、正直、诚实、协作、尊重、同理心和信心。这些技能和态度可以帮助每个人适应工作和彼此适应,从而增加成功的可能性。
参与有助于项目团队发现、收集和评估信息、数据和意见。这可形成共识和一致性,从而实现项目成果。此外,这些活动还有助于项目团队对项目进行裁剪,以识别、调整和应对不断变化的环境。
在整个项目进行期间,项目团队会积极让其他干系人参与,以最小化潜在消极影响并最大化积极影响。除了提高干系人满意度外,让干系人参与还使项目团队有机会取得更出色的项目绩效和成果。最后,其他干系人的参与有助于项目团队找到更能为更广泛的干系人接受的解决方案。
3.4 裁剪过程
裁剪过程并非单一的,一次性的过程。在渐进明细过程中,项目团队的工作方式、产品或可交付物的演变方式,以及其他知识等问题将表明哪些进一步的裁剪可以带来改进。审查点、阶段关口和回顾会议都提供了必要的检查和调整过程、开发方法和交付频率的机会。
让项目团队参与过程改进可以培养主人翁意识,并表现出对实施持续改进和质量的承诺。让项目团队参与寻找和实施改进措施也表明了对他们自己的技能和建议以及赋能的信任。项目团队参与裁剪展示了创新和改进而不是安于现状的思维模式。
图 3-6 中显示了增加、取消和变更这些过程的概念。
图 3-6. 实施持续改进
组织的裁剪方式本身就可以被裁剪。但大多数组织采取了以上描述的四个步骤中的部分或全部步骤。他们使用的要素包括选择初始方法、对组织进行裁剪、对项目进行裁剪以及实施持续改进(如图 3-7 所示)。
图 3-7. 裁剪过程
3.4.3.1 产品/可交付物
与产品或可交付物相关的属性包括但不限于:
▶ 合规性/关键性。什么程度的过程严格性和质量保证是合适的?
▶ 产品/可交付物的类型。产品是否为人所知且为有形之物,例如像一幢建筑那样易于识别和描述?或者是无形之物,例如软件或者新药设计?
▶ 行业市场。项目产品或可交付物服务于哪个市场?该市场是否受到严格监管,发展迅速或缓慢?竞争对手和所在企业的情况如何?
▶ 技术。技术是稳定且成熟,或是发展迅速且存在过时的风险?
▶ 时间框架。项目时间框架很短(数周或数月)还是很长(数年)?
▶ 需求的稳定性。核心需求出现变更的可能性有多大?
▶ 安全性。产品业务的要素是否属于保密或机密信息?
▶ 增量交付。这是项目团队可以用增量方式开发并获得干系人反馈的东西,还是在接近完成之前难以评估的东西?
3.4.3.2 项目团队
Allan Drexler 和 David Sibbet 开发了团队绩效模型,共有七个步骤。第 1 步至第 4 步描述了建立项目团队过程中的各个阶段,第 5 步至第 7 步则涵盖了项目团队的可持续性和绩效。
▶ 第 1 步 : 确定方向“确定方向”回答了为什么这个问题。在这一阶段,项目团队会了解项目的目的和使命。这通常发生在开工会议上,或者会记录在商业论证、项目章程或精益创业画布中。
▶ 第 2 步 : 建立信任“建立信任”回答了谁这个问题。这一阶段阐明了谁会加入项目团队以及每个人会带来什么样的技能和能力。它还可以包括关于可能未加入项目团队但对项目团队有影响的关键干系人的信息。
▶ 第 3 步 : 澄清目标“澄清目标”回答了什么这个问题。在这一阶段,项目团队详细阐述了高层级的项目信息。这可能包括进一步了解干系人的期望、需求、假设条件和可交付物的验收标准。
▶ 第 4 步 : 承诺“承诺”解决了如何这个问题。在这一阶段,项目团队开始定义实现目标的计划。这可以包括里程碑进度计划、发布计划、高层级预算、资源需求等。
▶ 第 5 步 : 实施。高层级计划会分解为更详细的层级,例如详细的进度计划或待办事项列表。项目团队开始共同努力生成可交付物。
▶ 第 6 步 : 高绩效。项目团队合作一段时间后,项目团队成员的绩效达到了很高的水平。他们可以很好地协同工作,无需太多监督,并且项目团队会产生协同效应。
▶ 第 7 步 : 重新开始“重新开始”是应对项目团队或项目变更的阶段。可交付物、干系人、环境、项目团队领导或团队成员资格可能会发生变化。这会使项目团队考虑过去的行为和行动是否仍然足够,或者团队是否需要返回到以前的某一阶段,以重新设立期望和合作方式。
3.4.3.4 实施持续改进
裁剪过程并非单一的,一次性的过程。在渐进明细过程中,项目团队的工作方式、产品或可交付物的演变方式,以及其他知识等问题将表明哪些进一步的裁剪可以带来改进。审查点、阶段关口和回顾会议都提供了必要的检查和调整过程、开发方法和交付频率的机会。
让项目团队参与过程改进可以培养主人翁意识,并表现出对实施持续改进和质量的承诺。让项目团队参与寻找和实施改进措施也表明了对他们自己的技能和建议以及赋能的信任。项目团队参与裁剪展示了创新和改进而不是安于现状的思维模式。
图 3-6 中显示了增加、取消和变更这些过程的概念。
图 3-6. 实施持续改进
组织的裁剪方式本身就可以被裁剪。但大多数组织采取了以上描述的四个步骤中的部分或全部步骤。他们使用的要素包括选择初始方法、对组织进行裁剪、对项目进行裁剪以及实施持续改进(如图 3-7 所示)。
图 3-7. 裁剪过程
3.5.8 测量
Jeff Hiatt 开发了 ADKAR 模型,该模型重点关注个人在适应变革时所经历的五个连续步骤:
▶ 第 1 步 : 认知。此步骤确定了为什么需要进行变革。
▶ 第 2 步 : 渴望。一旦人们知道为什么需要进行变革,就需要有参与和支持变更的渴望。
▶ 第 3 步 : 知识。人们需要了解如何进行变革。这包括了解新的过程和体系,以及新的角色和职责。知识可以通过培训和教育来传授。
▶ 第 4 步 : 能力。在这一步骤中,知识来自于动手实践,以及根据需要获得专业知识和帮助。
▶ 第 5 步 : 巩固。巩固可为维持变革提供支持。这可以包括奖励、认可、反馈和测量。
4.2.4.2 ADKAR 模型
Jeff Hiatt 开发了 ADKAR 模型,该模型重点关注个人在适应变革时所经历的五个连续步骤:
▶ 第 1 步 : 认知。此步骤确定了为什么需要进行变革。
▶ 第 2 步 : 渴望。一旦人们知道为什么需要进行变革,就需要有参与和支持变更的渴望。
▶ 第 3 步 : 知识。人们需要了解如何进行变革。这包括了解新的过程和体系,以及新的角色和职责。知识可以通过培训和教育来传授。
▶ 第 4 步 : 能力。在这一步骤中,知识来自于动手实践,以及根据需要获得专业知识和帮助。
▶ 第 5 步 : 巩固。巩固可为维持变革提供支持。这可以包括奖励、认可、反馈和测量。
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.3 会议和活动
会议是吸引项目团队和其他干系人参与的重要方式。它们是整个项目的主要沟通方式。
▶ 待办事项列表细化。在待办事项列表的细化会议上,项目团队会以渐进明细方式编制待办事项列表并(重新)明确其中各事项的优先级,以确定在即将到来的迭代中完成的工作。
▶ 投标人会议。在准备投标或建议书之前,与潜在卖方举行的会议,以便确保所有潜在供应商对本次采购都有清楚且一致的理解。该会议也称承包商会议、供应商会议或投标前会议。
▶ 变更控制委员会。变更控制委员会会议包括负责审核、评估、批准、推迟或拒绝项目变更的人员。
本次会议上所做的决定将被记录下来并传达给有关的干系人。此会议也可称为变更控制会议。
▶ 每日站会。每日站会是简短的协作会议,在该会议期间,项目团队会审查前一天的进展,宣布当天的计划,并强调指出遇到或预见的任何障碍。该会议也可称为“每日例会”。
▶ 迭代规划会议。迭代规划会议用于澄清待办事项列表中事项的详细信息、验收标准以及实现即将履行的迭代承诺所需的工作投入。此会议也可称为冲刺规划会议。
▶ 迭代审查会议。迭代审查会议是在一个迭代结束时举行,旨在展示在该迭代期间完成的工作。此会议也可称为冲刺审查会议。
▶ 开工。开工会议是项目开始执行时举行的会议,项目团队成员和其他关键干系人会聚在一起,正式设定期望、达成共识并开始工作。它会确立项目、阶段或迭代的开始。
▶ 经验教训会议。经验教训会议用于识别和分享在项目、阶段或迭代过程中获得的知识,其重点是关注提高项目团队的绩效。除了良好的做法和产生非常有利结果的情况外,此会议还可以讨论原本可以处理得更好的事情。
▶ 规划会议。规划会议用于创建、详细制订或审核计划,并获得对计划的承诺。
▶ 项目收尾。项目收尾会议用于获得发起人、产品负责人或客户对交付范围的最终验收。此会议表明了产品交付工作已完成。
▶ 项目审查。项目审查会议是一种在过程或项目结束时开展的活动,旨在评估状态、评估所交付的价值,并确定项目是否已准备好进入下一个阶段或移交至运营。
▶ 发布规划。发布规划会议是确定发布或改变产品、可交付物或价值增量的高层级计划。
▶ 回顾会议。回顾会议是定期举行的研讨会,参会者探讨其工作和结果,以便改进流程和产品。回顾会议是经验教训会议的一种形式。
▶ 风险审查。一种分析现有风险的状态并识别新风险的会议。这包括确定风险是否仍处于活跃状态以及风险属性(如概率、影响、紧急程度等)是否已发生了变化。并对风险应对措施进行评估,以确定它们是否有效或是否应更新。可能会识别和分析新的风险,也可能会关闭不再活跃的风险。风险再评估是风险审查会议的一个示例。
▶ 状态会议。状态会议是定期举行的会议,旨在交流和分析项目当前进展情况及其绩效方面的信息。
▶ 指导委员会。资深的干系人为项目团队提供指导和支持,并做出项目团队权限以外的决策的会议。
4.6.2 日志和登记册
日志和登记册用于记录项目不断演变的方面。它们会在整个项目期间得到更新。日志和登记册这两个词有时可以互换使用。我们经常看到用风险登记册或风险日志这两个词是指同一个工件。
▶ 假设日志。假设条件是没有证据或证明即被认为正确、真实或确定的因素。制约因素是对管理项目、项目集、项目组合或过程的方案进行限制的因素。假设日志记录了整个项目期间的所有假设条件和制约因素。
▶ 待办事项列表。待办事项列表是待完成工作的有序列表。项目可能有产品待办事项列表、需求待办事项列表、障碍因素待办事项列表等。待办事项列表中的事项会被确定优先级。然后为即将到来的迭代安排优先级高的工作。
▶ 变更日志。变更日志是项目过程中提交的变更及其当前状态的综合清单。变更可以是对任何正式受控的可交付物、项目管理计划组件或项目文件的修改。
▶ 问题日志。问题是可以对项目目标产生影响的当前条件或情形。问题日志会被用于记录和监督与尚未解决的问题相关的信息。问题将被分配给责任方进行跟进和解决。
▶ 经验教训登记册。经验教训登记册可被用于记录在某一项目、阶段或迭代期间所获知识的项目文件,以便未来可将这些知识用于提高团队和组织的绩效。
▶ 风险调整待办事项列表。风险调整待办事项列表包含了产品所需工作,以及应对威胁和机会的行动。
▶ 风险登记册。风险登记册是记录风险管理过程输出的存储文件。风险登记册中的信息可以包括相关管理风险的负责人,概率、影响、风险评分、计划的风险应对,和用来获得关于单个风险的高层级理解的其他信息。
▶ 干系人登记册。干系人登记册会记录与项目干系人有关的信息,其中包括对项目干系人的评估和分类。
4.6.5 基准
基准是经过批准的工作产品或计划的版本。会将实际绩效与基准进行比较,以识别偏差。
▶ 预算。成本基准是对整个项目、任一工作分解结构组件或任一进度活动所做的经批准的估算。
▶ 里程碑进度计划。用于显示有计划日期的里程碑,是一种进度计划类型。
▶ 绩效测量基准。整合在一起的范围、进度和成本基准被用来与项目执行情况相比较,以管理、测量和控制项目绩效。
▶ 项目进度计划。项目进度计划是进度模型的输出,为各个相互关联的活动标注了计划日期、持续时间、里程碑和资源等信息。
▶ 范围基准。此基准是经过批准的范围说明书、工作分解结构 (WBS) 和相应的 WBS 词典,能够通过正式的变更控制程序进行变更,并被用作与实际结果进行比较的依据。
附录X2 发起人
在不确定和快速变化的环境中运行的项目面临着“足够好可以发布”或“已完成”的目标可能会发生变化的情况。在竞争对手频繁发布新产品的市场中,新的发布中计划的特性可能会有所更新。同样,新的技术趋势(例如移动设备或可穿戴设备)可能会触发方向变化或引入新的需求。
在这些环境中,正在交付或“已完成”的项目目标的定义正在不断移动。项目团队会跟踪计划的项目目标实现率(相对于进度完成率)。完成项目耗费的时间越长,与“完成”的项目目标的距离就越远。这有时被称为“完成漂移”。
图 2-21 显示了一个开发新智能手表的场景。初始进度计划显示,开发具有一组初始功能和特性的手表需要 12 个月。随着竞争对手类似产品的上市,在这组初始功能和特性的基础上不断扩增,以便紧跟市场变化,这将上市日期推迟至第 14 个月。第 13 个月,另一个竞争对手上市了一款功能更多的产品。增加这些功能会将上市日期延迟到第 16 个月。项目团队将在某个时点决定是否发布产品(即使它没有最新特性),或者在上市之前继续对这些特性做出更新。
图 2-21. 开发智能手表的场景
在更加稳定的环境中运行的项目通常会面临“范围蔓延”。在这种情况下,将接受额外的范围或需求,而不对相应的进度、预算或资源需要等做出调整。为了应对范围蔓延,项目团队会使用变更控制系统,在该系统中评估所有变更,以了解变更为项目带来的潜在价值,及实现该价值所需的潜在资源、时间和预算。然后,项目团队将这些变更提交给项目治理机构、产品负责人或高管发起人,以待其正式批准。
X3.2 PMO价值主张—为什么要确立价值主张?
各组织会出于各种原因设立 PMO,但都会考虑一项核心收益:在进度、成本、质量、风险和其他方面改进项目管理PMO 在使工作与战略目标保持一致方面具有许多潜在角色:争取干系人参与和协作、培养人才以及实现项目投资的价值。
PMO 可以采用多种形式。了解在组织中如何使用 PMO 以及所承担的角色和职责,这样可以阐明PMO 能交付的一系列的收益:
▶ 一些 PMO 可提供项目管理指导,支持项目交付方式保持一致性。这些 PMO 可以提供良好实践的指南、模板和示例以及培训和教练。标准化的方法和工具有助于呈现各个项目的共同业务状况,并促进做出超越个别项目考虑问题的决策。这种 PMO 通常存在于刚刚开始改善项目管理能力的组织中。
▶ PMO 可以为规划活动、风险管理、项目绩效跟踪和类似活动提供项目支持服务PMO 的这种共享服务模式通常存在于具有独立或多元化业务部门的组织中,在为交付提供支持的同时,这些组织希望保持对其项目的更直接控制。
▶ PMO 可以是部门或业务单元的一部分,并监督项目的组合。监督可包括这样的活动:要求商业论证以便启动项目、分配财务资源和其他资源来交付项目、批准变更项目范围或活动的请求以及类似职能等。此类 PMO 可对项目进行集中化管理。这种结构存在于开展多个项目的部门,并提供重要战略结果(如 IT 能力或新产品开发)的组织中。
▶ 一个组织可能有一个企业级 PMO (EPMO),它将组织战略的实施与包括项目集和项目中交付具体结果、变更或产品的项目组合层级投资联系起来。这一结构存在于具有成熟项目管理能力的组织中,这些能力是直接关联的以实现组织战略和广泛的商业目标。
▶ 具有较为扁平化的结构、以客户为中心的举措和更多使用适应型交付方法的组织,可能会采用敏捷卓越中心 (ACoE) 或价值交付办公室 (VDO) 的结构ACoE/VDO 充当着促进者的角色,而非管理或监督职能。它侧重于教练团队,在整个组织内培养敏捷技能和能力,以及辅导发起人和产品负责人更有效地承担这些角色。这种类型的结构出现在更加去中心化的组织中,在这种组织中,团队需要对不断变化的客户需要做出快速响应。
PMO 可分为多个层级。例如,EPMO 可能具有从属的PMO 和 VDO,它们设置于特定的部门中。此类分级为在 EPMO 层级保持战略一致性,以及为在部门级 PMO 或 VDO 中特定的项目管理能力提供支持。
任何类型的 PMO 或 VDO 都是基于组织需要设立的。有助于塑造 PMO 或 VDO 的关键影响因素包括:所交付项目的类型、组织规模、组织结构、集中/分散决策的程度以及企业文化。当组织的需要随着时间发生变化,PMO 和 VDO 会相应发生演变。例如,PMO 可能转变为 VDO,或者 PMO 可能在履行完毕其章程后关闭。
X4.3 对项目交付实践的影响
随着市场从单一项目交付模式转向持续交付模式,一些组织正在寻找交付单一产品、变更或服务的临时性项目结构的替代方案。其实,它们正在寻找的是交付结构,该交付结构非常注重以客户为中心,认识到技术的快速发展,并与忠诚客户的持续服务和收入流保持一致。
为了价值交付,这些因素引起人们对产品管理生命周期的兴趣增加,并向其转变。产品管理采用更长生命周期的视角,包括支持和维持同一团队,并与其共同持续发展。稳定的团队在复杂而独特的领域中尤为重要,例如具有嵌入式软件的这类系统中,知识转移既耗时又昂贵。将关注点转向产品管理正在促使一些项目导向型组织调整其交付模式。
X4.4 关于产品管理的组织考虑因素
转向长期运作、基于产品的环境的组织可以利用多种策略来调整和协调产品管理。三种策略包括但不限于(另请参见图 X4-3):
图 X4-3. 针对持续价值交付的支持策略
▶ 建立稳定的团队。不要在初始开发完成后就解散团队,而是利用该团队与指定的产品负责人或该团队中可反映客户观点的人一起维持和发展产品。这就消除了知识转移的需要,并减轻了由于失去隐性知识而导致未来的产品增强被延迟的风险。
长期团队比短期团队还能更好地增强市场意识、客户洞察力和客户同理心。这有助于维持以客户为中心和客户忠诚度,并建立竞争优势。当人们知道他们将负责维护和增强某一产品时,他们不太可能走捷径来准备产品发布。因此,长期服务的团队比开发后即移交产品的团队,更能提升产品的质量、可维护性和可扩展性。这些因素反过来又有助于创造价值并持续价值交付。
在客户现场开发和部署初始产品的合作伙伴或承包商,他们应该进行有效的变更管理,以确保客户能够在产品移交后有能力维护产品。作为移交规划的一部分,可能要包括关于在接收组织内建立一个团队的讨论,以便在产品的整个生命周期内支持和发展产品。
▶ 增量式的指导和提供资金。应考虑更频繁的(如每季度一次)评审,并为下一个季度提供资金,而不是按预先确定的项目期限或年度预算提供资金。如能更频繁地进行评估和提供资金,企业就能更加密切地控制总体进展、方向和决策。
与风险投资类似,对交付的价值进行定期评审可将资金直接投向提供预期价值的产品,并减少或缩减对业绩不佳的举措的投资。这种提供资金模式使各组织能够寻求新的市场机会并利用成功开展的工作,同时对不可避免的新举措失败的百分比,降低风险敞口。
▶ 利用项目集管理结构。与支持以客户为中心的产品的稳定团队合作的从业者,可以应用项目集管理结构来管理长期运作的举措。项目集可很好地适应市场变化并聚焦于客户收益。它们的运作时间也通常比单个项目更长。
《项目集管理标准》可应对优先级排序的持续变更,具体如下“项目和项目集之间的主要区别在于,项目集内部认识到,随着组件的成果分别实现,可能需要自适应地优化交付收益的策略。交付项目集收益的最佳机制最初可能模糊不清或不确定。”
对许多管理产品交付的组织而言,接受这种对前期不确定性、适应需要、聚焦于收益和更长的时间框架,可能使项目集比项目更适合。
许多传统的产品行业(如基础设施、航空航天和汽车)都使用项目集管理指南和框架。这些行业利用项目集来统一方向和整合各个组件的活动(项目集、子项目集和项目的活动)。例如,针对整个生命周期内最大化平台投资回报率的功能,拥有技术平台的组织可以使用项目集管理和产品管理进行优先级排序和监督。稳定且有连续性的开发团队能够开展以客户为中心的增值特性和功能的工作。然后,项目团队对设备升级,并与新系统或增强后的系统相连接。运营团队可以对用户接口问题进行故障排除,并帮助客户适应新的特性。当组织中已经存在项目集结构时,转向这些产品管理结构并不要求每个人形成新的思维方式或采用新的工作方式。
表 X4-2. 项目、项目集和产品的独特特征
对项目管理和产品管理采用整合视角的组织,可将审视项目集管理框架作为基石,进而从中受益。项目集接受前期不确定性、适应需要、聚焦于收益和更长的时间框架,能够与产品思维更好地保持一致性。