项目范围管理

Posted 2022-09-10 左直拳

项目范围（scope）是规定达成项目目标所要做的工作。项目范围管理就是要明确哪些工作是项目应该做的，哪些不应该包括在项目中。项目范围是项目目标更具体的表述。

如果项目范围不明确，要么项目做的工作与实际目标不相符，南辕北辙，或者项目团队瞎忙活，从事着本不属于他们的工作。因此，范围管理必须清晰定义项目目标，并且该定义必须在项目干系人之间达成一致，并且项目工作范围还要详细划分为工作包，才能比较好地执行。
.

一、范围管理概述

项目范围管理（Scope Management）就是要做且只做范围内的事，既不少做也不多做，具体为：
1）明确项目边界，即明确哪些工作是包括在项目范围之内的，哪些工作不是；
2）监控项目执行工作，确保该做的都做，但又不多做，杜绝额外的工作；
3）防止项目范围发生蔓延，即未对时间、成本和资源做相应调整，导致产品或项目不受控，范围扩大。

1、产品范围与项目范围
项目中存在两个相互关联的范围：产品范围和项目范围。产品范围是产品或服务应该包含的功能，项目范围是为了交付产品而必须做的工作。产品范围是项目范围的基础。产品范围的定义是产品要求描述，而项目范围的定义是项目管理计划的基础。

项目的范围基准（Scope Baseline）是经过批准的项目范围说明书、WBS和WBS词典。判断项目范围是否完成，要以范围基准来衡量；而产品范围是否完成，则根据产品是否满足了产品描述来判断。

产品范围变更，并不意味着项目范围一定变更。

2、范围管理的重要性
1）项目范围管理是项目管理的一个主要部分，同时在项目建设过程中不断重申项目工作范围，有利于项目不偏离轨道，是项目中实施控制管理的一个主要手段。

2）项目范围管理能够确定项目的边界，明确项目目标和主要交付成果，有助于提高项目成本、进度和资源估算的准确性。

3）项目实践中，范围蔓延是项目失败最常见的原因之一。

3、范围管理的过程
项目范围管理的过程为：
1）规划范围管理
2）收集需求
3）定义范围
4）创建WBS
5）确认范围
6）控制范围

二、规划范围管理

规划范围管理（Plan Scope Management）是编制范围管理计划，书面描述将如何定义、确认和控制项目范围的过程，主要作用是对整个项目建设过程中如何管理范围提供指南和方向。

【输入】
1）项目管理计划
2）项目章程
3）事业环境因素
4）组织过程资产

【输出】
1）范围管理计划
2）需求管理计划

【工具与技术】
1）专家判断
2）会议

1、范围管理计划
范围管理计划是项目或项目集管理计划的组成部分，描述将会如何定义、制订、监督、控制和确认项目范围，是制订项目管理计划的主要输入。它对以下工作做出规定：
1）制订项目范围说明书
2）创建WBS
3）维护和批准WBS
4）确认和验收项目可交付成果
5）处理项目范围说明书的变更

2、需求管理计划
需求管理计划（Requirements Management Plan）描述在整个项目生命周期内如何分析、记录和管理需求。包括以下内容：
1）如何规划、跟踪和汇报各种需求活动

2）进行需求管理所需要使用的资源
如需求跟踪矩阵，需求变更审批表等

3）培训计划
4）项目干系人参与需求管理的策略
5）判断项目范围与需求不一致的准则和纠正规程
6）需求跟踪结构，即哪些需求属性将列入跟踪矩阵
7）配置管理活动
比如，如何启动变更，如何分析影响，如何跟踪和汇报等

三、收集需求

收集需求（Collect Requirement）是为实现项目目标而确定、记录并管理干系人的需要和需求的过程，是定义和管理项目范围（包括产品范围）奠定基础。

1、需求的分类
1）业务需求
组织高层级需要。

2）干系人需求
干系人或干系人群体的需要。

3）解决方案需求
即系统需求，又分为功能需求和非功能需求。

4）过渡需求
从当前状态过渡到将来状态所需的临时能力，如数据转换和培训需求。听上去，所谓过渡需求是使用新系统的准备工作的需求。

5）项目需求
项目需要满足的行动、过程或其他条件。

6）质量需求
分为基本需求、期望需求和意外需求。

QFD（Quality Function Deployment，质量功能部署）是一种将用户要求转化成软件需求的技术。其目的是最大限度地提升软件工程过程中用户的满意度。为了达到这个目标，QFD将软件需求分为三类：常规需求、期望需求和意外需求。

2、收集需求的工具与技术
收集需求看上去很简单，做起来却很难。收集需求是否科学、准备是否充分，对收集的结果影响很大。这是因为大部分干系人无法完整地描述需求，而且也不可能看到产品全貌，因此，收集需求只有通过与干系人的有效合作才能成功。

1）访谈
用户访谈是最基本的一种需求获取手段，形式包括结构化和非结构化两种。结构化是指事先准备好一系列问题，有针对地进行；而非结构化则是只列出一个粗略的想法，根据访谈的具体情况发挥。最有效的访谈是结合这两种方法进行，毕竟不可能事先一一计划清楚。

为了进行有效的用户访谈，需要在三个方面进行组织，分别是准备访谈、主持访谈和访谈的后续工作。

用户访谈具有良好的灵活性，有较宽广的应用范围。但用户时间不好安排；谈话信息量大，不好记录；需要沟通技巧和足够的领域知识、丰富的应对经验等。

需求获取及记录

2）焦点小组
预先选定的干系人和主题专家集中在一起，由一位训练有素的主持人引导大家进行互动式讨论。访谈的加强版。

3）引导式研讨会（Facilitated Workshop）
邀请主要的跨职能干系人一起参加会议，对需求进行集中讨论和定义。研讨会时快速定义跨职能需求和协调干系人差异的重要技术。

由于群体互动的特点，被有效引导的研讨会有助于建立信任、促进关系、改善沟通，从而有利于参加者达成一致意见。另一个好处是能够比单项会议更快地发现和解决问题。

联合应用开发（Joint Application Development，JAD）一种典型的引导式研讨会。

另外还有质量功能引导式研讨会，帮助确定新产品的关键特征。用矩阵的形式，将需求与产品特性联系起来。

4）群体创新技术（Group Creativity Technique）
是指组织一些群体活动来识别项目和产品需求，包括头脑风暴、名义小组技术、德尔菲技术、概念/思维导图、亲和图、多标准决策分析等。

（1）头脑风暴法
头脑风暴法（BrainStorming，BS）又称为智力激励法、自由思考法或集思广益法，是用来产生和收集项目需求与产品需求的多种创意技术。

头脑风暴法分为直接头脑风暴法（头脑风暴法）和质疑头脑风暴法（反头脑风暴法）。前者尽量多产生设想，后者对前者的设想和方案提出质疑，分析现实可行性。

一般参加者为5~10人，设一个主持。主持只负责主持会议，不对设想作评论。另有记录员1到2名。

头脑风暴法各抒己见，畅所欲言，庭外判决，对方案的评论必须放在最后。

（2）名义小组技术
名义小组技术（Nominal Group Technique）通过投票来排列最有用的创意，以便开展头脑风暴或进一步优先排序。名义小组是头脑风暴的深化应用，或说是更加结构化的头脑风暴法。

具体方法为先分为小组讨论，然后再全体评审。可以让不善言辞的参与者也能较为放开。

（3）德尔菲技术
参考 项目进度管理

（4）概念/思维导图
思维导图（Mind Mapping）又称为心智图，是将头脑风暴中获得的创意，用一张简单的图联系起来。该图图文并重，反映各主题的关系以及层次。

（5）亲和图
亲和图（Affinity Diagram）又称为KJ法，是针对某一问题，充分收集各种经验、知识、想法和意见，包括语言、文字，通过图解方式进行汇总，并按其相互亲和性归纳整理这些资料，使问题明确起来，求得统一认识，以利于解决问题。

亲和图的核心是头脑风暴法，属于根据结果找原因。通过将大量创意进行分类，以便审查和分析。分类依据是创意之间的相似性。在项目管理中，亲和图针对某个问题，产生各种创意，主要用来确定范围分解的结构，帮助制订WBS。

（6）多标准决策分析
多标准决策分析（Multi-Criteria Decision Analysis），借助决策矩阵，用系统分析方法建立如风险水平、不确定性和价值收益等多种标准，对众多方案进行评估和排序。

决策矩阵是风险型决策常用的分析手段之一，又被称为“决策表”、“益损矩阵”、“益损表”、“风险矩阵”。 决策矩阵评价一系列的选择并为其排序。 小组首先设计一些评价标准，然后按照标准对每个选择进行评价。 它属于L型矩阵的一种。

5）群体决策技术
群体决策（Group Decision-Making）是为达成某种期望结果而对多个未来行动方案进行评估。

群体决策技术可用来开发产品需求，以及对产品需求进行归类和优先排序。方案有多种：
（1）一致同意（Unanimity）
所有人都同意某个方案
（2）大多数原则（Majority）
超过50%以上的人支持就能做出决策。
（3）相对多数原则（Plurality）
根据群体中相对多数者的意见做出决定。比如ABC三个方案，A的支持者有40%，B 35%，C 25%，则A胜出。
（4）独裁（Dictatorship）
由某一个人（如项目经理）为群体做出决策。

6）问卷调查
问卷调查（Questionnaire and Survey）
需求获取及记录

7）观察
观察（Observation），也成为工作跟踪。现场观摩。

8）原型法
原型法（Prototype）。

9）标杆对照
标杆对照（Benchmarking），将实际或计划的做法与其他类似组织的做法（例如流程、操作过程）进行比较，以便识别最佳实践，形成改进意见，并作为绩效考核的依据。注意组织既可以是外部的，也可以是内部的。

10）系统交互图
系统交互图（Context Diagram）是范围模型的一个例子，是对产品范围的可视化描述，显示系统与参与者之间的交互方式。如DFD，用例图。

11）文件分析
文件分析（Document Analysis），也叫资料研读，文档考古。

3、需求文件
收集需求过程的主要输出有需求文件（Requirements Documentation）和需求跟踪矩阵。

需求文件不是一个文件的名字，需求文件格式多种多样，在不同的组织中，可能有不同的称呼。它既可以很简单也可以很详细，但内容应该包括但不限于
1）业务需求
2）干系人需求
3）解决方案需求
4）项目需求
5）过渡需求
6）需求相关的假设条件、依赖关系和制约因素

典型的需求文件是软件需求规格说明书。

4、需求跟踪
CMMI中，需求管理是已管理级的一个关键过程域，其中需求跟踪是需求管理的重要组成部分。

1）需求跟踪的内容
包括正向跟踪和反向跟踪。

2）需求跟踪矩阵

四、定义范围

定义范围（Define Scope）是制定项目和产品详细描述的过程，其主要作用是明确所收集的需求哪些包含在项目范围内，哪些不是，从而明确产品、服务或成果的边界。注意并非所有需求最终都会体现在项目里。

项目范围说明书的编制对项目成功至关重要。项目管理团队应该根据可交付成果、假设条件和制约因素来编制项目范围说明书。在项目推进过程中，随着对项目了解的深入，项目范围相应逐渐具体，甚至做必要的增补或更新。

1、定义范围的工具与技术
定义范围最重要的是详细定义项目的范围边界。范围边界是应该做的工作和不需要做的工作的分界线。
同时，定义范围时可以增加项目时间、成本和资源估算的准确度、实施项目控制的依据，明确相关责任人的职责、项目范围、合理性和目标，以及主要可交付成果。

定义范围的主要工具与技术有：

1）专家判断

2）产品分析
产品分析（Product Analysis）是一种对以产品为可交付成果的项目的有效工具。针对产品提问并回答，形成将要开发的产品的用途、特征和其他方面的描述。

产品分析技术包括产品分解、系统分析、需求分析、系统工程、价值工程和价值分析等。WBS就是一种典型的产品分解技术。

价值工程（Value Engineering）与价值分析（Value Analysis）两种活动都是对商品的价值、功能与成本进一步思考与探索。以小组活动的方式集思广益，寻求最佳方案，再运用体系分工的方式达成价值提升或降低成本的目标。其中价值工程位于工程设计阶段，价值分析则在产品量产之后。但一般场合，两个概念不作区分。

3）备选方案生成
备选方案生成（Alternatives Generation），用来指定尽可能多的潜在可选方案的技术，用于识别执行项目工作的不同方法。许多通用的方法都可用于生成备选方案，如头脑风暴、横向思维、备选方案分析等。
（1）备选方案分析（Alternative Analysis），对已识别的可选方案进行评估，决定采用哪种方案。
（2）横向思维（Lateral Thinking），又称为戴勃诺理论、发散思维、水平思维，要求全面观察问题，从事物的多种联系和关系中去认识事物，不一定有观测顺序，也不能预测观测结果。相对应的有纵向思维（Vertical Thinking），在结构范围内，按照有顺序的、可预测的、程序化的方向进行思维。纵向思维遵循由低到搞，由浅入深，由始到终，清晰明了，合乎逻辑，比较符合事物发展方向和人类认识习惯。

4）引导式研讨会

2、项目范围说明书
项目范围说明书（Project Scope Statement）是定义范围过程的主要成果，描述项目范围、主要可交付成果、假设条件和制约因素的描述。

1）范围说明书的内容
描述要做和不要做的工作，包括：
（1）产品范围描述

（2）验收标准

（3）可交付成果
产品或服务，以及辅助成果，如各种文档。

（4）项目的除外责任
明确说明哪些内容不属于项目范围。

（5）制约因素

（6）假设条件
假设条件是指在制订计划时，不需验证即可视为正确、真实或确定的因素。在项目范围说明书中，需要列出并说明与项目范围有关的假设条件，以及万一不成立而可能造成的后果。项目推进过程中，项目团队应该经常识别、记录并验证这些假设条件。

2）范围说明书的作用
（1）确定范围
（2）沟通基础
（3）规划和控制依据
（4）变更基础
（5）规划基础

项目范围说明书同样适用于WBS。

3）项目范围说明书与项目章程的区别
二者内容有一定重叠，但详细程度不同。项目章程包括高层级的信息，而项目范围说明书则是对项目范围的详细描述。项目范围在项目建设过程中渐进明细，而项目章程一般保持不变。

五、创建工作分解结构（WBS）

创建WBS是将项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程，主要作用是对所要交付的内容提供一个结构化的视图。

工作分解结构（Work Breakdown Structure，WBS），是以可交付成果为导向的工作层级分解。WBS每下降一个层次意味着项目工作更详尽的定义。注意，WBS中的“工作”，并不是指工作本身，而是指工作所导致的产品或可交付成果。

1、WBS的层次
WBS将项目整体或主要可交付成果分解，分解成容易管理、方便控制的若干个子项目或者工作包；然后子项目继续分解为工作包，持续这个过程，直到整个项目都分解为可管理的工作包。所有工作包的总和是项目范围。

特点：
1）每层中的所有要素之和是下一层的工作之和
2）每个工作要素应该具体指派一个层次，而不应该指派给多个层次
3）WBS需要有投入工作的范围描述，这样才能使所有人对要完成的工作有全面的了解

名词解释：
1）里程碑
里程碑（Milestone），标志着某个可交付成果或者阶段的正式完成。每个分解单元中都存在可交付成果和里程碑。可交付成果包括报告、原型、成果和最终产品。里程碑和可交付成果联系紧密，关注于可交付成果是否完成，例如，产生了正式的用户认可文件。

2）工作包
工作包（Work Package），是位于WBS每条分支最底层的可交付成果，或项目工作组成部分。工作包非常具体与明确，便于分派给不同的人或组织单元，每个承担者能明确自己的任务、目标和责任。

工作包大小是需要考虑的细节，可以应用8/80规则（80小时原则），即每个工作包的大小应该不少于8小时，不大于80小时完成。

3）控制账户
控制账户（Control Account）是一种管理控制点，在这个点，整合了范围、预算（资源计划）、实际成本和进度，可以与挣值比较，用于测量绩效。

控制账户既可以是工作包，也可以是比工作包更高层次的要素。一个控制账户可以包括若干个工作包，而一个工作包只属于一个控制账户。控制账户的层次高低，表明了项目管理团队想对项目实施“粗管”还是“细管”。

4）规划包
规划包（Planning Package）是在控制账户之下，工作内容已知，但尚欠缺详细进度活动的WBS组成部分。代表管理团队知道是个什么成果，但还不清楚要执行哪些具体的活动才能达成。规划包用于暂时编制计划，随着情况逐渐明朗，规划包最终将被分解成工作包以及相应的具体活动。

5）WBS词典
WBS词典也称为WBS词汇表，是描述WBS各组成部分的文件，比如账户编码标识、工作描述、假设条件和制约因素、负责人、里程碑、质量要求、验收标准等等。

控制范围变更过程中，如果要评价变更的影响，WBS词典拥有比WBS更多的信息，因此作用也更大。

控制账户、工作包和WBS字典

2、WBS分解
创建WBS没有所谓正确的方式，使用白板、草图、或者专业软件，如Project都可以；常用的WBS分解方法有自上而下、使用组织指南、使用WBS模板等；而WBS组件整合方法有自下而上方法。

1）分解概述
创建WBS过程的工具与技术主要有分解和专家判断。分解是一种将项目可交付成果和项目工作分解成较小的、更易于管理的组件的技术。要将整个项目工作分解为工作包，通常需要开展以下活动：
（1）识别和分析可交付成果及相关工作
（2）确定WBS的结构和编排方法
（3）自上而下逐层细化分解
（4）为WBS组件制定和分配标识编码
（5）核实可交付成果分解的程度是恰当的

2）分解原则
（1）功能或者技术原则
创建WBS时，需要考虑将不同人员的工作分开。

（2）组织结构
对于职能型的项目组织而言，WBS也要适应项目的组织结构形式，因为职能部门之间的协调有时候非常困难。如果采用外包，WBS也应该反映出来。

（3）系统或者子系统
项目最常用的划分原则。系统划分为子系统，子系统再细分。

几个原则相互配合使用。

3）分解方式
（1）项目生命周期的各阶段作为分解的第二层，产品和项目可交付成果放在第三层，如图所示

（2）主要可交付成果作为分解的第二层

（3）整合可能由项目团队以外的组织来实施的各种图件（如外包），编制相应WBS

4）工作过程
WBS不是某个项目团队成员的责任，应该由全体项目团队成员、用户和项目干系人共同完成和一致确认。创建WBS过程如下

5）注意事项
WBS是逐层分解项目或者主要交付成果的过程，也是分派角色和职责的过程。分解过程中，需要注意几个方面：
（1）WBS必须是面向可交付成果的
（2）WBS必须符合项目的范围
（3）WBS的底层应该支持计划和控制。
WBS是项目管理计划和项目范围之间的桥梁，WBS要支持项目管理计划，也要让管理层能够监视和控制项目的进度和预算。

（4）WBS中的元素必须有人负责
（5）WBS应该控制在4~6层。不过这只是指导而不是原则。
（6）WBS应包括项目管理工作（因为管理是项目具体工作的一部分），也包括分包出去的工作
（7）WBS编制需要所有（或主要）项目干系人和项目团队成员参与。
（8）WBS并非一成不变，WBS完成编制后，随着项目推进，可能会被修改。也称为滚动修改原则。

3、WBS的作用
当一个项目的WBS分解完成后，项目干系人应该给予确认，并达成共识，然后才据此进行时间估算和成本估算。WBS的目的和用途体现在：
1）明确而准确地说明项目范围，项目团队成员能够清楚地理解任务的性质和需要努力的方向。
2）清楚地定义项目边界。
3）规定人员的职责
4）可以针对独立单元进行时间、成本和资源的估算，进而提高整个项目估算的准确性
5）确定项目进度和控制的基准
6）将项目工作和项目的财务账目联系起来
7）确定工作内容和工作顺序
8）有助于防止需求蔓延

六、确认范围

确认范围（Validate Scope）是正式验收项目已完成的可交付成果的过程，作用是使验收过程具有客观性，同时提高验收的可能性。确认范围包括与客户或发起人一起审查可交付成果，确保可交付成果已圆满完成，并获得客户或发起人的正式验收。

信息系统集成项目中，确认范围不是一件容易的事情。主要体现在与用户沟通上，特别是定制产品项目。项目团队倾向用户尽早确认范围，以便尽快开展下一步工作；而用户则认为自己什么都未看到，怎能确认。因此项目团队必须与用户充分沟通，让用户认识到，虽然确认项目范围是正式的，但并不意味着不能变更。只不过，无论何时更改项目范围，都会引起项目的时间、进度和资源的变化。

1、确认范围概述
确认范围的主要工具与技术是检查和群体决策技术。验收测试是一种典型的确认范围的技术。

1）确认范围的步骤
确认范围应该贯穿项目的始终。步骤如下：
（1）确定需要进行范围确认的时间。
（2）识别范围确认需要哪些投入。
（3）确定范围正式被接受的标准和要素。
（4）确定范围确认会议的组织步骤。
（5）组织范围确认会议。

2）需要检查的问题
（1）可交付成果是否确定、可确认？
（2）每个可交付成果是否有明确的里程碑，且里程碑是否明确可辨别？
（3）是否有明确的质量标准？
（4）审核和承诺是否有清晰的表达？
（5）项目范围有无遗漏或者错误
（6）项目范围的风险是否太高

2、干系人关注点
确认范围主要是项目干系人对项目的范围进行确认和接受的工作，每个人对项目范围所关注的方面有所不同。

管理层关注范围对项目的进度、资金和资源的影响，是否超出组织承受范围，投入产出是否合理。

客户主要关心产品的范围，关心项目的可交付成果是否足够完成产品或服务。

项目管理人员主要关注可交付成果是否足够，是否必须完成，时间、资金和资源是否充足，主要的潜在风险和预备解决的方法。

项目团队成员主要关心项目范围中自己参与和负责的部分，工作时间是否足够，是否有冲突。

如果发现项目范围有遗漏或错误，应当向项目团队明确指出，并给出修正意见。

3、几个术语的比较

1）确认范围与核实产品
确认范围是针对项目可交付成果，由客户或发起人在阶段末期确认验收的过程；合适产品时针对产品是否完成，在项目（或阶段）结束时由客户或发起人来验证，强调产品的完整性。

2）确认范围与质量控制
确认范围主要强调可交付成果获得客户或发起人的接受；质量控制强调可交付成果的正确性，并符合质量标准。
质量控制一般在确认范围前进行，而确认范围一般在阶段末尾进行。
质量控制属内部检查，确认范围是外部干系人对可交付成果进行验收。

详细程度，核实产品<确认范围<质量控制

3）确认范围与项目收尾
虽然二者都在阶段末进行，但确认范围强调的是核实与接受可交付成果，而项目收尾强调的是结束项目（或阶段）所要做的流程性工作，比如交接啥的。
二者都有验收工作，确认范围强调验收可交付成果，项目收尾强调验收产品。

可见项目范围总是与可交付成果联系在一起。

可交付成果：
产品或服务，以及辅助成果，如各种文档。

七、控制范围

控制范围（Control Scope）是监督项目和产品的范围状态、管理范围基准变更的过程，主要作用是在整个项目期间维护范围基准。

1、范围变更的原因
1）政策因素
2）项目范围编制不周密
3）形势发生了变化，有新技术出现
4）项目执行组织有变动
5）客户想法变了

产品或项目范围的未经控制而扩大，是为范围蔓延。项目建设过程中，变更常常不可避免。变更不可怕，但一定要走流程，实行变更控制。

2、范围变更控制的工作
1）对导致范围变更的因素施加影响，尽量让它们朝有利方向发展
2）判断范围变更是否已经发生
3）范围变更发生时，对变更进行管理，确保申请的变更都得到控制