产品范围:完成产品需求,需求是根据特定协议或其他强制性规范,产品、服务或成果必须具备的条件和能力
项目范围:包括产品范围,完成可交付成果
敏捷:
过程:
1. 规划范围管理: 为了记录如何定义、确认和控制项目范围和产品范围,为整个项目期间如何管理范围提供指南和方向
输入:项目章程、项目管理计划、质量管理计划
质量管理计划中的质量政策、方法和标准会影响管理项目和产品范围的方式
工具:备选方案分析(评估、收集需求,确认范围和控制范围的方法)
输出:范围管理计划、需求管理计划
范围管理计划作用:
1. 制定项目范围说明书;
2. 根据详细的项目范围说明书创建WBS;
3. 确定如何审批和维护范围基准;
4. 正式验收已完成的可交付成果
2. 收集需求:为实现项目目的,确定、收集和管理干系人需求和期望,为定义产品范围和项目范围奠定基础
输入(所有包含有需求的):立项管理文件、项目章程、范围管理计划、需求管理计划、项目管理计划、干系人登记册、经验教训登记册、协议
工具:
数据收集:头脑风暴、焦点小组、访谈(可用于获取机密信息)、问卷调查、标杆对照
数据分析:文件分析
数据表现:
亲和图(对大量创意进行分组,进一步审查)
思维导图:从头脑风暴中获得的创意整合成一张图,反应之间的共性和差异,激发新创意
人际关系和团队技能:
名义小组:头脑风暴的创意,排列最有用的,
观察和交谈
引导:跨职能
投票、独裁型决策、
原型法:先造出产品模型
输出:需求文件、需求跟踪矩阵
3. 定义范围:
制定项目和产品的详细描述,描述产品、服务和成果的边界和验收标准
输入:需求文件,范围管理计划,项目章程,风险登记册(影响项目范围确认的策略,如缩小范围,改变产品范围以规避风险)
工具:备选方案分析、多标准决策、引导、产品分析
输出:项目范围说明书、项目文件更新
项目范围说明书的内容:
1. 产品范围描述
2. 可交付成果
3. 验收标准
4. 除外责任
4. 创建WBS:
将项目可交付成果分解成较小的,更易于管理的工作
全部工作范围的分解;最底层叫做工作包
输入:项目管理计划、需求文件、项目范围说明书
工具:分解
分解步骤:
1. 识别和分析可交付成果
2. 确定WBS结构和编排方法
3. 自上而下逐层细化分解
4. 为WBS组成部分制定和分配标识编码
5. 核实可交付成果的分解程度是否恰当
生命周期作为第二层(包含项目管理)、可交付成果作为第二层(包含项目管理)
8个注意事项:
1. wbs必须是面向可交付成果的;
2. 必须符合项目范围,不能多做也不能少做
3. 底层应该支持计划和控制
4. 每个元素必须有一个人负责
5. 应控制在4-6层,避免交叉从属,一个工作单元只能从属于一个上层单元
6. 必须包含项目管理工作、分包出去的工作
7. 编制需要所有主要干系人参与
8. 并非是一成不变的,完成后,人有可能对其进行修改
9. 8-80小时原则
输出:范围基准、
5. 确认范围:正式验收已完成的可交付成果,阶段性验收;使验收工作客观性,通过确认每个可交付成果来提高最终产品、成果或服务获得验收的可能性
输入:核实的可交付成果、范围管理计划、需求文件、需求跟踪矩阵、质量报告(看质量过程中的问题)、经验教训登记册
确认范围的步骤:
1. 确定需要进行范围确认的时间
2. 识别范围确认需要哪些投入
3. 确定范围正式被接受的标准和要素
4. 确定范围确认会议的组织步骤
5. 组织范围确认会议
一般来说,范围确认前需要先做质量控制工作;确认范围关注可交付成果的验收,质量控制关注可交付成果的正确性及是否满足质量要求。
干系人的关注点:
管理层:关注进度、成本和资源的影响,在投入产出比上是否合理
客户:关注可交付成果是否足够完成产品或服务
项目管理人员:关注项目制约因素,关系项目可交付成果,时间、资金、资源的合理,潜在风险,预备解决方案等。
项目团队成员:关注自己参与的元素和负责的元素,时间是否足够,是否并行,是否有冲突
工具:检查、投票
输出:验收的可交付成果、变更请求(验收没通过需要调整的)
6. 控制范围:监督项目和产品的范围状态,管理范围基准的变更,在整个项目期间保持对范围基准维护。
范围蔓延:未经控制的产品或项目范围的扩大
输入:变更管理计划、配置管理计划、范围基准、需求文件、项目范围说明书、绩效数据
工具:偏差分析、趋势分析(审查项目绩效随时间的变化,判断绩效在改善还是恶化)
输出:绩效信息、变更请求