范围管理

总论

范围管理以产出、成果与收益的形式,识别、定义与控制目标。它的目标是:

  • 识别利益相关方的要求与需求;
  • 将能满足达成共识的要求的产出、成果与收益具体化;
  • 生命周期中始终维护范围。

范围是应该交付的产出、成果与收益的总和。范围的复杂度是把工作作为项目、项目群还是项目组合来加以管理的主要区分因素。

识别流程中的一个关键要素,是决定实现目标是否需要改变正常经营。

低层次变更的管理,用典型的项目治理结构就能很好地实现。更大范围与更复杂的变革,是表明项目群(在有些情况下是项目组合)治理结构更为合适的指标。

用哪种方法来管理范围,取决于三件事:目标的性质(产出、成果或收益)、目标的可定义性和工作的复杂度。

项目范围通常只包括产出,但当复杂度比较低的时候,范围可能扩展至包括收益。项目群的范围总是包括收益实现以及随之而来的变更管理。标准的项目组合的范围是由它的项目和项目群定义的,然而结构化项目组合的范围是由设计它要实现的战略目标来定义的。

范围管理是由五个主要方面组成的,这五个方面的工作一起识别、定义、控制范围:

  • 要求管理捕捉与分析利益相关方对工作目标的观点。要求是“不涵盖解决方案”的,例如它们描述利益相关方的要求与需求,但不决定满足要求与需求所需的产出。
  • 制定解决方案是就对要求进行调研,看如何能够满足这些要求、并提供最佳投资回报。

  • 收益管理采纳已经按照收益的角度进行了表述的要求,并且管理要求,直到最终交付。收益管理通常依赖变更管理,将产出转变成成果,将成果转化成收益。

  • 变更控制是一种捕捉与评估潜在的范围变更的程序。它确保只有可取的、可实现、切实可行的变更才能进行变更。

  • 配置管理对产品的开发进行监督与文档管理。它记录经过批准的变更,为存档被取代的版本。配置管理系统中的信息,对评估变更申请很有帮助。

这些方面相互关联的方式有很大不同。简单的范围管理程序可以采取以下形式(“实施解决方案”覆盖变更控制与配置管理):

 

 

这描述了一种线性的方法,适用于数量不大的几个产出、支持数量不多的几个收益,即复杂度较低的工作,可能作为项目来加以管理。

在覆盖范围较广的工作中,多个产出与收益具有复杂的关系,范围管理与构成的诸多功能程序加以整合。

 

 

要求管理总是触发制定解决方案,由此设计有形的产出。如果已经根据收益定义了诸多要求,就要触发收益管理功能。收益依赖于产出的实施,因此制定解决方案与收益管理从一开始就必须同步进行。

一旦产出记录在了规格要求中、在收益概要中定义了收益,工作就有了必须交付什么的基线。这通常在生命周期的定义阶段的结尾时发生,尽管有些细节内容,可能要遗留到项目或项目群阶段开始的时候才能完全完成。

对交付规格要求和收益所需工作的定义,是进度管理的一部分。这种工作定义要被用来创建工作模型,进行时间进度安排资源进度安排编制预算与成本控制。

一旦项目与项目群交付阶段的工作开始,任何对基线范围的变更,都必须经过正式的变更控制流程,并与质量控制的结果一起,记录到配置管理中。

产品开发流程覆盖完全依赖于技术内容的工作的执行,无论是建筑行业的、软件开发的、还是医药开发或者任何其他行业。这些技术内容的细节超出了项目、项目群与项目组合管理的范畴,除了它与范围管理的交互界面。

收益管理是持续进行的,超越收益简介的创建、涵盖运用变更管理以实现收益。这个功能可以这样描述:它是独立于各个部门的,因此被视为项目、项目群与项目组合管理的一部分。

在项目、项目群或项目组合一开始,能够预测的要求与解决方案的详细程度,将影响如何管理范围。

项目、项目群与项目组合术语的演化已经潜在地产生了“变更控制”与“变更管理”之间的疑惑。

变更控制专门处理的是,对范围潜在变更的控制。

变更管理涵盖的,是变更正常经营中的工作实践的工作。

当很好理解了目标、有了有形的产出(例如,在建筑与工程项目与项目群中),通常在定义阶段对范围进行尽可能精准的定义。然后通过变更控制评估所有潜在的范围变更,减少成本上升,维护商业论证的可行性。

对超出范围进行定义,也是很有用的,可以避免误解。清晰定义哪些是范围之内的、哪些是范围之外的,可以降低风险,并管理所有关键利益相关方的期望。

在目标不是非常有形、或者很容易发生巨大变化的情况下,例如业务变革或一些IT系统,就需要用一些更灵活的方法来处理范围。可以采用并行生命周期,使用敏捷方法,这样在交付阶段始终都可以对范围进行迭代优化。这要求运用很严谨的方法,以避免成本增长。

管理工作范围的一个重要因素是,将物有所值最大化。价值管理学科将贯穿六个领域运行的重要程序与技术汇聚起来。它确保项目、项目群或项目组合的投资,对于所交付的潜在回报,是最佳的。

 

项目、项目群与项目组合

一旦产出得以具体化,工作定义决定了需要创建产出及其构成产品的所有单个的活动。信息可以作为产品分解结构(PBS)与/或工作分解结构(WBS)加以呈现。

编制分解结构是个迭代的过程。一开始是在定义流程中、与对项目其他方面(比如时间与成本)的详细规划同步并行。三重限制的三个要素必须保持平衡,这可能需要对产品分解结构与工作分解结构的细节做各种调整。

传统项目中,对于产出有比较合理全面的规格要求,经过批准的分解结构在定义流程结束时作为基线确定下来。产品分解结构中的产品将成为配置管理系统中的配置项。任何提出的范围变更,都需要经过正式的变更控制程序。

范围这个术语在最近几年里变得有点模糊不清晰。Praxis用以下方法进行一些澄清:

  • 目标可以是一个产出、成果或收益。

  • 大部分产出正式由一方移交给另一方 – 在这种情况下,它们被称为交付物。

  • 更复杂的产出可能由多个产品组成,其中一些产品可能本身就是交付物。

  • 一些产品还可能会被纳入配置管理系统,被定义为配置项。

  • 产品、产品组、以及创建它们的工作,整合到一起就是所谓的工作包。

一些项目运用敏捷法,范围基线从一开始就包括功能要求、而不是完全具体的产品。能满足这些功能的产品就以被称为时间盒的迭代方式,加以开发。

项目群要求,通常以与项目交付的产出相关的成果与收益来加以描述。因此,项目群的范围就用蓝图收益概要文件与构成项目清单来加以具体化。

产出、成果与收益的关系很少是一对一的,它们之间的关系是多重依赖关系。这些相互依赖关系必须加以定义与文档记录。对项目群整体有效的解决方案制定、收益管理、变更控制和配置管理,全都基于对这些相互依赖关系的理解。

项目群范围往往比项目范围更易变。针对项目群内部所有项目的解决方案,不大可能在开始的时候就能识别清楚,而且商业环境也可能发生变化。项目群管理团队必须管理整个生命周期过程中演变的范围。

一个标准的项目组合,是诸多具有互不连接的目标的项目与项目群的总和。标准项目组合的主要目的,就是创建实施一致标准的基本架构,并最优化地运用组织资源。项目组合的范围是灵活的,而且就是构成项目与项目群的范围的总和。

结构化的项目组合是由它的承办组织的战略目标所定义的,而项目组合就是设计出来满足组织的战略目标。它的范围就是交付这些战略目标的项目、项目群与所需要的变革活动的总和。

结构化项目组合的范围管理,开始于识别相关的项目与项目群。可能现有的项目与项目群,从一开始就被包括其中了。在项目组合生命周期中,会出现很多针对项目与项目群的想法观点,并为采纳进入范围而互相竞争。范围需要定期进行评审,并通过优先排序与平衡项目组合管理流程中的活动来加以调整。需要建立合格标准、可能以比如所需的投资回报水平、或可接受的风险水平来表述。

项目组合治理流程应该为推进新提议到评审阶段提供规则,项目组合经理应帮助项目与项目群发起人形成他们进入项目组合的潜在通道。制定解决方案与收益管理大部分授权给了项目和项目群,项目组合的协调流程将确保价值的最大化。

 

 

 

 

 

SHARE THIS PAGE

Please consider allowing cookies to be able to share this page on social media sites.

Change cookie settings
No history has been recorded.
Back to top