10-项目范围管理(2/10 十大管理)
9.1 管理基础
9.1.1 产品范围和项目范围
- 产品范围:指某项产品、服务或成果所具有的特征和功能。产品范围的完成情况是根据产品需求来衡量的。
- 项目范围:包括产品范围,是为交付具有规定特性与功能的产品服务或成果而必须完成的工作。项目范围的完成情况是根据项目管理计划来衡量的。
项目范围 > 产品范围
9.1.2 管理新实践
需求一直是项目管理的关注重点,需求管理过程结束于需求关闭,即把产品、服务或成果移交给接收方,以便长期策略、健康、实现并维持收益。
商业分析师(BA),该角色的职责还应包括需求管理相关的活动,项目经理则负责确保这些活动列入项目管理计划,并且在预算内按时完成,同时能够创造价值
项目经理与商业分析师之间应该是伙伴式合作关系
9.2 项目范围管理过程
9.2.1 过程概述
过程 | 过程定义 | 主要作用 |
---|---|---|
1.规划范围管理 | 为了记录如何定义、确认和控制项目范围及产品范围,而创建范围管理计划的过程 | 在整个项目期间对如何管理范围提供指南和方向 【仅开展一次或仅在项目的预定义点开展】 |
2.收集需求 | 为实现目标而确定,记录并管理干系人的需要和需求的过程 | 为定义产品范围和项目范围奠定基础 【仅开展一次或仅在项目的预定义点开展】 |
3.定义范围 | 制定项目和产品详细描述的过程 | 描述产品、服务或成果的边界和验收标准 【整个项目期间多次反复开展】 |
4.创建WBS | 把项目可交付成果和项目工作分解成较小、更易于管理的组件的过程 | 为所要交付的内容提供架构 【仅开展一次或仅在项目的预定义点开展】 |
5.确认范围 | 正式验收已完成的项目可交付成果的过程 | ①使验收过程具有客观性 ②通过确认每个可交付成果来提高最终产品、服务或成果获得验收的可能性 【整个项目期间定期开展】 |
6.控制范围 | 监督项目和产品的范围状态,管理范围基准变更的过程 | 在整个项目期间保持对范围基准的维护 【在整个项目期间开展】 |
规划过程组:1,2,3,4
监控过程组:5,6
9.2.2 裁剪考虑因素
裁剪考虑:
- 知识和需求管理
- 确认和控制
- 开发方法
- 需求的稳定性
- 治理
9.2.3 敏捷与适应方法
敏捷或适应型方法特意在项目早期缩短定义和协商范围的时间,为后续细化范围、明确范围争取更多的时间。在许多情况下,不断涌现的需求往往导致真实的业务需求与最初所述的业务需求之间存在差异。因此,敏捷方法有目的地构建和审查原型,并通过多次发布版本来明确需求,范围会在整个项目期间被定义和再定义。
采用敏捷或适应型生命周期,旨在应对大量变更,需要干系人持续参与项目。因此,应将适应型项目的整体范围分解为一系列拟实现的需求和拟执行的工作(有时称为产品未完成项),通过多次迭代来并发可交付成果,并在每次迭代开始时定义和批准详细的范围。在一个迭代开始时,团队将努力确定产品未完成项中,哪些优先级高的未完成项需要在下一次迭代中交付。在每次迭代中,都会重复开展三个过程:①收集需求 ②定义范围 ③创建WBS
在适应型或敏捷型生命周期中,发起人和客户代表应该持续参与项目,并对迭代交付的可交付成果提供反馈意见,确保产品未完成项真实地反映了他们的当前需求。在每次迭代中,都会重复开展两个过程:①确认范围 ②控制范围
9.3 规划范围管理
规划范围管理是为了记录如何定义、确认和控制项目范围及产品范围,而创建范围管理计划的过程。
本过程的主要作用是在整个项目期间对如何管理范围提供指南和方向。
本过程仅开展一次或仅在项目的预定义点开展。
9.3.1 输入
1.项目章程
2.项目管理计划
3.事业环境因素
4.组织过程资产
9.3.2 工具与技术
1.专家判断
2.数据分析(备选方案分析)
3.会议
9.3.3 输出
1.范围管理计划:是项目管理计划的组成部分,描述将如何定义、制定、监督、控制和确认项目范围。包括:
①制定项目范围说明书
②根据详细项目范围说明书创建WBS
③确定如何审批和维护范围基准
④正式验收已完成的项目可交付成果
【可以是正式或非正式的,非常详细或高度概括的】
2.需求管理计划:是项目管理计划的组成部分,描述如何分析、记录和管理需求。包括:
①如何规划、跟踪和报告各种需求活动
②配置管理活动,例如:如何启动变更,如何分析其影响,如何进行追溯、跟踪和报告,以及变更审批权限
③需求优先级排序过程
④测量指标及使用这些指标的理由
⑤反映哪些需求属性将列入跟踪矩阵等
9.4 收集需求
9.4.1 输入
1.立项管理文件
2.项目章程
3.项目管理计划
4.项目文件
5.协议
6.事业环境因素
7.组织过程资产
9.4.2 工具与技术
1.专家判断
2.数据收集(头脑风暴,访谈,焦点小组,问卷调查,标杆对照)
3.数据分析(文件分析)
4.决策(投票,独裁型决策,多标准决策)
5.数据表现(亲和图:对创意分组;思维导图)
6.人际关系与团队技能
- 名义小组技术:用于促进头脑风暴的一种技术,通过投票排列最有用的创意
- 观察和交谈:直接查看个人在各自环境中如何执行工作/任务和实施流程。观察也称为 '工作跟随',来挖掘隐藏的需求
- 引导:引导与主题研讨会结合使用,把主要干系人召集在一起定义产品需求。研讨会可用于快速定义跨职能需求并协调干系人的需求差异
7.系统交互图
8.原型法
9.4.3 输出
1.需求文件
需求文件描述各种单一需求将如何满足项目相关的业务需求。一开始可能只有高层级的需求,然后随着有关需求信息的增加而逐步细化。
只有明确的(可测量和可测试的)、可跟踪的、完整的、相互协调的,且主要干系人愿意认可的需求,才能作为基准
需求文件的格式多种多样,既可以是一份按干系人和优先级分类列出全部需求的简单文件,也可以是一份包括内容提要、细节描述和附件等的详细文件。
- 业务需求
- 干系人需求
- 解决方案需求:功能需求和非功能需求
- 过渡和就绪需求
- 项目需求
- 质量需求
2.需求跟踪矩阵
把产品需求从其来源连接到能满足需求的可交付成果的一种表格。使用需求跟踪矩阵,把每个需求与业务目标或项目目标联系起来,有助于确保每个需求都具有业务价值。需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法,有助于确定需求文件中被批准的每项需求在项目结束的时候都能实现并交付。
跟踪需求的内容包括:
- 业务需要、机会、目的和目标
- 项目目标
- 项目范围和WBS可交付成果
- 产品设计
- 产品开发
- 测试策略和测试场景
- 高层级需求到详细需求等
9.5 定义范围
9.5.1 输入
1.项目章程
2.项目管理计划
3.项目文件
4.事业环境因素
5.组织过程资产
9.5.2 工具与技术
1.专家判断
2.数据分析(备选方案分析)
3.决策(多标准决策分析)
4.人际关系与团队技能(典型示例是引导)
5.产品分析
9.5.3 输出
1.项目范围说明书:是对项目范围、主要可交付成果、假设条件和制约因素的描述
内容有:
- 产品范围描述
- 可交付成果
- 验收标准
- 项目的除外责任
9.6 创建WBS
WBS最低层的组成部分称为工作包
9.6.1 输入
1.项目管理计划
2.项目文件
3.事业环境因素
4.组织过程资产
9.6.2 工具与技术
1.专家判断
2.分解
项目工作分解为工作包,通常需要开展如下活动:
- 识别和分析可交付成果及相关工作
- 确定WBS的结构和编排方法(树形和表格/列表)
- 自上而下逐层细化分解
- 为WBS组成部分制定和分配标识编码
- 核实可交付成果分解的程度是否恰当
WBS注意事项
1)WBS必须是面向可交付成果的
2)WBS必须符合项目的范围,所有下一级的元素之和必须100%代表上一级的元素
3)WBS的低层应该支持计划和控制
4)WBS中的元素必须有人负责,而且只有一个人负责
5)WBS应控制在 4~6 层,一个工作单元只能从属于某个上层单元,避免交叉从属
6)WBS应包括项目管理工作,也要包括分包出去的工作
7)WBS的编制需要所有(主要)项目干系人的参与
8)WBS并非是一成不变的
分接任务的8/80(每天八小时,持续10天)
9.6.3 输出
1.范围基准:是经过批准的范围说明书、WBS和相应的WBS词典。只有通过正式的变更控制程序才能进行变更。范围标准是项目管理计划的组成部分。
1)项目范围说明书
2)WBS:全部工作范围的层级分解
3)工作包:WBS的最低层是带有独特标识号的工作包
4)规划包:规划包是一种低于控制账户而高于工作包的工作分解结构组件,工作内容已知,但详细的进度活动未知,一个控制账户可以包含一个或多个规划包
5)WBS字段:是针对WBS中的每个组件,详细描述可交付成果、活动和进度信息的文件
WBS字典中的内容一般包括:账户编码标识、工作描述、假设条件和制约因素、负责的组织、进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献、协议信息等
2.项目文件
9.7 确认范围
确认范围的步骤包括:
- 确定需要进行范围确认的时间
- 识别范围确认需要哪些投入
- 确定范围正式被接受的标准和要素
- 确定范围确认会议的组织步骤
- 组织范围确认会议
确认范围过程与控制质量过程的不同之处在于:前者关注可交付成果的验收,而后者关注可交付成果的正确性及是否满足质量要求。控制质量过程通常先于确认范围过程,但二者也可同时进行。
干系人关注的的不同:
- 管理层关注项目范围
- 客户关注产品范围
- 项目管理人员主要关注项目制约因素
- 项目团队人员主要关注项目范围中自己参与的元素和负责的元素
9.7.1 输入
1.项目管理计划
2.项目文件
3.工作绩效数据
4.核实的可交付成果
9.7.2 工具与技术
1.检查(开展测量、审查与确认等活动)
2.决策
9.7.3 输出
1.验收的可交付成果
2.变更请求
3.工作绩效信息
4.项目文件
9.8 控制范围
确保所有变更请求、推荐的纠正措施或预防措施都通过实施整体变更控制过程进行处理。在变更实际发生时,也需要采用控制范围过程来管理这些变更。控制范围过程应该与其他项目管理知识领域的控制过程协调开展。未经控制的产品或项目范围的扩大(未对事件、成本和资源做相应调整)被称为范围蔓延。
9.8.1 输入
1.项目管理计划
2.项目文件
3.工作绩效数据
4.组织过程资产
9.8.2 工具与技术
1.数据分析(偏差分析:偏差是否处于临界值区间内,趋势分析:绩效是正在改善还是正在恶化)
9.8.3 输出
1.工作绩效信息
2.变更请求
3.项目管理计划
4.项目文件