06.项目范围管理

1. 范围管理概述

1.1. 项目范围需要做以下三个方面

1、明确项目边界,即明确哪些工作是包括在项目范围之内的,哪 些工作是不包括在项目范围之内的。
2、对项目执行工作进行监控,确保所有该做的工作都做了,而且 没有多做。对不包括在项目范围内的额外工作说“不”杜绝做额外工 作。
3、防止项目范围发生蔓延。范围蔓延是指未对时间、成本和资源 做相应调整,未经控制的产品或项目范围的扩大。

1.2. 产品范围与项目范围

1、产品范围是指产品或者服务所应该包含的功能,项目范围是指为了能够交付产品,项目所必须做的工作。
2、产品范围是项目范围的基础,产品范围的定义是产品要求的描述;而项目范围的定义是产生项目管理计划的基础。
3、项目的范围基准是经过批准的项目范围说明书、WBS和WBS词典。
4、判断项目范围是否完成,要以范围基准来衡量。而产品范围是否完成,则根据产品是否满足了产品描述来判断。
5、产品范围描述是项目范围说明书的重要组成部分,因此,产品范围变更后,首先受到影响的是项目的范围。

1.3. 范围管理的过程

项目范围管理主要是通过规划范围管理、收集需求、定义范围、创建WBS、确认范围和控制范围六个过程来实现的。

2. 规划范围管理

★定义: 规划范围管理是编制范围管理计划,书面描述将如何定义、确认和 控制项目范围的过程,其主要作用是在整个项目中对如何管理范围 e 提供指南和方向。
★输入: 1、项目管理计划，2、项目章程，3、事业环境因素，4、组织过程资产
★工具与技术：1、专家判断，2、会议
★输出：1、范围管理计划，2、需求管理计划

范围管理计划：
定义：范围管理计划是制订项目管理计划过程和其他范围管理过程的主要输入
内容：
1、如何制订项目范围说明书。
2、如何根据范围说明书创建WBS。
3、如何维护和批准WBS。
4、如何确认和正式验收已完成的项目可交付成果。
5、如何处理项目范围说明书的变更,该工作与实施整体变更控制过程直接相联。

※特点：项目范围管理计划可能在项目管理计划之中,也可能作为单独的一项。根据不同的项目,可以是详细的或者概括的,可以是正式的或者非正式的。

需求管理计划
定义：需求管理计划描述在整个项目生命周期内如何分析、记录和管理需求。
内容：
1、如何规划、跟踪和汇报各种需求活动。
2、需求管理需要使用的资源。
3、培训计划
4、项目干系人参与需求管理的策略
5、判断项目范围与需求不一致的准则和纠正规程
6、需求跟踪结构,即哪些需求属性将列入跟踪矩阵,并可在其他哪些项目文件中追踪到这些需求。
7、配置管理活动

特点：

• 需求管理贯穿于整个过程,它的最基本的任务就是明确需求,并使 项目团队和用户达成共识,即建立需求基线。
• 还要建立需求跟踪能力联系链确保所有用户需求都被正确地应用, 并且在需求发生变更时,能够完全地控制其影响范围,始终保持产品与需求的一致性。

3. 收集需求

3.1. 需求的分类

业务需求：整个组织的高层级需要,例如,解决业务问题或抓住业务机会,以及实施项目 的原因。
干系人需求：是指干系人或干系人群体的需要
过渡需求：从当前状态过渡到将来状态所需的临时能力,例如,数据转换和培训需求。
质量需求：用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准。QFD对 质量需求进行了细分,分为基本需求、期望需求和意外需求。

3.2. ★输入

1、范围管理计划
2、需求管理计划
3、干系人管理计划
4、项目章程
5、干系人登记册

3.3. 工具和技术

1、访谈
2、焦点小组

• 将预先选定的干系人和主题专家集中在一起,了解他们对所提议产品、服务或成果的期 望和态度。由一位受过训练的主持人引导大家进行互动式讨论。焦点小组往往比一对一 的访谈更加热烈。
• 焦点小组是一种群体访谈而非一对一访谈,可以有6~10个被访谈者参加。针对访谈者 提出的问题,被访谈者之间开展互动式讨论,以求得到更有价值的意见。

3、引导式研讨会

• 通过邀请主要的跨职能干系人一起参加会议。引导式研讨会对产品需求进行集中讨论与定义。
• 研讨会是快速定义跨职能需求和协调干系人差异的重要技术。由于群体互动的特点,被有效引导的研讨会有助于建立信任、促进关系、改善沟通,从而有利于参加者达成一致意见。
• 该技术的另一个好处是,能够比单项会议更快地发现和解决问题。

4、群体创新技术

• 群体创新技术是指可以组织一些群体活动来识别项目和产品需求,群体创新技术包括头 脑风暴法、名义小组技术、德尔菲技术、概念/思维导图、亲和图和多标准决策分析等。
• 头脑风暴：各抒己见
• ※名义小组技术：通过投票来排列最有用的创意,以便进行进一步的头脑风暴或优先排序。 名义小组技术是头脑风暴法的深化应用,是更加结构化的头脑风暴法
• 德尔菲技术：可以防止个人的观点被不正确的放大
• 概念/思维导图：是将从头脑风暴中获得的创意,用——张简单的图联系起来,以反映这些创意之间的共性 与差异,从而引导出新的创意。
• 亲和图：亲和图又称为KJ法,是针对某一问题,充分收集各种经验、知识、想法和意见等语言、文字资料,通过图解方式进行汇总,并按其相互亲和性归纳整理这些资料,使问题明确起来,求得统一认识,以利于解决的一种方法。亲和图的核心是头脑风暴法,是根据结果去找原因。
• 多标准决策分析：借助决策矩阵,用系统分析方法建立诸如风险水平、不确定性和价值收 益等多种标准,从而对众多方案进行评估和排序的一种技术

5、群体决策技术
定义：群体决策就是为达成某种期望结果而对多个未来行动方案进行评估。群体决策技术可用 来开发产品需求,以及对产品需求进行归类和优先排序。
一致同意：所有人都同意某个行动方案
大多数原则：获得群体中50%以上的人的支持,就能做出决策。参与决策的人数定为奇数, 防止因平局而无法达成决策
相对多数原则：

• 根据群体中相对多数者的意见做出决定,即便未能获得——部分人的支持。
• 通常在候选项超过两个时使用该原则,例如,某个软件构件的功能有3种实现方案(标 记为A、B、C)在群体决策时,同意A方案的人有40%,同意B方案的人有35%,同意C 方案的人有25%,则最终确定采用A方案。
  独裁：由某一个人(例如,项目经理)为群体做出决策。

6、问卷调查

7、观察

9、原型法
原型法是一种根据干系人初步需求,利用产品开发工具,快速地建立一个产品模型展示 给干系人,在此基础上与干系人交流,最终实现干系人需求的产品快速开发的方法。
10、标杆对照
标杆对照将实际或计划的做法与其他类似组织的做法(例如,流程、操作过程等)进行比 较,以便识别最佳实践,形成改进意见,并为绩效考核提供依据,标杆对照所采用的"类 似组织"可以是内部组织,也可以是外部组织
11、系统交互图
系统交互图是对产品范围的可视化描述,显示系统(过程、设备、信息系统等)与参与者 (用户、独立于本系统之外的其他系统)之间的交互方式。系统交互图显示了业务系统的输入、输入提供者、业务系统的输出和输出接收者。
12、文件分析
文件分析就是通过分析现有文档,识别与需求相关的信息来挖掘需求。可供分析的文档很多,包括商业计划、营销文档、协议、招投标文件、建议邀请书、业务流程、逻辑数据模型、业务规则库、应用软件文档、用例文档、其他需求文档、问题日志、政策、程序和法规文件等。

3.4. 输出

3.4.1. 需求文件

定义：需求文件描述各种单一的需求将如何满足与项目相关的业务需求。
内容(不限于)：

• 1、业务需求
• 1、需求文件
• 2、干系人需求
• 3、解决方案需求
• 4、项目需求
• 5、过渡需求
• 6、与需求有关的假设条件、依赖关系和制约因素。

3.4.2. 需求跟踪矩阵

需求管理：需求管理包括在产品开发过程中维持需求一致性和精确性的所有活动,包括控制需求基线,保持项目计划与需求一致,控制单个需求 和需求文档的版本情况,管理需求和联系链之间的联系,或管理单个需求和项目其他可交付物之间的依赖关系,跟踪基线中需求的状态。

需求跟踪：

• 可跟踪性是项目需求的一个重要特征,需求跟踪是将单个需求和其他元素之间的依赖关 系和逻辑联系建立跟踪,这些元素包括各种类型的需求、业务规则、系统组件,以及帮助文件等。
• 每个配置项的需求到其涉及的产品(或构件)需求都要具有双向可跟踪性。所谓双向跟踪,包括正向跟踪和反向跟踪,正向跟踪是指检查需求文件中的每个需求是否都能在后 ★继工作产品(成果)中找到对应点;反向跟踪也称为逆向跟踪,是指检查设计文档、产品 构件、测试文档等。工作成果是否都能在需求文件中找到出处。具体来说,需求跟踪涉及五种类型。
  
• 箭头表示需求跟踪能力联系链,它能跟踪需求使用的整个周期,即从需求建议到交付的全过程。
• 从用户原始需求可向前追溯到需求文件,这样就能区分出项目过程中或项目结束后由于 变更受到影响的需求,也确保了需求文件中包括所有用户需求。同样,可以从需求文件 回溯到相应的用户原始需求,确认每个需求的出处。
• 由于在项目实施过程中,产品需求转变为设计和测试等实现元素,所以通过定义单个需 求和特定的产品元素之间的联系链,可以从需求文件追溯到产品元素。这种联系链使项目团队成员知道每个需求对应的产品元素,从而确保产品元素满足每个需求。第四类联系链是从产品元素回溯到需求文件,使项目团队成员知道每个产品元素存在的原因。如 果不能将设计元素或测试案例回溯到一个需求文件,就可能出现镀金行为。当然,如果某个孤立的产品元素表明了一个正当的功能,则说明需求文件漏掉了一项需求。
• 第五类联系链是需求文件之间的跟踪,这种跟踪便于更好地处理各种需求之间的逻辑相 关性,检查需求分解中可能出现的错误或遗漏。

需求变更矩阵：

• 表示需求和其他产品元素之间的联系链的最普遍方式是使用需求跟踪(能力)矩阵,需求跟踪矩阵是将产品需求从其来源连接到能满足需求的可交付成果的一种表格
• 应在需求跟踪矩阵中记录每个需求的相关属性这些属性有助于明确每个需求的关键信息。需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态(例如,进行中、已取消、已推迟、新 增加、已批准、已分配、已完成等)和状态日期。

4. 范围定义

4.1. 定义

定义范围是制定项目和产品详细描述的过程,其主要作用是明确所收集的需求哪些将包 含在项目范围内,哪些将排除在项目范围外,从而明确产品、服务或成果的边界。

4.2. ★输入

1、范围管理计划，2、项目章程，3、需求文件，4、组织过程资产

4.3. ★工具与技术：

1、专家判断
2、产品分析：产品分析是一种有效的工具。通常,针对产品提问并回答, 形成对将要开发的产品的用途、特征和其他方面的描述。
3、备选方案生成：备选方案生成是一种用来指定尽可能多的潜在可选方案的技术,用于识别执行项目工作的不同方法。
4、引导式研讨会

4.4. 输出：

4.4.1. ★1、项目范围说明书

定义：作为定义范围过程的主要成果,项目范围说明书是对项目范围、主要可交付成果、假设 条件和制约因素的描述。项目范围说明书记录了整个范围,包括项目范围和产品范围,详细描述项目的可交付成 果,以及为提交这些可交付成果而必须开展的工作。

內容：
1、产品范围描述。
2、验收标准：定义可交付成果通过验收前必须满足的一系列条件,以及验收的过程。
3、可交付成果。
4、项目的除外责任：通常需要识别出什么是被排除在项目之外的。明确说明哪些内容不属于项目范围,有助于管理干系人的期望。
5、制约因素：列出并说明与项目范围有关且限制项目团队选择的具体项目制约因素
6、假设条件

作用：
1、确定范围。
2、沟通基础。
3、规划和控制依据。
4、变更基础。
5、规划基础。

2、项目文件更新

5. 创建WBS

WBS不是某个项目团队成员的责任,应该由全体项目团队成员、用户和项目干系人共同 完成和一致确认。

5.1. 定义

创建WBS是将项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程。

5.2. WBS

★里程碑：里程碑标志着某个可交付成果或者阶段的正式完成。重要的检查点是里程碑、重要的里 程碑是基线。
工作包：工作包是位于WBS每条分支最底层的可交付成果或项目工作组成部分,工作包应该非常 具体,以便承担者能明确自己的任务、努力的目标和承担的责任。工作包的大小需要遵循8/80原则。
控制账户：控制账户是一种管理控制点。是WBS某个层次上的要素,既可以是工作包,也可以是比 工作包更高层次上的一个要素。如果是后一种情况,一个控制账户中就包括若干个工作 包,但一个工作包仅属于一个控制账户。项目管理团队在控制账户上考核项目的执行情 况,即在控制账户的相应要素下,将项目执行情况与计划情况进行比较,以便评价执行 情况好坏,并发现与纠正偏差。
★规划包：规划包是指在控制账户之下,工作内容已知但尚缺详细进度活动的WBS组成部分。是在 控制账户之下、工作包之上的WBS要素是暂时用来做计划的。随着情况的逐渐清晰,规 划包最终将被分解成工作包以及相应的具体活动。
WBS词典：WBS词典,在制作WBS的过程中,要给WBS的每个部分赋予一个账户编码标志符,它们是成本、进度和资源使用信息汇总的层次结构。需要生成一些配套的文件,这些文件需要和WBS配套使用,称为WBS词典。WBS词典也称为WBS词汇表,它是描述WBS各组成部分的文件。

5.3. ★输入

1、范围管理计划
2、项目范围说明书
3、需求文件
4、事业环境因素
5、组织过程资产

5.4. 工具和技术

分解、专家判断

5.5. ★输出

1、范围基准，2、项目文件更新

5.6. ★ 分解的步骤

1、识别和分析可交付成果及相关工作。
2、确定WBS的结构和编排方法。
3、自上而下逐层细化分解。
4、为WBS组件制定和分配标识编码。
5、核实可交付成果分解的程度是恰当的。

5.7. 分解的原则

功能或者技术原则：在创建WBS时,需要考虑将不同人员的工作分开。
组织结构：对于职能型的项目组织而言,WBS也要适应项目的组织结构形式
系统或者子系统：总的系统划分为几个主要的子系统,然后对每个子系统再进行分解

5.8. ★ WBS分层方式

1、将项目生命周期的各阶段作为分解的第二层
2、主要可交付成果作为分解的第二层
3、子项目作为分解的第二层

5.9. ★表示形式

树型结构(组织结构图式)：

• 优点：树型结构图的WBS层次清晰、直观性和结构性强
• 缺点：但不容易修改,对大的、复杂的项目很难表示出项目的全貌。

表格形式(列表式)

• 优点：能够反映出项目所有的工作要素。
• 缺点：但表格形式的直观性比较差

值得注意的是,虽然有些参考文献也使用鱼骨图形式的WBS,但这种形式并不常用。

5.10. ★分解注意事项

1、WBS必须是面向可交付成果的。项目的目标是提供产品或服务,仅仅是一连串特别的活动。
2、WBS必须符合项目的范围。WBS必须包括,也仅包括为了完成项目的可交付成果的活动
3、WBS的底层应该支持计划和控制。WBS是项目管理计划和项目范围之间的桥梁, WBS的底层不但要支持项目管理计划,而且要让管理层能够监视和控制项目的进度和预算。
4、WBS中的元素必须有人负责,而且只由一个人负责,尽管实际上可能需要多个人参与
5、WBS的指导。作为指导而不是原则,WBS应控制在4~6层。当然,大项目可以超过6层。
6、WBS应包括项目管理工作,也要包括分包出去的工作。
7、WBS的编制需要所有(主要)项目干系人的参与,需要项目团队成员的参与。
8、WBS并非是一成不变的,在完成了WBS之后的工作中,仍然有可能需要对WBS进行修改。

5.11. WBS用途与作用

1、明确和准确说明项目范围,项目团队成员能够清楚地理解任务的性质和需要努力的方向。
2、清楚地定义项目的边界
3、为各独立单元分派人员,规定这些人员的职责,可以确定完成项目所需要的技术和人力资源。
4、针对独立单元,进行时间、成本和资源需求量的估算,提高估算的准确性。
5、为计划、预算、进度安排和费用控制奠定共同基础,确定项目进度和控制的基准。
6、将项目工作和项目的财务账目联系起来。
7、确定工作内容和工作顺序,将项目分解成具体的工作任务,就可以按照工作任务的逻辑顺序来实施项目。WBS可以使用图形化的方式来查看工作内容,任何人都能够清楚地辨别项目的阶段、工作单元,并根据实际情况进行调节和控制。
★8、有助于防止需求蔓延。

6. 确认范围

6.1. ★定义

确认范围是正式验收项目已完成的可交付成果的过程。确认范围包括与客户或发起人一起重查可交付成果,确保可交付成果已圆满完成,并获得客户或发起人的正式验收。确认范围应该贯穿项目的始终

6.2. ★输入

1、项目管理计划
2、需求文件
3、需求跟踪矩阵
4、确认的可交付成果
5、工作绩效数据

6.3. ★ 工具与技术

检查 检查也称为审查、评审、审计、走查、巡检、测试等。
群体决策

6.4. ★输出

1、验收的可交付成果
2、变更请求
3、工作绩效信息
4、项目文件更新

6.5. 步骤

1、确定需要进行范围确认的时间。
2、识别范围确认需要哪些投入。
3、确定范围正式被接受的标准和要素。
4、确定范围确认会议的组织步骤。
5、组织范围确认会议。

6.6. 项目干系人进行范围确认时, 一般需要检查以下6个方面的问题

1、可交付成果是否是确定的、可确认的。
2、每个可交付成果是否有明确的里程碑,里程碑是否有明确的、可辨别的事件。
3、是否有明确的质量标准。
4、审核和承诺是否有清晰的表达。
5、项目范围是否覆盖了需要完成的产品或服务进行的所有活动,有没有遗漏或者错误。
6、项目范围的风险是否太高,管理层是否能够降低可预见的风险发生时对项目的冲击。

6.7. 项目干系人关注点

1、管理层所关注的项目范围,是指范围对项目的进度、资金和资源的影响,这些因素是否超过了组织承受范围,是否在投入产出上具有合理性。
2、客户主要关心的是产品的范围,关心项目的可交付成果是否足够完成产品或服务。
3、项目管理人员主要关注可交付成果是否足够和必须完成,时间、资金和资源是否足够,主要的潜在风险和预备解决的方法。
4、项目团队成员主要关心项目范围中自己参与的元素和负责的元素,通过定义范围中的时间检查自己的工作时间是否足够,自己在项目范围中是否有多项工作,而这些工作又有冲突的地方。

6.8. 几个术语的比较

1、确认范围与核实产品
核实产品是针对产品是否完成,在项目(或阶段)结束时由发起人或客户来验证,强调 产品是否完整;确认范围是针对项目可交付成果,由客户或发起人在阶段末确认验收的过程。
2、确认范围与质量控制

• 1、确认范围主要强调可交付成果获得客户或发起人的接受;质量控制强调可交付成果的正确性,并符合为其制定的具体质量要求(质量标准)。
• 2、质量控制一般在确认范围前进行,也可同时进行;确认范围一般在阶段末尾进行,而质量控制并不一定在阶段未进行。
• 3、质量控制属内部检查,由执行组织的相应质量部门实施;确认范围则是由外部干系人(客户或发起人)对项目可交付成果进行检查验收。

3、确认范围与项目收尾

• 1、虽然确认范围与项目收尾工作都在阶段未进行,但确认范围强调的是核实与接受可交付成果,而项目收尾强调的是结束项目(或阶段)所要做的流程性工作。
• 2、确认范围与项目收尾都有验收工作,确认范围强调验收项目可交付成果,项目收尾强调验收产品。

7. 控制范围

7.1. ★定义

控制范围是监督项目和产品的范围状态、管理范围基准变更的过程。

7.2. ★输入

1、项目管理计划
2、需求文件
3、需求跟踪矩阵
4、工作绩效数据
5、组织过程资产

7.3. ★工具与技术

偏差分析

7.4. 输出

1、工作绩效信息
2、变更请求
3、项目管理计划更新
4、项目文件更新
5、组织过程资产更新

7.5. ★范围变更的原因

1、政府政策的问题。
2、项目范围的计划编制不周密详细,有一定的错误或遗漏。
3、市场上出现了或是设计人员提出了新技术、新手段或新方案。
4、项目执行组织本身发生变化。
5、客户对项目、项目产品或服务的要求发生变化。

7.6. 主要工作

1、影响导致范围变更的因素,并尽量使这些因素向有利的方面发展。
2、判断范围变更是否已经发生。
3、范围变更发生时管理实际的变更,确保所有被请求的变更按照项目整体变更控制过程处理。