范围管理计划

image-20230903212556530

范围管理

定义:

项目范围管理:包括确保项目做且只做所需的全部工作,以成功完成项目。

项目范围管理主要在意定义和控制那些工作应该包括在项目内,那些不应该包含在项目内。

范围管理的基础:
  • 产品范围和项目范围
    • 产品范围
      • 指某项产品、服务或成果所具有的特征和功能。
      • 衡量是否完成,根据产品需求来衡量的。产品需求规格说明书。
    • 项目范围
      • 包括产品范围,是为交付具有规定特征与功能的产品、服务或成果而必须完成的工作。
      • 衡量是否完成,根据项目管理计划来衡量的。
  • 管理新实践
项目范围管理过程
  • 过程概述,6个过程
    • 规范范围管理
  • 裁剪考虑因素
  • 敏捷与适应方法

image-20230903213356451

范围管理的六个过程

一、规范范围管理

定义:

规范范围管理是为了记录如何定义、确认和控制项目范围及产品范围,而创建范围管理计划的过程。

本过程的主要作用:

在整个项目期间对如何管理范围提供指南和方向。

开展频率:

仅开展一次或仅在项目的预定点开展。

规范范围管理-输入:
  1. 项目章程
  2. 项目管理计划
  3. 事业环境因素
    • 组织内部的事业环境因素
      • 组织文化、结构和治理
      • 设施和资源的物理分布
      • 基础设施
      • 信息技术软件
      • 资源可用性
      • 员工能力
    • 组织外部的事业环境因素
      • 市场条件
      • 社会和文化影响因素
      • 监管环境
      • 商业数据库
      • 学术研究
      • 行业标准
      • 财考虑因素
      • 物理环境因素
  4. 组织过程资产
    • 安保和安全
    • 治理文件
    • 数据资产
    • 过程资产
    • 知识资产
规范范围管理-工具与技术
  1. 专家判断
  2. 数据分析
  3. 会议

image-20230903214250961

规范范围管理-输出
  1. 范围管理计划

    定义:

    范围管理计划是项目管理的组成部分,描述将如何定义、制定、监督、就控制和确认项目范围。

    作用:

    指导如下过程和相关工作

    • 制定项目范围说明书
    • 根据详细项目范围说明书创建WBS
    • 确定如何审批和维护范围基准
    • 正式验收已完成的项目可交付成果

    特征:

    范围管理计划可以是正式的或非常是的,非常详细或高度概括的。

  2. 需求管理计划

    定义:

    需求管理计划是项目管理计划的组成部分,描述如何分析、记录和管理需求。

    主要内容:

    • 如何规划、跟踪和报告各种需求活动
    • 管理活动
    • 需求优先级排序过程
    • 测量指标及使用这些指标的理由
    • 反映那些需求属性江北列出跟踪矩阵等

二、收集需求

定义:

收集需求是为实现目标而确定,记录并管理干系人的需要和需求的过程。

本过程的主要作用:

是为定义产品范围和项目范围奠定基础。

开展频率:

本过程仅开展一次或仅在项目的预定义点开展。

收集需求-输入
  1. 立项管理文件
  2. 项目章程
  3. 项目管理计划
    • 范围管理计划
    • 需求管理计划
    • 干系人参与计划
  4. 项目文件
    • 假设日志
    • 干系人登记册
    • 经验教训登记册
  5. 协议
  6. 事业环境因素
    1. 组织内部事业环境因素
    2. 组织外部事业环境因素
  7. 组织过程资产
    1. 过程资产
    2. 治理文件
    3. 数据资产
    4. 知识资产
    5. 安保和安全
收集需求-工具与技术
  1. 专家判断

  2. 数据收集

    • 访谈
    • 头脑风暴
    • 焦点小组
    • 问卷调查
    • 标杆对照
      • 将实际或计划的产品、过程和时间,与其他科比组织得的实践进行比较,以便识别最佳实践,形成改进意见,并为绩效考核提供依据。
      • 标杆对照所采用的科比组织可以是内部的,也可以是外部的。
  3. 数据分析

    • 文件分析:文件分析指审核和评估任何相关的文件信息。
  4. 决策

    • 投票
    • 独裁型决策制定
    • 多标准决策分析
  5. 数据表现

    • 亲和图:用来对大量创意进行分组的技术,以便进一步审查和分析。
    • 思维导图:把从头脑风暴中获得的创意整合成一张图,用于反映创意之间的共性与差异,激发新创意。
  6. 人际关系与团队技能

    1. 名义小组技术

      用于促进头脑风暴的一种技术,通过投票排列最有用的创意,以便进一步开展头脑风暴或优先顺序。

      四个步骤:

      1. 向集体提出一个问题或难题,每个人在深思后写出自己的想法;
      2. 主持人在活动挂图上记录所有人的想法;
      3. 集体讨论各个想法,指导全体成员达成一个明确的共识;
      4. 个人私下投票决出各个想法的优先顺序,通常采用5分制,1分最低,5分最高。
    2. 观察和交谈:指直接察看个人在各自的环境中如何执行工作(或任务)和实施流程。

    3. 引导:引导与主题研讨会结合使用,把主要干系人着急在一起定义产品需求。研讨会可用于快速定义跨职能需求并协调干系人的需求差异。

  7. 系统交互图:系统交互图是对产品范围的可视化描述,可以直观显示业务系统(过程、设备、计算机系统等)以及 与人和其他系统(行动者)之间的交互方式。

  8. 原型法

    • 原型法是指在实际制造预期产品之前,先早出该产品的模型,并据此征求对需求的早起反馈。
    • 故事板:是一种原型技术,通过一系列的图像或图示来展示顺序或导航路径。
收集需求-输出
  1. 需求文件

    定义:

    需求文件描述各种单一需求将如何满足项目相关的业务需求。

    作为基准需求的特征:

    有明确的(可测量的可测试的)、可跟踪的、完整的、相互协调的,且干系人愿意认可的需求,才能作为基准

    需求的类别:

    1. 业务需求

      整个组织的高层级需要,例如,解决业务问题或抓住业务机会,以及实施项目的原因。

    2. 干系人需求

      干系人的需要。

    3. 解决方案需求(系统需求)

      为满足业务需求和干系人需求,产品、服务或成果必须具备的特性、功能和特征。

      分为:功能需求和非功能需求。

      功能需求:描述产品应具备的功能。例如:产品应该执行的行动、流程、数据和交互;

      非功能需求:是对功能需求的补充,是产品正常运行所需的环境条件或质量要求。例如:可靠性、保密性、性能、安全性、服务水平、可支持性、保留或清除等。

    4. 过度和就绪需求

      如数据转换和培训需求。这些需求描述了从当前状态过渡到将来状态所需的临时能力。

    5. 项目需求

      项目需要满足的行动、过程或其他条件,例如:里程碑日期、合同责任、制约因素等

    6. 质量需求

      用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准。例如:测试、认证、确认等

  2. 需求跟踪矩阵

    定义:

    需求跟踪矩阵是把产品需求从其来源连接到能够满足需求的可交付成果的一种表格。

    内容:

    1. 业务需要、机会、目的和目标
    2. 项目目标
    3. 项目范围和WBS可交付成果
    4. 产品设计
    5. 产品开发
    6. 测试策略和测试场景
    7. 高层级需求到详细需求等

    image-20230903222628535

三、定义范围

定义:

定义范围是制定项目和产品详细描述的过程。

本过程的主要作用:

是描述产品、服务或成果的边界和验收标准。

开展频率:

在整个项目期间多次反复开展。

定义范围-输入
  1. 项目章程
  2. 项目管理计划
  3. 项目文件
    • 假设日志
    • 需求文件
    • 风险登记册
  4. 事业环境因素
  5. 组织过程资产
定义范围-工具与技术
  1. 专家判断
  2. 数据分析
    • 备选方案分析:用于评估实现项目章程中所述的需求和目标的各种方法。
  3. 决策
    • 多标准决策分析
  4. 人际关机与团队技能
    • 引导
  5. 产品分析
    • 可用于产品和服务,包括针对产品或服务提问并回答,以描述要交付产品的用途、特征及其他方面。
定义范围-输出
  1. 项目范围说明书

    定义:项目范围说明书是对项目范围、可交付成果、假设条件和制约因素的描述。

    内容:

    • 产品范围描述:逐步细化在项目章程和需求文件中所述的产品、服务或成果特征。
    • 可交付成果:为完成某一过程、阶段或项目而必须产出的任何独特并可交付的产品、服务或成果能力,可交付成果也包括:各种辅助成果,如项目管理报告和文件。
    • 验收标准:可交付成果验收前必须满足的一系列条件。
    • 项目的除外责任:识别排除在项目之外的内容。

    注意-项目范围说明书与项目正常的区别

    • 虽然项目章程和项目范围说明书的内容存在一定程度的重叠,但它们的详细程度完全不同。
    • 项目章程包含高层级的信息,而项目范围说明书则是对范围组成部分的详细描述,这些组成部分需要在项目过程中渐进明细。
  2. 项目文件(更新)

四、创建WBS

定义:

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

本过程的主要作用:

为所要交付的内容提供架构

开展频率:

它仅开展一次或仅在项目的预定义点开展。

工作包:

WBS最底层的组成部分成为工作包,其中包括计划的工作。

创建WBS-输入
  1. 项目管理计划
  2. 项目文件:需求文件、项目范围说明书
  3. 事业环境因素
  4. 组织过程资产
创建WBS-工具与技术
  1. 专家判断

  2. 分析

    定义:分解是一种把项目范围和项目可交付成果逐步划分为更小,更便于管理的组成部分的技术。

    创建WBS的方法:

    • 自上而下的方法
    • 使用组织特定的指南
    • 使用WBS模板

    分解活动的分解步骤

    1. 识别和分析可交付成果及相关工作(看那些东西需要分析)
    2. 确定WBS的结构和编排方法(怎么分解)
    3. 自上而下逐层细化分解(分解)
    4. 为WBS组成部分制定和分配标识编码(编码)
    5. 核实可交付成果分解的程度是否恰当(检查下看看有没有错误的)

    WBS结构:

    1. 生命周期作为第2层image-20230904213130970
    2. 可交付成果作为第2层image-20230904213404061
    3. 包含外包工作:纳入由团队以外的组织开发的各种较低层组件(如外包工作)。随后,作为外包工作的一部分,卖方须制定相应的合同WBS。
    4. 滚动式规划:要在未来元气才完成的可交付成果或组件,当前可能无法分解。项目管理团队因而通常需要等待对该可交付成果或组成部分达成一致意见,才能够制定出WBS中的相应细节。

    注意事项:

    1. WBS必须是面向可交付成果的。
    2. WBS必须符合项目的范围:WBS必须包括也仅包括为了完成项目的可交付成果的活动。
    3. WBS的底层应该支持计划和控制
    4. WBS的元素必须有入负责,而且只有一个人负责
    5. WBS应控制在4~6层
    6. WBS应包括项目管理工作(因为管理是项目具体工作的一部分),也要包括分包出去的工作。
    7. WBS的编制需要所有(主要)项目干系人的参与
    8. WBS并非是一成不变的。
创建WBS-输出
  1. 范围基准

    定义:

    范围基准是经过批准的范围说明书、WBS和相应的WBS词典,只有通过正式的变更控制程序才能进行变更,它被用作比较的基础。

    其他概念:

    1. 项目范围说明书

    2. WBS

    3. 工作包

      • 控制账户:每个工作包都是控制账户的一部分,而控制账户则是一个管理控制点。在该控制点上,把范围、预算和进度加以整合,并于挣值相比较来测量绩效。
      • 工作包与控制账号的关系:控制账户包含两个或更多工作包,每个工作包只有一个控制账户关联。
    4. 规划包

      规划包是一种低于控制账户而高于工作包的工作分解结构组件,工作内容已知,但详细的进度活动未知,一个控制账户可以包含一个或多个规划包。

    5. WBS字典

      WBS字典是针对WBS中的每个组件,详细描述可交付成果、活动和进度信息的文件。

  2. 项目文件(更新)

    1. 假设日志
    2. 需求文件

五、确认范围

定义:

确认范围是正式验收已完成的项目可交付成果的过程。

本过程的主要作用:
  1. 是验收过程具有客观性
  2. 通过确认每个可交付成果来提高最终产品、服务或成果获得验收的可能性
开展频率

需要再整个项目期间定期开展

概念
  1. 确认范围的步骤

    确认范围步骤

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

    与质量控制的区别

    1. 确认范围关注可交付成果的验收
    2. 质量控制关注可交付成果的正确性及是否满足质量要求
    3. 控制质量过程通常先于确认范围过程,但二者也可以同时进行。
  2. 需要检查的问题

    1. 可交付成果是否确定的、可确认的
    2. 每个可交付成果是否有明确的里程碑,里程碑是否有明确的、可辨别的时间、例如:客户的书面认可等
    3. 是否有明确的质量标准
    4. 审核和承诺是否有清晰的表达
    5. 项目范围是否覆盖了需要完成的产品或服务的所有活动,有没有遗漏或错误
    6. 项目范围的风险是否太高
  3. 干系人关注点的不同

    1. 管理层主要关注项目范围

      是指范围对项目的进度、资金和资源的影响,这些因素是否超过了组织承受范围,是否在投入产出上具有合理性。

    2. 客户主要关注产品范围

      关心项目的可交付成果是否足够完成产品或服务

    3. 项目管理人员主要关注项目制约因素

      关心可交付成果是否足够和必须完成,时间、资金和资源是否足够,主要的潜在风险和预备解决方法

    4. 项目团队成员主要关注项目范围中自己参与的元素和负责的元素

      通过定义范围中的时间检查自己的工作时间是否足够,自己在项目范围中是否有多项工作,而这些工作是否有冲突的地方。

  

确认范围-输入
  1. 项目管理计划

    1. 范围管理计划
    2. 需求管理计划
    3. 范围基准
  2. 项目文件

    1. 需求文件
    2. 需求跟踪矩阵
    3. 质量报告
    4. 经验教训登记册
  3. 工作绩效数据

  4. 核实的可交付成果

    核实的可交付成果是指已经完成,并被控制质量过程检查为正确的可交付成果。

确认范围-工具与技术
  1. 检查

    检查是指开展测量、审查与确认等活动,来判断工作和可交付成果是否符合需求和产品验收标准。检查有时也被称为审查、产品审查和巡检等。

  2. 决策

    可用于确定范围过程决策技术是投票,当由项目团队和其他干系人进行验收时,使用投票来形成结论。

确认范围-输出
  1. 验收的可交付成果

    符合验收标准的可交付成果应由客户或发起人正式签字批准。

  2. 变更请求

    对已经完成但未通过正式验收的可交付成果及其未通过验收的原因,应该记录案。

  3. 工作绩效信息

    工作绩效信息包括项目进展信息,例如:哪些可交付成果已经被验收,哪些未通过验收以及原因。

  4. 项目文件(更新)

    1. 需求文件
    2. 需求跟踪矩阵
    3. 经验教训登记册

六、控制范围

定义:

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

本过程的主要作用:

是在整个项目期间保持对范围基准的维护。

开展频率:

本过程需要在整个项目期间开展。

范围蔓延:

未经控制的产品或项目范围的扩大(未对时间、成本和资源做出相应调整)被称为范围蔓延。

控制范围-输入:
  1. 项目管理计划
  2. 项目文件
  3. 工作绩效数据
  4. 事业环境因素
  5. 组织过程资产
控制范围-工具与技术:
  1. 数据分析:
    1. 偏差分析:用于基准与实际结果进行比较,以确定偏差是否处开临界值区间内或是否有必要采取纠正或预防措施。
    2. 趋势分析:旨在审查项目绩效随时间的变化情况,以判断绩效是正在改着还是正在恶化。
控制范围-输出:
  1. 工作绩效信息
  2. 变更请求
  3. 项目管理计划(更新)
  4. 项目文件(更新)

练一练

  1. 在()生命周期中,项目开始时就对项目可交付成果进行定义,对任何范围变化都要进行变更管理。

    • 预测型
    • 适应型
    • 敏捷型
    • 迭代型

    预测型:瀑布型

  2. ()不是规划范围管理过程的输入。

    • 项目章程
    • 项目管理计划
    • 质量管理计划
    • 需求管理计划
  3. 关于需求的理解,不正确的()。

    • 让干系人积极参与需求的探索和分解工作,并仔细确定、记录和管理对产品、服务或成果的需求,能直接促进项目成功
    • 为更好地对项目进行了解,收集需求的过程应在整个项目期间定期开展
    • 需求是指根据特定协议或其他强制性规范,产品、服务或成果必须具备的条件或能力
    • 需求包括发起人、客户和其他干系人的己量化且书面记录的需要和期望
  4. 数据收集技术中,()将实际或计划的产品、过程和实践,与其他可比组织的实践进行比较,以便识别最佳实践,形成改进意见,并为绩效考核提供依据。

    • 头脑风暴
    • 焦点小组
    • 亲和图
    • 标杆对比
  5. ()是把产品需求从其来源连接到能满虽需求的可交付成果的一种表格。

    • 系统交互图
    • 决策矩阵
    • 需求跟踪矩阵
    • uc矩阵
  6. 应根据()来编制详细的项目范围说明书。

    1. 可交付成果
    2. 假设条件
    3. 制约因素
    4. WBS
    5. 123
    6. 124
    7. 134
    8. 234

    根据详细的项目范围说明书来确定wbs。

  7. 关于项目范围说明书的理解,不正确的是()。

    • 项目范围说明书可明确指出哪些工作不属于本项目范围
    • 项目范围说明书使项目团队能进行更详细的规划,并为评价变更请求或额外工作是否超过项目边界提供基准
    • 项目范围说明书描述要做和不要做的工作的详细程度,决定着项目管理团队控制整个项目范围的有效程度
    • 项目范围说明书不能代表项目干系人之间就项目范围所达成的共识
  8. 范围基准包括()。

    1. 经过批准的范围说明书
    2. 项目章程
    3. wbs词典
    4. wbs
    5. 项目管理计划
    • 125
    • 124
    • 134
    • 145
  9. ()用于确认项目可交付成果的成功完成。

    • 业务需求
    • 解决方案需求
    • 质量需求
    • 过渡与就绪需求

    功能属于质量需求

  10. 关于确认范围的描述,不正确的是()。

    • 确认范围的作用之一是确保验收过程具有客观性
    • 确认范围过程通常先于控制质量过程,二者也可同时进行
    • 在确认范围时,要检查可交付成果是否有明确的质量标准
    • 管理层、客户、项目管理人员在确认范围的关注点有所不同
  11. 关于wbs的描述,正确的是()。

    • WBS中的各项工作为可交付成果提供服务
    • WBS的内容一般会超出完成可交付成果的活动范围
    • WBS的元素可以由一人或多人负责
    • WBS应包括分包的工作,但不包括管理工作

简答题

  1. 请简述确认范围过程与控制质量过程的不同之处。

    答:

    1. 关注点不一样

      确认范围过程关注的验收,

      控制质量过程关注的是可交付成果是否满足项目的质量要求

    2. 一般是先做确认范围过程,再做控制质量过程,两者也可同时进行。