第7章项目范围管理（2）

软考中项/系统集成项目管理工程师/第7章项目范围管理（2），包含创建工作分解结构、确认范围、范围控制等。

第7章 项目范围管理 （2）

• 实现过程
  • 步骤（四） 创建工作分解结构（WBS） [Work Breakdown Structure]
    • 含义
      • 把项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程
      • 是项目管理的基础，项目的所有规划和控制工作都必须基于工作分解结构
      • 是对项目团队为实现项目目标、创建可交付成果而需要实施的全部工作范围的层级分解。
      • 组织并定义了项目的总范围，代表着经批准的当前项目范围说明书中规定的工作。
      • 是后续管理工作的主要依据，是项目时间、成本、人力等管理工作的基础
    • 作用
      • 对所要交付的内容提供一个结构化的视图
    • 意义
      • （1） 使项目相关人员对项目一目了然
      • （2） 保证了项目结构的系统性和完整性
      • （3） 可以建立完整的项目保证体系
      • （4） 明确项目相关各方的工作界面，便于责任划分和落实
      • （5） 最终WBS，可以直接作为进度计划和控制的工具
      • （6） 为建立项目沟通管理提供依据，便于把握信息重点
      • （7） 是项目各分计划和控制措施制定的基础和主要依据
      • （8） 有助于防止需求和范围蔓延
    • WBS最低层的工作单元被成为工作包，是进行进度安排、成本估算和监控的基础工作包对相关活动进行归类
    • 内容
      • 1. 项目的全部工作都必须包含在WBS中，且不包含在WBS中的任何工作都不是项目的组成部分，都不能做，否则就是“镀金”
        • WBS必须且只能包括100%的工作（百分百规则）
      • 2. WBS的编制需要所有项目干系人的参与，需要项目团队成员的参与
      • 3. WBS是逐层向下分解的。WBS最高层的要素总是整个项目或分项目的最终成果。每下一个层次都是上一层次相应要素的细分，上一层次是下一层次各要素之和。WBS中每条分支分解层次不必相等，一般应控制在3～6层为宜。如果项目较大，要超过6层，可以把大项目分解成子项目，再对子项目做WBS
      • 4. WBS中的各要素应该是相对独立的，要尽量减少相互之间交叉
    • 结构形式
      • （1） 分级的树型结构
        • 优点
          • 层次清晰，非常直观，结构性强，适用于中小项目
        • 缺点
          • 不易修改，对大型复杂项目很难表示项目全景
        • 适用范围
          • 小的、适中的应用项目
      • （2） 表格形式
        • 优点
          • 可反映出项目所有的工作要素，在大型复杂项目中用的较多 [采用缩进图表]
        • 缺点
          • 直观性较差
        • 适用范围
          • 大型复杂项目
        • 特点
          • 每层中的所有要素之和是下一层的工作之和
          • 每个工作要素应该具体指派一个层次，而不应该指派给多个层次
          • WBS需要有投入工作的范围描述，使项目团队成员对要完成的工作有全面的了解
    • 相关概念
      • 里程碑
        • 标志着某个可交付成果或阶段的正式完成
          • 里程碑=具体时间+在这个时间应完成的事件
        • 里程碑和可交付成果紧密联系在一起，但并不是一个概念。里程碑关注事件是否完成。WBS中的任务有明确的开始时间和结束时间，任务的结果可以和预期的结果相比较。
      • 工作包
        • 位于WBS每条分支最低层的可交付成果或项目工作组成部分
        • 由于工作包便于完整地分派给不同的人或组织（每个工作包仅有一个负责人），所以要求明确各工作单元之间的界面。
        • 工作包应该非常具体，以便承担者能明确自己的任务、努力的目标和承担的责任，工作包是基层任务或工作的指派，同时其具有检测和报告工作的作用。
        • 工作包太大，难以达到可管理、可控制的目标；工作包太小，WBS就要消耗项目管理人员和团队成员大量时间和精力
        • 8/80经验规则：建议工作包的大小应该至少需要8个小时来完成，总完成时间也不应该大于80小时
        • 特征
          • 规模较小，可在短时间（80小时）完成
          • 在逻辑上讲，不能再分了
          • 所需资源、时间、成本等已经可以比较准确地估算，已经可以对其进行有效的时间、成本、质量、范围和风险控制
      • 控制账户
        • 在制作分解结构的过程中，把每个工作包分配到一个控制账户，并根据“账户编码”为工作包建立唯一标识，这些标识为进行成本、进度与资源信息的层级汇总提供了层级结构。
        • 是一个管理控制点；在该控制点上，把范围、预算、实际成本和进度加以整合，并与挣值相比较，以测量绩效
        • 控制账户设置在WBS选定的管理节点上，每个控制账户可能包括一个或多个工作包，但是一个工作包只能属于一个控制账户
      • WBS词典
        • 含义
          • 需要生成一些配套的文件，这些文件需要和WBS配合使用
        • 包括
          • WBS组成部分的详细内容、账户编码、工作说明、负责人、进度里程碑清单
          • 合同信息、质量要求、技术文献、计划活动、资源和成本估计
      • WBS编码设计
        • 为了简化WBS的信息交流过程，通常利用编码技术对WBS进行信息交换。
        • 编码设计与结构设计存在对应关系。结构的每一层次代表编码的某一位数，有一个分配给它特定的代码数字。
        • 在WBS编码中，任何等级的一位项目要素，是其余全部次一级项目要素的总和。如第二个数字代表子项目要素。所有子项目的编码第一位数字是相同的，再下一级的工作单元的编码依此类推。
        • 编码设计对WBS来说是个关键技术，进行编码设计时必须仔细考虑收集到的信息和收集所用的方法
    • ITO
      • 输入 Input
        • （1） 项目范围管理计划
        • （2） 项目范围说明书
        • （3） 需求文件
        • （4） 事业环境因素
        • （5） 组织过程资产
      • 工具与技术 Tool&Technology
        • （1） 专家判断
        • （2） 分解
          • 开展的活动 口诀：释放粪便核
            • 1||| 识别和分析可交付成果及相关工作
            • 2||| 确定WBS的结构和编排方法
            • 3||| 自上而下逐层细化分解
            • 4||| 为WBS组件制定和分配标识编码
            • 5||| 核实可交付成果分解的程度是否恰当
          • 7个原则
            • 1||| 在层次上保持项目的完整性，避免遗漏必要的组成部分
            • 2||| 在一个工作单元只能从属于某个上层单元，避免交叉从属
            • 3||| 相同层次的工作单元应用相同性质
            • 4||| 工作单元应能分开不同的责任者和不同的工作内容
            • 5||| 便于项目管理计划和项目控制的需要
            • 6||| 最底层工作应该具有可比性，是可管理的，可定量（非定性）检查的
            • 7||| 应包括项目管理工作，包括分包出去的工作
          • （书本无）3种方法
            • 1||| 使用项目生命周期的阶段作为分解的第一层，而把项目可交付物安排在第二层
            • 2||| 把项目重要的可交付物作为分解的第一层
            • 3||| 把子项目安排在第一层，再分解子项目的WBS
      • Output 输出
        • 1||| 范围基准
          • 内容
            • 1. 项目范围说明书
            • 2. WBS
              • WBS每向下分解一层，代表着对项目工作更详细的定义
              • 把每个工作包分配到一个控制账户，并根据“账户编码”为工作包建立唯一标识，是创建WBS的最后步骤
              • 控制账户设置在WBS中选定的管理节点上
            • 3. WBS词典
              • 内容包括：账户编码标识、工作描述、假设条件和制约因素、负责的组织、进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献、协议信息
          • 只有通过正式的变更控制程序才可对基准进行变更。基准被用作比较的基础。
        • 2||| 项目文件更新
  • 步骤（五） 确认范围 =验收≠验证
    • 含义
      • 正式验收已完成的项目可交付成果的过程
    • 内涵
      • 需要审查可交付物和工作成果，以保证项目中所有工作都能准确地、满意地完成
      • 要贯穿项目的始终
      • 确认范围过程应该以书面文件的形式把它完成情况记录下来
      • 由客户或发起人审查从控制质量过程输出的核实的可交付成果，确认这些可交付成果已经圆满完成并正式通过验收
    • 作用
      • 使验收过程具有客观性，同时通过验收每个可交付成果，提高最终产品、服务或成果获得验收的可能性
    • 对比
      • 确认范围过程
        • 关注可交付成果的验收
      • 控制质量过程
        • 关注可交付成果的正确性及是否满足质量要求
      • 控制质量过程通常先于确认范围过程， 但二者也可同时进行
    • 步骤 口诀：屎投标不足
      • 1||| 确定需要进行确认范围的时间
      • 2||| 识别确认范围需要哪些投入
      • 3||| 确定范围正式被接受的标准和要素
      • 4||| 确定确认范围会议的组织步骤
      • 5||| 组织确认范围会议
    • 工作要点
      • 制定并执行确认程序
      • 项目干系人对项目范围的正式承认
        • 干系人需要检查6方面
          • 1||| 可交付成果是否确实的、可确认的或者说可核实的
          • 2||| 每个交付成果是否有明确的里程碑，里程碑是否明确可辨别的
          • 3||| 是否有明确的质量标准
          • 4||| 审核或承诺是否表达清晰
          • 5||| 项目范围是否覆盖了需要完成的产品或服务进行的所有活动。
          • 6||| 项目范围的风险发生概率，管理层是否能够降低可预见性的风险对项目的影响
    • ITO
      • 输入 Input
        • （1） 项目管理计划
        • （2） 需求文件
        • （3） 需求跟踪矩阵
          • 连接了需求与需求源，用于在整个项目生命周期中对需求进行跟踪。
        • （4） 核实的可交付成果
          • 已经完成，并经质量过程检查为正确的可交付成果。
        • （5） 工作绩效数据
          • 可能包括符合需求的程度、不一致的数量、不一致的严重性或在某时间段内开展确认的次数。
      • 工具与技术 Tool&Technology
        • （1） 检查
          • 开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准，是否满足项目干系人的要求和期望
          • 也称为审查、产品审查、审计和巡检等
          • 确认范围完成时，应当对确认中调整的WBS及WBS词典进行更新
        • （2） 群体决策技术
          • 当由项目团队和其它干系人进行确认时，可以使用群体决策技术来达成结论
      • Output 输出
        • （1） 验收的可交付成果
          • 符合验收标准的可交付成果应该由客户或发起人以书面的形式正式签字批准。
          • 没有被客户接受的交付物也应当记录下来，同时还要记录未被接受的原因。
          • 应该从客户或发起人那里获得正式文件，证明干系人对项目可交付成果的正式验收。这些文件将提交给结束项目或阶段过程。
          • 由于范围确认可以是阶段性的，所以此处所讲的交付物可能是中间交付物。系统集成项目的验收可先分批验收，最后再终验，每一次验收都需要客户的书面确认。
        • （2） 变更请求
        • （3） 工作绩效信息
        • （4） 项目文件更新
          • 确认文件需要客户或发起人以签字或会签的形式进行批准。
    • 补充
      • 范围确认和需求确认一定要分开
        • 需求确认是在项目前期三方通过召开需求评审会的方式讨论形成一个需求说明书，来确认需求
        • 范围确认则是阶段性的验收
  • 步骤（六） 范围控制
    • 含义
      • 监督项目和产品的范围状态，管理范围基准变更的过程
    • 相关名词
      • 范围蔓延
        • 未经控制的产品或项目范围扩大（未对时间、成本和资源做相应的调整）
    • 要点
      • 变更是项目干系人常常由于项目环境或是其他原因要求而对项目的范围计划进行修改，甚至是重新规划，有时变更也叫变化
      • 变更不可避免，因此在每个项目上，都必须以书面形式记录并实施某种形式的变更控制管理
      • 项目的范围变更控制、管理是对项目中存在的或潜在的变化采用正确的策略和方法来降低项目的风险
    • 作用
      • 在整个项目期间保持对范围基准的维护
    • 与项目整体变更管理的联系
      • 范围变更常见问题
        • （1） 项目范围蔓延
          • 项目经理能够意识到大的范围变化，但对小的范围变化不那么细心
        • （2） 得不到投资人的批准
          • 客户通常只能提出范围变化的要求，但却没有批准的权力。
          • 项目经理也没有批准的权力
          • 只有项目投资人（除非该资助人已经授权给了他人）才能批准范围变更
        • （3） 项目小组未尽责任
          • 所有小组成员都必须及时发现项目范围变化并将其报告给项目经理
    • 与用户需求变更的联系
      • 用户的需求变更必须控制在可控范围之内。
      • 需求基线定义了项目的范围。每次需求变更并经过需求评审后，都要重新确定新的需求基线。项目组需要维护需求基线文档，保存好各个版本的需求基线，以备不时之需。随着项目的进展，需求基线将越定越高，容许的需求变更将越来越少。
      • 需求变更及范围变更一定要遵循由变更控制委员会制定的变更控制流程。
    • ITO
      • 输入 Input
        • （1） 项目管理计划
          • 1||| 范围基准
          • 2||| 范围管理计划
          • 3||| 变更管理计划
          • 4||| 配置管理计划
          • 5||| 需求管理计划
        • （2） 需求文件
        • （3） 需求跟踪矩阵
        • （4） 工作绩效数据
        • （5） 组织过程资产
      • 工具与技术 Tool&Technology
        • 偏差分析
          • 是一种确定实际绩效与基准的差异程度及原因的技术。
          • 可利用项目绩效测量结果评估偏离范围基准的程度，确定偏离范围基准的原因和程度，并决定是否需要采取纠正或预防措施，是项目范围控制的重要工作
      • Output 输出
        • （1） 工作绩效信息
        • （2） 变更请求
        • （3） 项目管理计划更新
          • 范围基准更新
          • 其它基准更新
        • （4） 项目文件更新
        • （5） 组织过程资产更新