第五章 下

项目范围管理过程之三 “定义范围” (规划过程组)p150

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

    本过程的作用:描述产品,服务或成果的边界验收标准

    从需求文件中选取最终的项目需求,然后制定出关于项目及其产品,服务或成果的详细描述(p151)

  • 应根据项目启动过程中记载的主要可交付成果,假设条件和制约因素来编制项目范围说明书。

  • 还需要分析现有风险,假设条件和制约因素的完整性,并做必要的增补或更新。

  • 需要多次反复开展定义范围过程(涉及多个迭代)


定义范围——输入:项目章程 p152

  • 项目章程中包含对项目的高层级描述产品特征审批要求。

定义范围——输入:项目文件 p152

  • 需求文件——识别了应纳入范围的要求。

项目范围管理过程之三 “定义范围” (规划过程组)p150

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

    本过程的作用:描述产品,服务或成果的边界验收标准

    从需求文件中选取最终的项目需求,然后制定出关于项目及其产品,服务或成果的详细描述(p151)

  • 应根据项目启动过程中记载的主要可交付成果,假设条件和制约因素来编制项目范围说明书。

  • 还需要分析现有风险,假设条件和制约因素的完整性,并做必要的增补或更新。

  • 需要多次反复开展定义范围过程(涉及多个迭代)


定义范围——输入:项目章程 p152

  • 项目章程中包含对项目的高层级描述产品特征审批要求。

定义范围——输入:项目文件 p152

  • 需求文件——识别了应纳入范围的要求。

补充示例——以 “主要可交付成果” 作为第二层

image


定义范围——工具与技术:数据分析 p153

  • 可用于本工程的数据分析技术包括:备选方案分析

定义范围——工具与技术:决策 p153

  • 可用于本工程的决策技术包括:多标准决策分析

定义范围——工具与技术:人际关系与团队技术 p153

  • 在研讨会和座谈会中使用引导技能来协调具有不同期望或不同专业知识的关键相关方,使他们就项目可交付成功以及项目和产品边界达成跨职能的共识。

定义范围——工具与技术:产品分析 p153

  • 产品分析——把高层级的产品描述转变为有形的可交付成果。产品分析技术包括产品分解,系统分析,需求分析,系统工程,价值工程,价值分析等。

定义范围——输出:项目范围说明书 P154

  • 项目范围说明书——是对项目范围,主要可交付成功,假设条件和制约因素的描述。记录了整个范围,包括项目和产品范围

  • 项目范围说明书详细描述了项目的可交付成果,还代表项目项目相关方之间就项目范围所达成的共识。

  • 为了便于管理相关方的期望,项目范围说明书可明确指出那些工作不属于本项目范围。

    包含的内容 内容描述
    产品范围描述 逐步细化在项目章程和需求文件中所述的产品,服务或成果的特征
    可交付成果 必须产出的任何独特并核实的产品,成果或服务能力。也包括辅助成果,如项目管理报告和文件
    验收标准 可交付成果通过验收前必须满足的一系列条件
    除外责任 明确说明那些内容不属于项目范围,有助于管理相关方的期望减少范围蔓延

高层级需求,需求,范围(补充)

image)

项目范围管理工程之四 “创建WBS” (规划过程组)p156

  • 创建WBS——把项目可交付成果项目工作分解成较小的,更易于管理的组件的过程。
  • 本工程的作用:对所要交付的内容提供架构
  • WBS(工作分解结构) 组织定义了项目的总范围(项目范围说明书只定义范围,没有组织范围)
  • WBS 最低层的组成部分称为工作包,其中包括计划的工作。、
  • 在 “工作分解结构” 这个词语,“工作” 是指作为活动结果的工作产品或可交付成果,而不是活动本身

创建WBS——工具与技术:分解 p158

  • 分解——把项目范围和项目可交付成果逐步划分为更小,更便于管理的组成部分的技术。

  • 工作包——WBS 最底层的组件,可对其成本持续时间进行估算和管理。

  • 创建WBS,就是要将整个项目工作分解为工作包

    WBS:工作分解结构 Work Breakdown Structure

分解的五个步骤 P158

  1. 识别和分析,可交付成果及相关工作
  2. 确定WBS的结构和编排方法
  3. 自上而下逐层细化分解
  4. 为WBS组件制定和分配标识编码
  5. 核实可交付成果分解的程度是否恰当

WBS的结构可以采用如下形式 P159

  • 项目生命周期的各阶段作为分解的第二层,产品和项目可交付成果放在第三层
  • 主要可交付成果作为分解的第二层
  • 纳入由项目团队以外的组织开发的各种较低层次组件(如外包工作)

image


创建WBS的四个注意 P160

  • 如果采用敏捷方法,可以将长篇故事分解成用户故事
  • 不同的可交付成果可以分解到不同的层次
  • 并不是分解得越细越好。过细的分解会造成管理努力的无效耗费资源使用效率低下,工作实施效率降低,同时造成WBS各层级的数据汇总困难
  • 远期才完成的可交付成果或组件,当前可能无法分解(规划包),需要滚动式规划。

创建WBS的四个主要原则 P161

  1. 无遗漏无多余:100%原则

  2. 工作包80小时:80小时原则

  3. 不宜过细分解:4~6层原则

  4. 有明确责任人:责任明确原则
    image

image


控制账号与工作包 p161

  • 控制账户(CA)——是一个管理控制点(可以与组织的财务程序链接),在该控制点上,把范围,预算,实际成本和进度加以整合,并与挣值相比较,以测量绩效。
  • 绩效测量基准(PMB)——由范围基准,进度基准,成本基准共同构成。
  • 每个控制账号可能包括一个或多个工作包(或规划包),但是一个工作包只能属于一个控制账号。

image


项目范围管理过程之五 "确认范围" (监控过程组)p163

  • 确认范围 —— “客户” 或 “发起人正式验收已完成的项目可交付成果的过程
  • 本过程的作用:通过验收每一个可交付成果,提高最终产品,服务或成果验收的可能性。

确认范围 ——输入:核实的可交付成果 p165

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

确认范围 —— 工具与技术: 检查 p166

  • 检查 (审查,产品审查,巡检)——开展测量,审查与确认等活动,来判断工作和可交付成果是否符合需求和产品验收标准。

确认范围——输出:验收的可交付成果 P166

  • 符合验收标准的可交付成果应该由客户或发起人正式签字批准。
  • 应该从客户或发起人哪里获得正式文件,证明相关方对项目可交付成果的正式验收

确认范围——输出:变更请求 p166

  • 如果未通过验收,处理步骤 (1)记录 (了解)原因 ; (2)走变更流程,进行缺陷补救。

项目范围管理 (补充)

image


项目范围管理过程之六 "控制范围" (监控过程组) p167

  • 控制范围——监督项目和产品范围状态,管理范围基准变更的过程。
  • 本过程的作用:
    • 整个项目期间保持对范围基准的维护
    • 确保所有变更请求,纠正措施,预防措施都通过实施整体变更控制过程进行处理

控制范围——工具与技术 :数据分析 p170

  • 偏差分析——用于将基准实际结果进行比较,以确认偏差是否于临界值区间内或是否有必要采取纠正或预防措施。
  • 趋势分析——旨在审查项目绩效时间的变化情况,以判断绩效是正在改善还是正在恶化。
  • 确认偏差范围基准原因和程度,并决定是否需要采取纠正或预防措施,是项目范围控制的重要工作。

范围蔓延,镀金,范围潜变

  • 范围蔓延——未对时间,成本和资源做相应调整,未经控制的产品或项目范围的扩大。p168
    • ————来自团队内部原因造成的范围蔓延称未“镀金
    • ————来自团队外部原因造成的范围蔓延称为“范围潜变”。
  • 镀金——项目人员为了“讨好”客户而做的不解决实际问题,没有应用价值的项目活动。
  • 范围潜变——范围潜变是指客户不断提出小的,不易察觉的范围改变,如果不加控制,累计起来导致项目严重偏离既定的范围基准,导致项目失控和失败。
  • 如果已经出现了范围蔓延,需要补变更流程,如果变更没有获得批准,需要取消不良变更。
原文地址:https://www.cnblogs.com/quietzpc/p/14598503.html