导图社区 【高项】项目范围管理
项目范围管理学习要点，包含规划范围管理、收集需求、定义范围、创建WBS、确认范围等。
这是一篇关于项目成本管理学习要点，主要包含规划成本管理、估算成本、制定预算、控制成本等。
项目进度管理学习要点，包含规划进度管理、定义活动、排列活动次序、估算活动持续时间等。
社区模板帮助中心，点此进入>>
互联网9大思维
组织架构-单商户商城webAPP 思维导图。
域控上线
python思维导图
css
CSS
计算机操作系统思维导图
计算机组成原理
IMX6UL(A7)
考试学情分析系统
1. 规划范围管理
输入
项目章程
项目管理计划
质量管理计划
项目生命周期描述
开发方法
事业环境因素
组织文化、基础设施、人事管理制度和市场条件
组织过程资产
工具与技术
专家判断
数据分析
会议
输出
范围管理计划
指导如下过程和相关工作
制定范围项目说明书
根据详细项目范围说明书创建WBS
确定如何审批和维护范围基准
正式验收已完成的项目可交付成果
需求管理计划
主要内容包括
如何规划、跟踪和报告各种需求活动
配置管理活动，如启动变更，如何分析影响，如何追溯、跟踪和报告，以及变更审批权限
需求优先级排序过程
测量指标及使用这些指标的理由
反应哪些需求属性将被列入跟踪矩阵
分解步骤
识别和分析可交付成果及相关工作
确定WBS的结构和编排方法
自上而下逐层细化分解
为WBS组成部分制定和分配标识编码
核实可交付成果分解的程度是否恰当
确认范围 关注点
管理层主要罐组项目范围：进度、资金和资源影响
客户主要关注产品范围：可交付成果是否能够完成产品或服务
项目管理人员主要关注项目制约因素：可交付成果是否足够和必须完成，时间、资金和资源是够足够，主要潜在风险和预备解决的方法
项目团队成员主要关注项目范围中自己参与的元素和负责的元素： 自己工作时间是否足够，多项工作是否冲突
确认范围 6问题
可交付成果是否是确定、可确认的
每个可交付成果是否有明确的里程碑， 里程碑是否有明确的、可辨别的时间，如客户的书面认可
是否有明确的质量标准
审核和承诺是否有清晰表达
项目范围是否覆盖了需要完成的产品或服务的所有活动， 有没有遗漏或错误
项目范围的风险是否太高
确认范围的步骤
确定需要进行范围确认的时间
识别范围确认需要哪些投入
确定范围正式被接受的标准和要素
确认范围确认会议的组织步骤
组织范围确认会议
定义 作用
定义: 监督项目和产品的范围状态，管理范围基准的变更
作用: 在整个项目期间保持对范围基准的维护
定义: 正式验收已完成的项目可交付成果
作用: 1）使验收过程具有客观性 2）通过确认每个可交付成果来提高最终产品、服务或成果获得验收的可能性
定义: 将项目可交付成果和项目工作分解为较小的、更易于管理的组件
作用: 为所要交付的内容提供架构
定义: 制定项目和产品详细描述
作用: 描述产品、服务或成果的边界和验收标准
定义: 为了实现项目目标而确定，记录并管理干系人的需要和需求
作用: 为定义产品范围和项目范围奠定基础
定义: 为了记录如何定义、确认和控制项目范围及产品范围，创建范围管理计划的过程
作用: 在整个项目期间对如何管理范围提供指南和方向
项目范围管理
6. 控制范围
变更管理计划
配置管理计划
范围基准
绩效测量基准
项目文件
需求文件
需求跟踪矩阵
经验教训登记册
工作绩效数据
资源可用情况
进度和成本数据
挣值报告
燃烧图
燃尽图
偏差分析
基准与实际比较，采取纠正或预防措施
趋势分析
绩效随时间的变化，判断绩效是改善或恶化
工作绩效信息
变更请求
项目管理计划（更新）
进度基准
成本基准
项目文件（更新）
增加或修改需求
随需求文件更新
更新经验教训登记册，以记录控制范围的有效技术，以及造成偏差的原因和选择的纠正措施
5. 确认范围
质量报告
核实的可交付成果
已完成并被控制质量过程检查为正确的可交付成果
检查
开展测量、审查与确认的活动，判断符合验收标准
也称审查、产品审查和巡检
决策
投票
验收的可交付成果
符合验收标准的可交付成果应该由客户或发起人正式签字批准
预防措施
纠正措施
缺陷补救
项目文件(更新)
记录实际的验收结果，更新需求文件
根据验收结果更新跟踪矩阵，包括所采取的验收方法及其使用结果
更新经验教训登记册，以记录所遇到的挑战、本应如何避免改挑战的方法，以及良好的可交付成果验收的方法
4. 创建WBS
项目范围说明书
组织的标准政策、流程和程序
人事管理制度
组织对沟通的要求
正式的知识分享和信息分享程序
分解
分解活动
分解为工作包开展如下活动
WBS结构
以项目生命周期的各阶段作为分解的第二层，把产品和项目可交付成果放在第三层
以主要可交付成果作为分解的第二层
纳入由项目团队以外的组织开发的各种较低层次组建（如外包工作）。随后，作为外包工作的一部分，卖方须制定相应的合同WBS
注意事项
WBS必须是面向可交付成果的【工作可能重复，如软件测试】
WBS必须符合项目的范围【100%原则】
WBS的底层应该支持计划和控制
WBS中的元素必须有人负责，而且只有一个人负责
WBS应该控制在4~6层【一个元素分为4~7个新元素；避免交叉从属】
WBS应包括项目管理工作（因为管理是项目具体工作的一部分），也要包括分包出去的工作
WBS编制需要所有（主要）项目干系人的参与
WBS并非是一成不变的
WBS
WBS字典
内容一般包括
账户编码标识
工作描述
假设条件和制约因素
负责的组织
进度里程碑
相关的进度活动
所需资源
成本估算
质量要求
验收标准
技术参考文献
协议信息
工作包【账户编码】
规划包【低于控制账户高于工作包的工作分解结构组件】
假设日志
3. 定义范围
高层级描述、产品特征和审批要求
风险登记册
备选方案分析
多标准决策分析
人际关系与团队技能
引导
产品分析
产品分解、需求分析、系统分析、系统工程、价值分析、价值工程
详细的项目范围说明书包括内容
产品范围描述
可交付成果
项目的除外责任【识别配出项目之外的内容】
干系人登记册
2. 收集需求
立项管理文件
干系人参与计划
协议
数据收集
头脑风暴
访谈 与干系人，“一对一”
焦点小组 干系人+主题专家
问卷调查
标杆对照
独裁型决策制定
数据表现
亲和图 大量创意 分组 审查分析
思维导图
名义小组技术
观察和交谈
系统交互图
原型法
需求类别一般包括
业务需求【整个组织的高层级需要】
干系人需求【干系人需要】
解决方案的需求
为满足业务需求和干系人需求，产品、服务或成果必须具备的特性、功能和特征【功能需求；非功能需求】
过渡和就绪需求【如数据转换和培训需求】
项目需求【项目需要满足的行动、过程或其他条件】【里程碑日期、合同责任、制约因素等】
质量需求【用于确认项目可交付成果的成功完成或其他项目需求的视线的任何条件或标准，如测试、认证、确认等】
内容包括
业务需要、机会、目的和目标
项目目标
项目范围和WBS可交付成果
产品设计
产品开发
测试策略和测试场景
高层级需求到详细需求
裁剪考虑因素
知识和管理需求
确认和控制
需求的稳定性
治理
