PMP第五章项目范围管理

美国著名商学院PMP核心课程。 项目管理人才已成为中国最稀缺的人力资源之一，这是近年来我办才市场上不断传出的信息。最近两年，项目管理已被我国外国专家局成功的引入了中国，美国项目管理扫员会已在中国进行PMP资格认证考试。一批有志于成为企业管理精英的人士，将有幸获得美国项目管理委员会颁布的PMP证书。 本书的显著特点是，既具有一定的理论性，又具有很强的实用性和可操作性，非常适合参加项目管理培。

项目范围管理

• 核心概念
  • 范围定义（做且做所需的全部工作）
    • 产品范围
      • 某项产品、服务或成果所具有的特征和功能
        • 决定项目范围
        • 自身变化不一定会引起项目范围的变化
        • 不包含项目范围
        • 衡量依据：产品需求文件
    • 项目范围
      • 为交付具有规定特性与功能的产品、服务或成果二必须完成的工作
        • 服务于产品范围
        • 自身变化不一定会引起产品范围的变化
        • 广义上有时也包括产品范围
        • 衡量依据：项目管理计划
      • 生命周期之范围管理对比
        • 预测型生命周期
          • 项目开始时就对项目可交付成果进行定义，对任何范围变化都要进行渐进管理
          • 需求稳定，技术成熟
          • 项目开始时从所有需求中开展这些过程，必要时通过实时整体变更控制过程进行更新
          • 确认范围：每个可交付成果生成时或在阶段审查点
          • 控制范围：持续性进行
          • 最终范围基准：项目范围说明书+WBS+WBS词典
        • 适应性/敏捷型生命周期
          • 通过多次迭代来开发可交付成果，并在每次迭代开始时定义和批准i详细的范围
          • 应对大量变更，相关方持续参与
          • 在每个迭代开始时，在产品未完成项中选择最优先项开展这些过程
          • 确认、控制范围：每次迭代中，都会重复开展两个过程
          • 最终范围基准：未完成项，包含产品需求和用户故事
• 发展趋势和新兴实践
  • 通过定义、管理和控制需求活动来提高竞争优势
  • 商业分析活动可在项目启动和项目经理任命之前就开始
  • 注重与商业分析专业人士的合作
  • 需求管理过程 始于 需要评估， 结束于 需求关闭。
  • 项目经理与商业分析师之间是 伙伴式合作 关系。
    • 商业分析师 负责 需求管理相关 的活动
    • 项目经理 负责确保这些活动在项目管理 计划有所安排 ，并且在 预算内按时完成 ，同时能够 创造价值
• 敏捷或适应性环境因素中需要考虑的因素
  • 特意在项目早期 缩短定义和协商范围的时间 ，并为持续探索和明确范围而延长创建相应过程的时间。
  • 有目的地 构建和审查原型 ，并通过 多次发布版本 来明确需求。 把需求列入未完项
• 裁剪时需要考虑的因素
• 过程包括
  • 规划范围管理（规划过程组）
    • 为了记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程。
    • 主要作用：在整个项目期间对如何管理范围提供指南和方向
    • 输出
      • 范围管理计划
        • 描述将 如何 定义、制定、监督、控制和确认项目范围。
        • 注意点
          • 范围管理计划无范围 （范围在范围基准中
          • 范围管理计划可以是正式或非正式的，非常详细或高度概括的。
      • 需求管理计划（商业分析计划
        • 描述将 如何 分析、记录和管理项目和产品需求。
        • 注意点
          • 需求管理计划无需求 （需求在需求文件中
          • 内容包括配置管理活动、需求优先级排序过程、测量指标等。
  • 收集需求（规划过程组）
    • 为实现目标而 确定 、 记录 并 管理 相关方的 需要和需求 的过程。
    • 本过程的作用：为定义产品范围和项目范围奠定基础。
    • 需求
      • 定义：根据 特定协议 或其他 强制性规范 ，产品、服务或成果 必须具备 的条件或能力。
      • 需求包括发起人、客户和其他相关方的 已量化 且 书面记录 的需要和期望。
    • 输入
      • 项目文件
        • 相关方登记册
          • 用于了解 哪些相关方能够提供需求 方面的信息，及记录 相关方对项目的需求和期望
      • 商业文件
        • 会影响收集需求过程的商业文件是 商业论证 ，它描述了 为满足业务需要 而 应该达到 的 必要 、 期望 及 可选标准
      • 协议
        • 会影响收集需求过程的商业文件是商业论证，描述了为满足业务需要而应该达到的必要、期望及可选标准
    • 工具与技术
      • 数据收集
        • 头脑风暴
          • 大量创意、各种想法、畅所欲言
        • 访谈
          • 直接交谈、预设和即兴问题、一对一、多对多、获取机密信息
        • 焦点小组
          • 同职能、同一领域、有相似背景、主题专家（SME）、主持人引导互动式讨论
        • 问卷调查
          • 受众多样化、需快速完成、地理位置分散、适合开展统计分析
        • 标杆对照
          • 标杆可以是内部或外部、同行业或不同行业、识别最佳实践、形成改进意见
      • 数据分析
        • 文件分析
          • 分析现有文件
      • 决策
        • 投票
          • 一致同意
            • 每个人都同意、德尔菲（专家、匿名、多轮、趋同、消除偏见）
          • 大多数同意
            • 超过50％、一般把决策小组的人数定为奇数
          • 相对多数同意
            • 相对多数，通常候选项超过两个时使用。
        • 独裁型决策制定
          • 一个人做决策
        • 多标准决策分析
          • 决策矩阵、多种标准、评估和排序
            • 权重*得分求出总分比较
      • 数据表现
        • 亲和图
          • 分组、分类
        • 思维导图
          • 整合、反映共性与差异、激发新创意、脑图
      • 人际关系与团队 技能
        • 名义小组
          • 促进头脑风暴、投票、优先排序、5 分制、数轮
        • 观察（工作跟随）和交谈
          • “工作跟随”、难以或不愿清晰说明、挖掘隐藏的需求
        • 引导
          • 概念
            • 与主题研讨会结合使用、跨职能、不同部门、协调相关方差异
          • 情景
            • 联合应用设计或 开发（ JAD
              • 软件开发行业、业务主题专家和开发团队集中
            • 质量功能展开 QFD
              • 制造行业、收集客户需要（客户声音）开始、分类和排序
            • 用户故事
              • 需求研讨会、角色、目标、动机
              • 对所需功能的简短文字描述
      • 系统交互图
        • 拓扑图、产品范围可视化
      • 原型法
        • 支持渐进明细的理念。例如：故事板，能减轻返工的风险。
        • 步骤（反复循环）：1. 模型创建、 2. 用户体验、 3. 反馈收集、 4. 原型修改（可能需要走变更流程）
    • 输出
      • 需求文件（单一需求）
        • 描述各种单一需求将如何满足与项目相关的业务需求
        • 只有明确的(可测量和可测试的)、可跟踪的、完整的、相互协调的，且主要相关方愿意认可的需求，才能作为基准
        • 需求的类别
          • 业务需求
            • 整个组织的高层及需要
          • 相关方需求
            • 相关方或相关方群体的需要
          • 解决方案需求
            • 分类
              • 功能需求
                • 描述产品应具备的功能
              • 非功能需求
                • 对功能需求的补充，是产品正常运行所需的环境条件或质量要求
            • 为满足业务需求和相关方需求，产品、服务或成果必须具备的特性、功能和特征。
          • 过渡和就绪需求
            • 描述了从“当前状态”过渡到“将来状态”所需的临时能力，如数据转换和培训需求
          • 项目需求
            • 满足的行动、过程或其他条件，如里程碑日期、合同责任、制约因素等
          • 质量需求
            • 确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准，例如测试、认证、确认等
      • 需求跟踪矩阵
        • 是把产品需求从其他来源连接到能满足需求的可交付城关的一种表格。
        • 把每个需求与业务目标或项目目标联系起来，有助于确保每个需求都具有商业价值
        • 提供了在整个项目生命周期中跟踪需求的一种方法（正向追踪、逆向追踪）
        • 有助于确保需求文件中被批准的每项需求在项目结束的时候都能交付。
        • 收集需求时产生的需求文件和需求追踪矩阵并不代表项目的真实范围
        • 需要进一步明确哪些包含在项目范围内，哪些排除在项目范围外。（定义范围）
  • 定义范围（规划过程组）
    • 制定项目和产品详细描述的过程
    • 主要作用：描述产品、服务或成果的边界和验收标准
    • 从需求文件中选取最终的项目需求，然后指定出关于项目及其产品、服务或成果的详细描述
    • 应根据项目启动过程中记载的主要可交付成果、假设条件和制约因素来编制详细的项目范围说明书
    • 还需要分析现有风险、假设条件和制约因素的完整性，并做必要的增补或i更新。
    • 需要多次反复开展定义范围过程（涉及多个迭代）
    • 输入
      • 项目章程（高层级需求）
        • 包含对项目的高层级描述、产品特征和审批要求
      • 项目文件
        • 需求文件
          • 识别了应纳入范围的需求
    • 工具与技术
      • 数据分析
        • 备选方案分析
      • 决策
        • 多标准决策分析
      • 人际关系与团队技能
        • 引导
          • 在研讨会和座谈会中使用引导技能来协调具有不同期望或不同专业背景的关键相关方，使他们就项目可交付成果以及项目和产品边界达成跨职能的共识。
      • 产品分析
        • 把高层级的产品描述转变为有形的的可交付成果。产品分析技术包括产品分解、系统分析、需求分析、系统工程、价值工程、价值分析等。
    • 输出
      • 范围说明书（可交付成果/验收标准）
        • 是对项目范围、主要可交付成果、假设条件和制约因素的描述。记录了整个范围，包括项目和产品范围。
        • 详细描述了项目的可交付成果，还代表项目相关方之间就项目范围所达成的共识
        • 为了便于管理相关方的期望，项目范围说明书可明确指出哪些工作不属于本项目范围
        • 包括以下内容
          • 产品范围描述
            • 逐步细化在项目章程和需求文件中所述的产品、服务或成果的特征
          • 可交付成果
            • 必须产出的任何独特并可核实的产品、成果或服务能力。也包括辅助成果，如项目管理报告和文件
          • 验收标准
            • 可交付成果通过验收前必须满足的一系列条件
          • 除外责任
            • 明确说明那些内容不属于项目范围，有助于管理相关方的期望及减少范围蔓延
  • 创建WBS（规划过程组）（工作分解结构 Work Breakdown Stucture）
    • 把项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程
    • 本过程的作用：对所要交付的内容提供架构
    • WBS组织并定义了项目的总范围（项目范围说明书只定义范围，没有组织范围）
    • WBS最低层的组成部分称为工作包，其中包括计划的工作
    • 在工作分解结构这个词语中，工作是指作为活动结果的工作产品或可交付成果，而不是活动本身
    • 工具与技术
      • 分解
        • 把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术
      • 工作包
        • WBS最低层的组件，可对其成本和持续时间进行估算和管理
      • 创建WBS，就是要将整个项目工作分解为工作包
    • 分解的五个步骤
      • 1.识别和分析可交付成果及相关工作
      • 2.确定WBS的结构和编排方法
      • 3.自上而下逐层细化分解
      • 4.为WBS组件制定和分配标识编码
      • 5.核实可交付成果分解的程度是否恰当
    • WBS结构的形式
      • 把项目生命周期的各阶段作为分解的第二层，产品和项目可交付成果放在第三层
      • 把主要可交付成果作为分解的第二层
      • 纳入由项目团队以外的组织开发的各种较低层次组件（如外包工作）
    • 创建WBS的四个注意
      • 如果采用敏捷方法，可以将长篇故事分解成用户故事
      • 不同的可交付成果可以分解到不同的层次
      • 并不是分解的越细越好，过细的分解会造成管理努力的无效消耗、资源使用效率低下、工作实施效率降低，同时造成WBS各层级的数据汇总困难
      • 远期才完成的可交付成果或组件，当前可能无法分解（规划包），需要滚动式规划
    • 四个主要原则
      • 100%原则
      • 有明确责任人
      • 80小时原则
      • 不宜过细分解
    • 创建WBS的方法
      • 自上而下
      • 自下而上
    • 输出
      • 范围基准
        • 项目范围说明书
          • 项目范围
          • 主要可交付成果
          • 验收标准
          • 项目的除外责任
        • WBS
          • 工作包
          • 规划包
          • 控制账户
            • 是一个管理控制点(可以与组织的财务程序链接)，在该控制点上，把范围、预算、实际成本和进度加以整合，并与挣值相比较，以测量绩效
            • 每个控制账户可能包括一个或多个工作包(或规划包)，但是一个工作包只能属于一个控制账户
            • 绩效测试基准PMB：由范围基准、进度基准、成本基准共同构成
        • WBS词典
          • 针对WBS中的每个组件，详细描述可交付成果、活动和进度信息的文件
  • 确认范围（监控过程组）
    • 客户或发起人正式验收已完成的项目可交付成果的过程
    • 本过程的作用：通过验收每个可交付成果，提高最终产品、服务或成果验收的可能性
    • 输入
      • 核实的可交付成果
        • 已经完成，并被控制质量过程检查为正确的可交付成果
    • 工具与技术
      • 检查(审查、产品审查、巡检)
        • 开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准
    • 输出
      • 验收的可交付成果
        • 符合验收标准的可交付成果应该由客户或发起人正式签字批准
        • 应该从客户或发起人那里获得正式文件，证明相关方对项目可交付成果的正式验收
      • 变更请求
        • 如果验收未通过，处理步骤1.记录(了解)原因；2走变更流程，进行缺陷补救
  • 控制范围（监控过程组）
    • 监督项目和产品的范围状态，管理范围基准变更的过程
    • 作用
      • 在整个项目期间保持对范围基准的维护
      • 确保所有变更请求、纠正措施、预防措施都通过实施整体变更控制过程进行处理
    • 工具与技术
      • 偏差分析
        • 用于将基准与实际结果进行比较，以确定偏差是否处于临界值区间内或是否有必须要采取纠正或预防措施
      • 趋势分析
        • 旨在审查项目绩效随时间的变化情况，以判断绩效是正在改善还是正在恶化
      • 确定偏离范围基准的原因和程度，并决定是否需要采取纠正或预防措施，是项目范围控制的重要工作。
    • 范围蔓延
      • 未对时间、成本和资源做相应调整，未经控制的产品或项目范围的扩大
        • 镀金
          • 来自团队内部原因造成的范围蔓延
          • 项目人员为了讨好客户而做的不解决实际问题，没有应用价值的项目活动
        • 范围潜变
          • 来自团队外部原因造成的范围蔓延
          • 指客户不断提出小的，不易察觉的范围改变，如果不加控制，累计起来导致项目严重偏离既定的范围基准，导致项目失控和失败
      • 如果已经出现了范围蔓延，需要停止不良变更，补变更流程，如果变更流程没有获得批准，需要取消不良变更