第7章 项目范围管理

目录

7.2 编制范围管理计划和范围说明书

7.3 收集需求

7.4 范围定义

7.5 创建工作分解结构（WBS）

7.6 项目范围确认

7.7 项目范围控制

---

上午考察4分

7.1 项目范围管理概念

• 1. 项目范围管理√
  • 包括确保项目做且只做所需的全部工作，以成功完成项目的各个过程。
    • 关注的焦点是：为项目工作明确划定边界。即什么是包括在项目之内的，什么是不包括在项目之内的。
    • 因某种原因，要改变项目的工作边界时，项目范围管理会提供一套规范的方法去处理范围变更。
  • 项目范围是项目其他各方面管理的基础，若范围不清，成本、进度和质量等无从谈起。
  • 重要性：
    • （1）清楚了项目的工作具体范围和具体工作内容，为提高成本、时间、资源估算的准确性提供了基础；
    • （2）项目范围既然是确定要完成哪些具体的工作，项目范围基准是确定项目进度测量和控制的基准。
    • （3）项目范围的确定就是确定了项目的具体工作任务，有助于清楚的责任划分和任务分配；
  • 对项目范围管理和控制的有效性，是衡量项目是否达到成功的一个必要标准，项目范围的管理不仅仅是项目整体管理的一个主要部分，同时在项目中不断地重申项目工作范围，有利于项目不偏离轨道，是项目中实施控制管理的一个主要手段。
• 2. 范围管理过程【背】
  • （1）编制范围管理计划过程：对如何定义、确认和控制项目范围的过程进行描述
  • （2）收集需求：为实现项目目标，明确并记录项目干系人的相关需求的过程
  • （3）定义范围：详细描述产品范围和项目范围，编制项目范围说明书，作为以后项目决策的基础
  • （4）创建工作分解结构（WBS）：把整个项目工作分解成较小的、易于管理的组成部分，形成一个自下而上的分解结构
  • （5）确认范围：正式验收已完成的可交付成果
  • （6）范围控制：监督项目和产品的范围状态、管理范围基准变更。
• 3. 产品范围和项目范围√
  • 区别和联系（产品范围是项目范围的基础）
    • （1）产品范围：某项产品、服务或成果所具有的特性和功能。以是否完成产品需求说明书为衡量标准
    • （2）项目范围：是为完成所规定特性与功能的产品、服务或成果而必须完成的工作。有是项目范围又称为工作范围。以是否完成项目管理计划、项目范围说明书、WBS及字典为衡量标准（管理方面）
• 4. 范围管理ITO

  • 

7.2 编制范围管理计划和范围说明书

• 编制范围管理计划：是项目或项目集管理计划的组成部分，描述了如何定义、制定、监督、控制和确认项目范围。
  • 编制范围管理计划和细化项目范围始于对下列信息的分析：项目章程中的信息、项目管理计划中已批准的子计划等。
  • 作用：有助于降低项目范围蔓延的风险。
• 1. 编制范围管理计划ITO

  

• 2. 输入
  • 1）项目管理计划；
  • 2）项目章程，项目章程提供了高层级的项目描述和产品特征。产品特征出自项目工作说明书；
  • 3）组织过程资产
  • 4）事业环境因素
• 3. 工具与计算
  • 1）会议：与会人员可能包括项目经理、项目发起人、选定的团队成员、选定的干系人、范围管理各过程负责人以及其他必要人员。
  • 2）专家判断
• 4.输出
  • （1）范围管理计划：项目团队可以参加项目会议来制定范围管理计划。是项目或项目集管理计划的组成部分，描述了如何定义、制定、监督、控制和确认项目范围。
    • 作用：是制定项目管理计划过程和其他范围管理过程的主要依据。
    • 根据项目需要，范围管理计划可以是正式的或非正式的，非常详细或高度概括的。
    • 项目范围管理计划需要项目管理团队全员参与
    • 范围管理计划包括：
      • ①制定详细项目范围说明书；
      • ②根据详细项目范围说明书创建WBS；
      • ③维护和批准工作分解结构（WBS）；
      • ④正式验收已完成的项目可交付成果。
      • ⑤处理对详细项目范围说明书或WBS的变更。该工作与实施整体变更控制过程直接相联。
  • （2）需求管理计划：是项目管理计划的组成部分，描述了如何分析、记录和管理需求，以及阶段与阶段间的关系对管理需求的影响。
    • 项目经理为项目选择最有效的阶段间关系，并将它记录在需求管理计划中。需求管理计划的许多内容都是以阶段关系为基础的。
    • 需求管理计划包括：√
      • ①如何规划、跟踪和报告各种需求活动；
      • ②配置管理活动，例如：如何启动产品变更，如何分析其影响，如何进行追溯、跟踪和报告，以及变更审批权限。
      • ③需求优先级排序过程；
      • ④产品测量指标及使用这些指标的理由。
      • ⑤用来反映哪些需求属性被列入跟踪矩阵的跟踪结构。
      • ⑥收集需求过程。

7.3 收集需求

• 收集需求：是为实现项目目标而确定、记录并管理干系人的需要和需求的过程。
  • 主要作用：为定义和管理项目范围（包括产品范围）奠定基础。
• 1. 收集需求的ITO

  • 

• 2. 工具与技术
  • （1）访谈：访谈是通过与干系人直接交流来获取信息的 正式或非正式的方法。访谈经常是一个访谈者和一个被访谈者之间的“一对一”活动，但也可以包括多个访谈者或多个被访谈者。
  • （2）聚焦小组：聚焦小组是召集预订的干系人和专题专家，了解他们对所讨论的产品、服务或成果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论。焦点小组往往比“一对一”的访谈更热烈。
  • （3）引导式研讨会：引导式研讨会把主要干系人召集在一起，通过集中讨论来定义产品需求。研讨会是快速定义跨职能需求和协调干系人差异的重要技术。由于群体互动的特点，被有效引导的研讨会有助于参与者之间建立信任、改进关系、改善沟通，从而有利于干系人达成一致意见，此外，研讨会能够比单项会议更早发现问题、更快解决问题。
  • （4）群体创新技术☆：可以组织一些群体活动来识别项目和产品需求，常用的群体创新技术有：
    • 头脑风暴法。一种用来产生和收集对项目需求与产品需求的多种创意的技术；
    • 名义小组技术。用于促进头脑风暴的一种技术，通过投票排列最有用的创意，以便进一步开展头脑风暴或有限排序。
    • 概念/思维导图。把从头脑风暴中获得的创意整合成一张图的技术，以反映创意之间的共性与差异，激发新创意。
    • 亲和图。用来对大量创意进行分组的技术，以便进一步审查和分析。
    • 多标准决策分析。借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，从而对众多方案进行评估和排序的一种技术。
  • （5）群体决策技术☆：群体决策技术就是为达成某种期望结果，而对多个未来行动方案进行评估的过程。本技术用于生产产品需求，并对产品需求进行归类和优先级排序，例如：
    • 一致同意：每个人都同意某个行动方案。
    • 大多数原则：获得群体超过50%人员的支持，就能做出决策。把参与决策的小组人数定为奇数，防止因平局而无法达成决策。
    • 独裁：由某一个人为群体做出决策。
  • （6）问卷调查：问卷调查是指设计一系列书面问题，向众多受访者快速收集信息。问卷调查方法非常适用于以下情况：受众多样化，需要快速完成调查，受访者地理位置分数，并且适合开展统计分析。
  • （7）观察：观察是指直接察看个人在各自的环境中如何执行工作（或任务）和实施过程。
  • （8）原型法：原型法是指在实际制造预期产品之前，先造出该产品的实用模型，并据此征求对需求的早期反馈。原型法支持渐进明细的理念，需要经历从模型创建、用户体验、反馈收集到原型修改的反复循环过程。在经过足够的反馈循环后，就可以通过原型获得足够的需求信息，从而进入设计或制造阶段。
  • （9）标杆对照： 标杆对照将实际或计划的做法（如流程和操作过程）与其他可比组织的做法进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。标杆对照所采用的可比组织可以是内部的，也可以是外部的。
  • （10）系统交互图：系统交互图是范围模型的一个例子，它是对产品范围的可视化描述，显示业务系统及其他与人和其他系统（行动者）之间的交互方式。系统交互图显示了业务系统的输入、输入提供者、业务系统的输出和输出接收者。
  • （11）文件分析：文件分析就是通过分析现有文档，识别与需求相关的信息，来挖掘需求。
• 3. 输入
  • 范围管理计划
  • 需求管理计划
  • 干系人管理计划
  • 项目章程
  • 干系人登记册
• 4. 输出
  • 1）需求文件：描述各种单一需求如何满足与项目相关的业务需求；
  • 2）需求跟踪矩阵：把产品需求从其来源连接到能满足的可交付成果的一种表格。
    • 作用：
      • （1）把每个需求与业务目标或者项目目标联系起来，有助于确保每个需求都具有商业价值。
      • （2）需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法，有助于确保需求文件中被批准的每项需求在项目结束的时候都能交付。
      • （3）为管理产品范围变更提供了框架。
    • 内容：应在需求跟踪矩阵中记录每个需求的相关属性。需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态和状态日期。为保证干系人满意，可能需要增加一些补充属性，如稳定性、复杂性和验收标准。

7.4 范围定义

• 1. 范围定义
  • 定义范围：定义范围是制定项目和产品详细描述的过程
    • 主要作用：明确所收集的需求哪些将包含在项目范围内，哪些将排除在项目范围外，从而明确项目、服务或输出的边界。
    • 范围迭代过程：
      • 准备好详细的项目范围说明书，对项目成功至关重要。应根据项目启动过程中记载的主要可交付成果、假设条件和制约因素来编制项目范围说明书。在项目规划过程中，随着对项目信息的更多了解，应该更加详细具体地定义和描述项目范围。还需要分析现有风险、假设条件和制约因素的完整性，并做必要的增补或更新。需要多次反复开展定义范围过程。
      • 在迭代型生命周期的项目中，先为整个项目确定一个高层级的愿景，再针对每一次迭代明确详细范围。通常，随着当前迭代的项目范围和可交付成果的进展，而详细规划下一次迭代的工作。
  • 最重要的任务就是：详细定义项目的范围边界，范围边界是应该做的工作和不需要进行的工作分界线。
  • 意义：定义范围可以增加项目时间、成本和资源估算的准确度，定义项目控制的依据，明确相关责任人在项目中的责任，明确项目的范围、合理性和目标，以及主要可交付成果。
• 2. 范围定义的ITO

  • 

• 3. 输入
  • （1）范围管理计划：确定了制定、监督和控制项目范围的各种活动
  • （2）项目章程：包含对项目和产品特征的高层级描述、项目审批要求。
    • 如果执行组织不使用项目章程，则应取得或编制类型的信息，用做制定详细范围说明书的基础。
    • 如果组织不制定正式的项目章程，通常会进行非正式的分析，为后续的范围规划提供依据。
  • （3）需求文件：描述各种单一需求将如何满足与项目相关的业务需求。一开始，可能只有高层级的需求，然后随着有关需求信息的增加而逐步细化。只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的，且主要干系人愿意认可的需求，才能作为基准。
    • 需求文件的主要内容至少包括：
      • 1）业务需求，包括：可跟踪的业务目标和项目目标、执行组织的业务规则、组织的指导原则；
      • 2）干系人需求，包括：对组织其他领域的影响、对执行组织内部或外部团体的影响、干系人对沟通和报告的需求；
      • 3）解决方案需求，包括：功能和非功能需求、技术和标准合规性需求、支持和培训的需求、质量需求、报告需求（可用文本记录或用模型展示解决方案需求，也可两者同时使用）；
      • 4）项目需求，例如服务水平、绩效、安全和合规性，以及验收标准。
      • 5）过渡需求；
  • （4）组织过程资产
• 4. 输出
  • （1）项目范围说明书
  • （2）项目文件更新。可能需要更新的项目文件至少包括：干系人登记册、需求文件、需求跟踪矩阵。
• 5. 工具和技术
  • （1）产品分析：产品分析旨在弄清产品范围，并把对产品的要求转化成项目的要求（即有形的可交付成果）。
    • 包括：产品分解、系统分析、需求分析、系统工程、价值工程和价值分析等。
    • 例如：一个IT系统可以划分为几个子系统，以及这些子系统之间如何交互，直接影响到项目团队如何实现这些子系统，即采用什么样的项目策略，从而影响到项目范围的定义。
  • （2）专家判断
  • （3）备选方案生成：是一种用来制定尽可能多的潜在可选方案的技术，用于识别执行项目工作的不同方法。许多通用的管理技术都可用于生成备选方案，如头脑风暴、横向思维、备选方案分析等。
  • （4）引导式研讨会：具有不同期望或专业知识的关键人物参与研讨会，有助于项目目标和项目限制达成跨职能的共识
  • 其中，目标优化矩阵是项目管理中进行干系人收集需求调查的有效工具之一，它可以被设计成客户调查表或名义调查表来使用，而且可以大规模取样，涉及的人越多越好。
• 6. 范围说明书
  • 项目范围说明书：是对项目范围、主要可交付成果、假设条件和制约因素的描述。——>明确指出哪些工作不属于本项目范围
    • 项目范围说明书记录了整个范围，包括项目和产品范围。
    • 项目范围说明书详细描述项目的可交付成果，以及创建这些可交付成果而必须开展的工作。
  • 项目范围边界一定是闭合的，否则我们就不能判断某变更是对原项目范围的变更还是新添加的项目范围。
  • 详细的范围说明书或引用的文档通常包含以下内容：
    • ①项目目标
    • ②产品范围描述
    • ③项目需求
    • ④项目边界
    • ⑤项目的可交付成果
    • ⑥项目的制约因素
    • ⑦假设条件
    • 范解可约虚假目标
  • 虽然项目章程和项目范围说明书的内容存在一定程度的重叠，但它们的详细程序完全不同。（对比着看）
  • 项目章程包含高层级的信息，而项目范围说明书则是对项目范围的详细概述。项目范围需要在项目过程中渐进明细。

7.5 创建工作分解结构（WBS）

• 1.工作分解结构（WBS）
  • 1）作用和意义
    • 定义：是把项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程
    • 主要作用：对所要交付的内容提供一个结构化的视图。
  • 2）包含的内容
    • WBS最低层的工作单元被称为工作包，是进行进度安排、成本估算和监控的基础。
    • 工作包对相关活动进行归类：
      • ①项目的全部工作都必须包含在工作分解结构当中
        • 而且不包含在工作分解结构中的任何工作都不是项目的组成部分，都不能做，否则就是“镀金”。—>工作分解结构必须且只能包括100%的工作。
      • ②工作分解结构的编制需要所有项目干系人的参与，需要项目团队成员的参与 
        • 各项目干系人站在自己的立场上，对同一个项目可能编制出差别较大的工作分解结构。项目经理应发挥“整合者”的作用。组织他们进行讨论，以便编制出一份大家都能接受的工作分解结构；
      • ③逐层向下分解的。工作分解结构最高层的要素总是整个项目或分项目的最终成果。
        • 工作分解结构中每条分支分解层次不必相等。
        • 一般情况下，工作分解结构应控制在3~6层为宜。若项目比较大，以至于工作分解结构要超过6层，可以将大项目分解成子项目，然后对子项目做工作分解结构。
        • 工作分解结构中的各要素应该是相对独立的，要尽量减少相互之间的交叉。
    • 较常用的工作分解结构表示形式主要有以下两种：
      • ①分级的树形结构：层次清晰、非常直观、结构性强，但是不容易修改，一般在一些小的项目
      • ②表格形式：反映出项目所有的工作要素，直观性较差。但在一些大型的、复杂的项目中使用得比较多
    • 工作分解中的一些概念
      • （1）里程碑：“里程碑=具体时间+在这个时间应完成的事件”
        • 重要的检查点叫做里程碑；
        • 重要的里程碑叫做基线；
      • （2）工作包：工作包是位于工作分解结构每条分支最低层的可交付成果或项目工作组成部分。
        • 作为一种经验法则，8/80规则（80小时原则）建议工作包的大小应该至少需要8个小时来完成，而总完成时间也不应该大于80小时。
        • 判断：具有如下特征之一，就可能被当作工作包：
          • ①规模较小，可以在短时间（80小时）完成；
          • ②从逻辑上讲，不能再分了。
          • ③所需资源、时间、成本等已经可以比较准确的估算，已经可以对其进行有效的时间、成本、质量、范围和风险控制。
      • （3）WBS编码设计：通常利用编码技术对WBS进行信息交换，以现实简化WBS的信息交流过程。
  • 3）创建WBS的ITO

    • 

• 2. 工具与技术
  • （1）分解
    • 分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的单元，直到可交付物细分到足以用来支持未来的项目活动定义的工作包。
    • 通常需要开展以下活动：
      • 识别和分析可交付成果及相关工作。
      • 确定 WBS的结构和编排方法。
      • 自上而下逐层细化分解。
      • 为WBS组件制定和分配标识编码。
      • 核实可交付成果分解的程度是否恰当。
    • WBS 分解的方法
      • ①使用项目生命周期的阶段作为分解的第一层，而把项目可交付物安排在第二层
      • ②把项目重要的可交付物作为分解的第一层
      • ③把子项目安排在第一层，再分解子项目的WBS
    • 工作结构分解应把握如下原则：
      • ①在层次上保持项目的完整性，避免遗漏必要的组成部分；
      • ②一个工作单元只能从属于某个上层单元，避免交叉从属；
      • ③相同层次的工作单元应用相同性质；
      • ④工作单元应能分开不同的责任者和不同的工作内容；
      • ⑤便于项目管理计划和项目控制的需要；
      • ⑥最底层工作应该具有可比性，是可管理的，可定量检查的；
      • ⑦应包括项目管理工作，包括分包出去的工作。
  • （2）专家判断
• 3.输入
  • 1）项目范围管理计划：定义了应该如何根据详细项目说明书创建WBS，以及应该如何维护和批准WBS。
  • 2）项目范围说明书：描述了需要实施的工作及不包含在项目中的工作，同时也列举和描述了会影响项目执行的各种内外部制约或限制条件。
  • 3）需求文件
• 4.输出
  • 1）范围基准：经过批准的范围说明书、工作分解结构（WBS）和相应的WBS词典组成了范围基准，只有通过正式的变更控制程序才能进行变更这个基准，它被用作比较的基础。
    • 范围基准是项目管理计划的组成部分，包括:
    • （1）项目范围说明书：包括对项目范围、主要可交付成果、假设条件和制约因素的描述。
    • （2）WBS
    • （3）WBS词典：是针对每个WBS组件，详细描述可交付成果、活动和进度信息的文件。WBS词典对WBS提供支持。WBS词典中的内容可能至少包括：账户编码标识、工作描述、假设条件和制约因素、负责的组织、进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献、协议信息。
  • 2）项目文件更新：可能需要更新的项目文件至少包括需求文件。

7.6 项目范围确认

• 1. 项目范围确认概述
  • 确认范围：是正式验收已完成的项目可交付成果的过程。
  • 确认范围需要审查可交付物和工作成果，以保证项目中所有工作都能准确地、满意地完成。
  • 确认范围应该贯穿项目的始终，从WBS的确认或合同中具体分工界面的确认，到项目验收时范围的检验。
  • 确认范围过程应该以书面文件的形式把它完成情况记录下来。
  • 主要作用是：使验收过程具有客观性，同时通过验收每个可交付成果，提高最终产品、服务或成果获得验收的可能性。
• 2. 项目范围确认的工作要点
  • （1）制定并执行确认程序。
    • 确认范围过程与控制质量过程的不同之处在于，前者关注可交付成果的验收，而后者关注可交付成果的正确性及是否满足质量要求。控制质量过程通常优先于确认范围过程，但二者也可同时进行。
    • 确认范围的一般步骤如下：
      • 确定需要进行确认范围的时间；
      • 识别确认范围需要哪些投入；
      • 确定范围正式被接受的标准和要素；
      • 确定确认范围会议的组织步骤；
      • 组织确认范围会议。
  • （2）项目干系人对项目范围的正式承认。在每个阶段中，有必要说明最重要的活动，但没必要过分强调涉及细节。除非项目干系人特别提到，而且要有详细讨论每个细节的准备。项目干系人进行确认范围时，一般需要检查以下6个方面的问题：
    • 可交付成果是否确实的、可确认的或者说可核实的；
    • 每个交付成果是否有明确的里程碑，里程碑是否明确可辨别的。例如：客户的书面认可书等。
    • 是否有明确的质量标准；
    • 审核或承诺是否表达清晰。项目投资人必须正式同意项目的边界、项目完成的产品或服务、以及项目相关的可交付成果。项目团队必须清楚了解并取得一致的意见。
    • 项目范围是否覆盖了需要完成的产品或服务进行的所有活动；
    • 项目范围的风险发生概率，管理层是否能够降低可预见性的风险对项目的影响。
• 3. 项目范围确认ITO

  • 

• 4. 工具与技术
  • （1）检查：开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准，是否满足项目干系人的要求和期望。检查有时也被称为审查、产品审查、审计和巡检等。
  • （2）群体决策技术：为达成某种期望结果，而对多个未来行动方案进行评估的过程。本技术用于生成产品需求，并对产品需求进行归类和优先级排序。达成群体决策的方法有很多，例如：一致同意、大多数原则、相对多数原则、独裁。

7.7 项目范围控制

• 1. 项目范围控制概述
  • 范围控制：是监督项目和产品的范围状态，管理范围基准变更的过程。
  • 未经控制的产品或项目范围的扩大被称为范围蔓延。
  • 变更不可避免，因此在每个项目上，都必须以书面的形式记录并实施某种形式的变更控制管理。
  • 作用：在整个项目期间保持对范围基准的维护。
• 2.项目范围控制与用户需求变更的联系
  • 用户的需求变更必须控制在可控范围之内。
  • 需求基线定义了项目的范围。随着项目的进展，用户的需求可能发生变化，从而导致需求基准变化以及项目范围的变化。每次需求变更并经过需求评审后，都要重新确定新的需求基线。项目组需要维护需求基线文档，保存好各个版本的需求基线，以备不时之需。
• 3. 范围控制ITO

  • 

• 4. 工具与技术
  • 偏差分析：是一种确定实际绩效与基准的差异程度及原因的技术。
    • 可利用项目绩效测量结果评估偏离范围基准的程度，确定偏离范围基准的原因和程度，并决定是否需要采取纠正或预防措施，是项目范围控制的重要工作。
• 5. 输入
  • 项目管理计划：用于范围控制的，如范围基准、范围管理计划、变更管理计划、配置管理计划、需求管理计划；
  • 需求文件：应明确（可测量且可测试）、可跟踪、完整、一致且得到主要干系人的认可。记录完好的需求文件便于发现任何对批准的项目或产品范围的偏离。
  • 需求跟踪矩阵：有助于发现任何变更或对范围基准的任何偏离给项目目标造成的影响。
  • 工作绩效数据：可能包括变更请求的数量、接受的变更请求的数量，或完成的可交付成果数量等
• 6. 输出
  • 工作绩效信息；
  • 变更请求；
  • 项目管理计划更新，可能至少包括：
    • 范围基准更新；
    • 其他基准更新；
    • 项目文件更新；
  • 确认范围，正式验收已完成的可交付成果；
  • 范围控制，监督项目和产品的范围状态、管理范围基准变更。