项目范围管理
项目范围管理包括确保项目做且只做所需的全部工作，以成功完成项目。
- 产品范围：指某项产品、服务或成果所具有的特征和功能。
- 项目范围：包括产品范围，是为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。
1 规划范围管理
规划范围管理是为了记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程。本过程的主要作用是在整个项目期间对如何管理范围提供指南和方向。
1.1 输入和依据
- 项目章程
- 项目管理计划
- 质量管理计划：在项目中实施组织的质量政策、方法和标准的方式会影响管理项目和产品范围的方式。
- 项目生命周期描述：定义了项目从开始到完成所经历的一系列阶段。
- 开发方法：开发方法定义了项目是采用预测型、适应型还是混合型开发方法。
- 事业环境因素
- 组织过程资产
1.2 输出
- 范围管理计划
1.制定项目范围说明书
2.根据详细项目范围说明书创建WBS
3.确定如何审批和维护范围基准
4.正式验收已完成的项目可交付成果 - 需求管理计划
1.如何规划、跟踪和报告，以及变更审批权限
2.配置管理活动，例如，如何启动变更，如何分析其影响，如何进行追溯、跟踪和报告，以及变更审批权限
3.需求优先级排序过程
4.测试指标及使用这些指标的理由
5.反映哪些需求属性将被敖跟踪矩阵等
2 收集需求
收集需求是为实现目标而确定，记录并管理干系人的需要和需求的过程。本过程的主要作用是为定义产品范围和项目范围奠定基础。
2.1 输入和依据
- 立项管理文件
- 项目建议书
- 可行性分析报告
- 项目评估报告
- 项目章程
- 项目管理计划
- 范围管理计划：包含如何定义和制定项目范围的信息
- 需求管理计划：包含如何收集、分析和记录项目需求的信息
- 干系人参与计划：从该计划中了解干系人的沟通需求和参与程序 ，以便评估并适应干系人对需求活动的参与程度。
- 项目文件
- 假设日志
- 干系人登记册
- 经验教训登记册
- 协议
- 事业环境因素
- 组织过程资产
数据收集
- 头脑风暴：是一种用来产生和收集对项目与产品需求的多种创意的技术
- 访谈：是通过与干系人直接交谈，来获取 信息的正式或非正式的方法。访谈经常是一个访谈者和一个被访者之间的“一对一”谈话，但也可包括多个访谈者或多个被访谈者。
- 焦点小组：是如集预定的干系人和主题专家，了解他们对所讨论的产品、服务或成果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论。
- 问卷调查：是指设计一系列书面问题，向众多受访者快速收集信息。
- 标杆对照：将实际或计划的产品、过程和实践，与其他可比组织的实践进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。
决策
- 投票:是一种为达成某种期望结果，而对未来多个行动方案进行评估的决策技术和过程。
- 独裁型决策制定：采用这种方法，将由一个人负责为整个集体制定决策。
- 多标准决策分析：该技术借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，以对众多创意进行评估和排序。
数据表现
- 亲和图
- 思维导图
人际关系与团队技能
- 名义小组技术：是用于促进头脑风暴的一种技术，通过投票排列最有用的创意，以便进一步开展头脑风暴或优先排序。
1、向集体提出一个问题或难题，每个人在沉思后写出自己的想法
2、主持人在活动挂图止记录所有人的想法
3、集体讨论各个想法，直到全体成员达成一个明确的共识
4、个人私下投票决出各种想法的优先排序，通常采用5分制，1分最低，5分最高。 - 观察和交谈：是指直接察看个人在各自的环境中如何 执行工作（或任务）和实施流程。
- 引导：引导与主题研讨会结合使用，把主要干系人如今在一起定义产品需求。
系统交互图
原型法
原型法是指在实际制造预期产品之前，先造出该产品的模型，并据此征求对需求的早期 反馈。
2.2 输出
- 需求文件：需求文件描述各种单一需求将如何满足项目相关的业务需求。
- 业务需求
- 干系人需求
- 解决方案需求
- 过渡和就绪需求
- 项目需求
- 质量需求
- 需求跟踪矩阵：需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。
| 需求跟踪矩阵 | ||||||||
| 项目名称： | ||||||||
| 成本中心： | ||||||||
| 项目描述： | ||||||||
| 标识 | 关联标识 | 需求描述 | 业务需求、机会、目的和目标 | 项目目标 | WBS可交付成果 | 产品设计 | 产品开发 | 测试案例 |
| 001 | 1.0 | |||||||
| 1.1 | ||||||||
| 1.2 | ||||||||
| 1.2.1 | ||||||||
| 002 | 2.0 | |||||||
| 2.1 | ||||||||
| 2.1.1 | ||||||||
| 003 | 3.0 | |||||||
| 3.1 | ||||||||
| 3.2 | ||||||||
| 004 | 4.0 | |||||||
| 005 | 5.0 | |||||||
3 定义范围
定义范围是制定项目和产品详细描述的过程。本过程的主要作用是描述产品、服务或成果的边界和验收标准。
3.1 输入和依据
- 项目章程
- 项目管理计划
- 项目文件
- 假设日志
- 需求文件
- 风险登记册
- 事业环境因素
- 组织过程资产
3.2 输出
- 项目范围说明书：项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。
- 产品范围描述：逐步细化在项目章程和需求文件中所述的产品、服或成果特征。
- 可交付成果：为完成某一过程、阶段或项目而必须产出的任何独特并可核实的产品、成果或服务能力，可交付成果也包括各种辅助成果，如项目管理报告和文件。
- 验收标准：可交付成果通过验收前必须满足的一系列条件。
- 项目除外责任：识别排除在项目之外的内容。
- 项目文件（更新）
- 假设日志
- 需求文件
- 需求跟踪矩阵
- 干系人登记册
4 创建WBS
创建工作分解结构（WBS)是把项目可交付成果和项目工作分解成较小、更易于管理的组件的过程。本过程的主要作用是为所要交付的内容提供架构。
4.1 输入
- 项目管理计划
- 项目文件
- 需求文件
- 项目范围说明书
- 事业环境因素
- 组织过程资产
分解
分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术。
创建WBS常用方法包括自上而下的方法、使用组织特定的指南和使用WBS模板。
分解活动
要把整个项目工作分解 为工作包，通常需要开展如下活动：
- 识别和分析可交付成果及相关工作
- 确定WBS的结构和编排方法
- 自上而下逐层细化分解
- 为WBS组成部分制定和分配标识编码
- 核实可交付成果分解的程度是否恰当
WBS结构
- 以项目生命周期的各阶段作为分解的第二层，把产品和项目可交付成果放在第三层
- 以主要可交付成果作为分解的第二层
- 纳入由项目团队以外的组织开发的各种较低层次组件
注意事项
- WBS必须是面向可交付成果的：项目的目标是提供产品或服务，WBS中的各项工作是为提供可交付的成果服务的。
- WBS必须符合项目的范围：WBS必须包括也仅包括为了完成项目的可交付成果的活动。
- WBS的底层应该支持计划和控制：WBS是项目管理计划和项目范围之间的桥梁，WBS的底层不但要支持项目管理计划，而且要让管理层能够监视和控制 项目的进度和预算。
- WBS中的元素必须有人负责，而且只有一个人负责：如果存在没有人负责的内容，那么WBS发布后，项目团队成员将很少能够意识到自己和其中内容上的联系。
- WBS应控制在4~6层：如果项目规模比较大，以至于WBS要超过6层，此时，可以使用项目分解结构将大项目分解成子项目，然后针对子项目来做WBS。
- WBS应包括项目管理工作（因为管理是项目具体工作的一部分），也要包括分包出去的工作。
- WBS的编制需要所有（主要）项目干系人的参与：各项目干系人在自己的立场上，对同一个项目可能编制同差别较大的WBS。
- WBS并非一成不变的：在完成了WBS之后的工作中，仍然有可能需要对WBS进行修改。
4.2 输出
- 范围基准：范围基准是经批准的范围说明书、WBS和相应的WBS词典，只有通过正式的变更控制程序才能进行变更，它被用作比较的基础。
- 项目范围说明书
- WBS
- 工作包：WBS的最低层是速腾独特标识的工作包。
- 规划包：规划包是一种低于控制账户而高于工作包的工作分解结构组件，工作内容已知，但详细的进度活动未知，一个控制账户可以包含一个或多个规划包。
- WBS字典：WBS字典是针对WBS中的每个组件，详细描述可交付成果、活动和进度的信息文件。一般包括：账户编码标识、工作描述、假设条件和制约因素、负责的组织、进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献、协议信息等。
- 项目文件（更新）
5 确认范围
项目范围是正式验收已完成的 项目可交付成果的过程。本过程的主要作用：
1.使验收过程具有客观性
2.通过确认每个可交付成果来提高最终产品、服务或成果获得验收的可能性。
确认范围的步骤
1.确定需要进行范围确认的时间
2.识别范围确认需要哪些投入
3.确定范围正式被接受的标准和要素
4.确定范围确认会议的组织步骤
5.组织范围确认会议
需要检查的问题
1.可交付成果是否是确定的、可确认的。
2.每个可交付成果是否有明确的里程碑，里程碑是否有明确的、可辨别的事件，例如：客户的书面认可等。
3.是否有明确的质量标准：可交付成果的交付不但要有明确的标准标志，而且要有是否按照要求完成的标准，可交付成果和其标准之间是否有明确联系
4.审核和承诺是否有清晰的表达：项目发起人必须 正式同意项目的边界，项目完成的产口或服务，以.及项目相关的可交付成果。
5.项目范围是否覆盖了需要完成的产品或服务的所有活动，有没有遗漏或错误。
6.项目范围的风险是否太高：管理层是否能够降低风险发生时对项目的影响。
干系人关注点的不同
1.管理层主要关注项目范围：是指范围对项目的进度、资金和资源的影响，这些因素是否超过了组织的承受范围，是否在投入产出上具有合理性。
2.客户主要关注产品范围：关心项目的可交付成果是否足够完成产品或服务。
3.项目管理人员主要关注项目制约因素：关心项目可交付成果是否足够和必须 完成，时间、资金和资源是否足够，主要的潜在风险和预备解决的方法
4.项目团队成员主要关注项目范围中自己参与的元素和负责的元素：通过定义范围中的时间检查自己的工作时间是否足够，自己在项目范围中是否有多项工作，而这些工作是否有冲突的地方。
5.1 输入
- 项目管理计划
- 范围管理计划
- 需求管理计划
- 范围基准
- 项目文件
- 需求文件
- 需求跟踪矩阵
- 质量报告
- 经验教训登记册
- 工作绩效数据
- 核实的可交付成果
5.2 输出
- 验收的可交付成果
- 变更请求
- 工作绩效信息
- 项目文件（更新）
6 控制范围
控制范围监督项目和产品的范围状态，管理范围的基准变更的过程。本过程的主要作用是在整个项目期间保持对范围基准的维护。
6.1 输入
- 项目管理计划
- 范围管理计划：记录了如何 控制项目和产品范围
- 需求管理计划：记录了如何 管理项目需求
- 变更管理计划：定义了管理项目变更 的过程
- 配置管理计划：定义了哪些是配置项，哪些配置项需要正式变更控制，以及针对这些配置项的变更控制过程
- 范围基准：用范围基与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施
- 绩效测量基准：使用挣值分析时，将绩效测量基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施
- 项目文件
- 需求文件：用于发现任何对商定的项目或产品范围的偏离
- 需求跟踪矩阵：有助于探查任何变更或对范围基准的任何偏离对项目目标的影响，它还可以提供受控需求的状态
- 经验教训登记册：项目早期的经验教训可以运用到后期阶段，以改进范围控制
- 工作绩效数据
- 组织过程资产
数据分析
偏差分析
趋势分析
6.2 输出
- 工作绩效信息
- 变更请求
- 项目管理计划（更新）
- 范围管理计划：更新范围管理计划，以反映范围管理方式的变更
- 范围基准：在针对范围、范围说明书、WBS或WBS字典的变更获得批准后，需要对范围基准做出相应的变更。
- 进度基准：在针对范围、资源或进度估算的变更获得批准后，需要对进度基准做出相应的变更。
- 成本基准：在针对范围、资源或成本估算的变更获得批准后，需要对成本基准做出相应的变更。
- 绩效测量基准：在针对范围、进度绩效或成本估算的变更获得批准后，需要对绩效测量基准做出相应的变更。
- 项目文件（更新）
- 需求文件
- 需求跟踪矩阵
- 经验教训登记册
进度网络图
双代号网络图：
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
