9. 项目范围管理
1.产品范围和项目范围:
产品范围的完成情况是根据产品需求来衡量的
项目范围的完成情况是根据项目管理计划来衡量的
2.范围管理的新趋势和新实践:注重与商业分析师一起合作
商业分析师的职责还应包括需求管理相关的活动项目经理则负责确保这些活动列入项目管理计划,并且在预算内按时完成,同时能够创造价值。
3.项目范围管理六大过程:
①规划范围管理:为了记录如何定义、确认和控制项目范围及产品范围,创建范围管理计划。
②收集需求:为了实现项目目标,确定、记录并管理干系人的需要和需求。
③定义范围:制定项目和产品详细描述。
④创建WBS:将项目可交付成果和项目工作分解为较小的、更易于管理的组件。
⑤确认范围:正式验收已完成的项目可交付成果。
⑥控制范围:监督项目和产品的范围状态,管理范围基准的变更。在项目实际进展中,以上各过程会相互交叠和相互作用。
过程 | 输入 | 工具和技术 | 输出 |
规划项目范围管理 | 项目章程、项目管理计划、事业环境因素、组织过程资产 | 专家判断、数据分析、会议 | 范围管理计划 |
收集需求 | 立项管理文件、项目章程、项目管理计划、项目文件、协议、事业环境因素、组织过程资产 | 专家判断、数据收集、数据分析、决策、数据表现、人际关系与团队技能、系统交互图、原型法 | 需求文件 |
定义范围 | 项目章程、项目管理计划、项目文件、事业环境因素、组织过程资产 | 专家判断、数据分析、决策、人际关系与团队技能、产品分析 | 项目范围说明书 |
创建WBS | 项目管理计划、项目文件、事业环境因素、组织过程资产 | 专家判断、分解 | 范围基准 |
确认范围 | 项目管理计划、项目文件、工作绩效数据、核实的可交付成果 | 检查、决策 | 验收的可交付成果、变更请求、工作绩效信息项目文件(更新) |
控制范围 | 项目管理计划、项目文件、工 | 数据分析 | 工作绩效信息 |
4.裁剪范围管理过程的因素:知识和需求管理、确认和控制、开发方法、需求的稳定性、治理。
5.敏捷与适应方法:对于需求不断变化、风险大或不确定性高的项目,在项目开始时通常无法明确项目的范围,而需要在项目期间逐渐明确。敏捷或适应型方法特意在项目早期缩短定义和协商范围的时间,为后续细化范围、明确范围争取更多的时间。
采用敏捷或适应型生命周期,旨在应对大量变更,需要干系人持续参与项目。
采用多次迭代,重复开展三个过程:①收集需求;②定义范围;③创建WBS。
发起人和客户代表应该持续参与项目,重复开展两个过程:①确认范围;②控制范围。
6.规划范围管理:是为了记录如何定义、确认和控制项目范围及产品范围,而创建范围管理计划的过程。
作用:是在整个项目期间对如何管理范围提供指南和方向。
本过程仅开展一次或仅在项目的预定义点开展。
7.范围管理计划是项目管理计划的组成部分,描述将如何定义、制定、监督、控制和确认项目范围。可以是正式或非正式的,非常详细或高度概括的。
8.需求管理计划是项目管理计划的组成部分,描述如何分析、记录和管理需求。需求管理计划的主要内容包括:
①如何规划、跟踪和报告各种需求活动;
②配置管理活动,例如,如何启动变更,如何分析其影响,如何进行追溯、跟踪和报告,以及变更审批权限;
③需求优先级排序过程;
④测量指标及使用这些指标的理由;
⑤反映哪些需求属性将被列入跟踪矩阵等。
9.收集需求:是为实现目标而确定,记录并管理干系人的需要和需求的过程。作用:是为定义产品范围和项目范围奠定基础。
本过程仅开展一次或仅在项目的预定义点开展。
10.让干系人积极参与需求的探索和分解工作(分解成项目和产品需求),并仔细确定、记录和管理对产品、服务或成果的需求,能直接促进项目成功。
需求是指根据特定协议或其他强制性规范,产品、服务或成果必须具备的条件或能力。它包括发起人、客户和其他干系人的已量化且书面记录的需要和期望。
需求将作为后续工作分解结构(WBS)的基础,也将作为成本、进度、质量和采购规划的基础。
11.数据收集过程的数据收集技术:
①头脑风暴;②访谈;③焦点小组;④问卷调查;⑤标杆对照
12. 数据分析技术:文件分析,审核和评估任何相关的文件信息,通过分析现有文件,识别与需求相关的信息获取需求
13. 决策:①投票;②独裁型决策制定;③多标准决策分析(决策矩阵)
14. 人际关系与团队技能:①名义小组技术(结构化头脑风暴);②观察和交谈(适用于产品使用者难以或不情愿清晰说明他们的需求);③引导(与主题研讨会结合使用,召集主要干系人一起定义产品需求,能快速定义跨职能需求并协调干系人的需求差异,更早发现并解决问题)
15. 系统交互图:对产品范围的可视化描绘
16. 原型法:在实际制造预期产品之前,先造出产品的模型
17. 故事板:一种原型技术,使用实体模型来展示网页,屏幕或其他用户界面的导航路径
18. 需求文件:描述各种需求将如何满足项目相关的业务需求。逐步细化。只有明确的(可测量和可测试的)、可跟踪的、完整的、相互协调的,且主要干系人愿意认可的需求,才能作为基准。
19. 需求的类别:
①业务需求:整个组织的高层级需要;②干系人需求:干系人的需要;③解决方案需求:Ⅰ为满足①②,产品、服务或成果必须具备的特性、功能和特征;Ⅱ功能需求/非功能需求
①过渡和就绪需求;②项目需求;③质量需求
20. 需求跟踪矩阵:把产品需求从其来源连接到能满足需求的可交付成果的表格
21. 定义范围:制定项目和产品详细描述的过程
作用:描述产品、服务或成果的边界和验收标准
本过程需要在项目期间多次反复开展。
22. 项目范围说明书:是对项目范围、主要可交付成果、假设条件和制约因素的描述。明确指出哪些工作不属于本项目范围。
23. 详细的项目范围说明书包括内容有:
①产品范围描述:逐步细化在项目章程和需求文件中所述的产品、服务或成果特征。
②可交付成果:为完成某一过程、阶段或项目而必须产出的任何独特并可核实的产品、成果或服务能力,可交付成果也包括各种辅助成果,如项目管理报告和文件。对可交付成果的描述可略可详。
③验收标准:可交付成果通过验收前必须满足的一系列条件。
④项目的除外责任:识别排除在项目之外的内容。明确说明哪些内容不属于项目范围,有助于管理干系人的期望及减少范围蔓延。
24. 创建工作分解结构(WBS):把项目可交付成果和项目工作分解成较小、更容易管理的组件的过程。
作用:为所要交付的内容提供架构
仅开展一次或仅在项目的预定义点开展
25. 分解:一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术。工作包是WBS最低层的工作。
创建WBS的方法:①自上而下(可用于归并较低层次的组件);②使用组织特定的指南;③使用WBS模板
26. WBS结构的形式:①以项目生命周期各阶段作为第二层;②以主要可交付成果作为第二层;③纳入项目团队以外的组织开发的各种较低层次组件(如外包)
27. 分解注意事项:
①WBS必须是面向可交付成果的。
②WBS必须符合项目的范围:WBS必须包括也仅包括为了完成项目的可交付成果的活动。100%原则,在WBS中,所有下一级的元素之和必须100%表上一级的元素。
③WBS的底层应该支持计划和控制。
④WBS中的元素必须有人负责,而且只有一个人负责。
⑤WBS应控制在4~6层。一个工作单元只能从属于某个上层单元,避免交叉从属。
⑥WBS应包括项目管理工作(因为管理是项目具体工作的一部分),也要包括分包出去的工作。
⑦WBS的编制需要所有(主要)项目干系人的参与。
⑧WBS并非是一成不变的。
28. 范围基准:由经过批准的范围说明书、工作分解结构(WBS)和相应的WBS词典组成。只有通过正式的变更控制程序才能变更这个基准。
29. 工作包:WBS的最低层且带有独特标志号
30. 控制账户:一个管理控制点,在该控制点上,把范围、预算和进度加以结合,并与挣值相比测量绩效。每个控制账户可能包括一个或多个工作包,但是一个工作包只能属于一个控制账户。
31. 规划包:一种低于控制账户而高于工作包的工作分解组件,工作内容已知,但详细的进度活动未知,一个控制账户可以包含一个或多个规划包。
32. 确认范围:正式验收已完成的项目可交付成果的过程。
作用:①使验收过程具有客观性;②通过确认每个可交付成果来提高最终产品、服务或成果获得验收的可能性。
在整个项目期定期开展。
33. 范围确认步骤:①确认范围的时间;②识别确认范围需要哪些投入;③确定范围正式被接受的标准和要素;④确定确认范围会议的组织步骤;⑤组织确认范围会议。
34. 质量控制:核实的可交付成果(已完成,如成绩单);范围确认:验收的可交付成果(正式文件,正式验收,如证书)
35. 项目干系人进行范围确认的内容:
①可交付成果是否确实的、可确认的。
②每个交付成果是否有明确的里程碑,里程碑是否有明确的、可辨别的事件。
③是否有明确的质量标准。
④审核或承诺是否有清晰的表达。
⑤项目范围是否覆盖了需要完成的产品或服务的所有活动,有无遗漏或错误。
⑥项目范围的风险是否太高,管理层是否能够降低可预见性的风险对项目的影响。
36. 干系人的关注点:
①管理层:项目范围;②客户:产品范围;③项目管理人员:项目制约因素;④项目团队成员:项目范围中自己参与的元素和负责的元素
37. 可交付成果的时间线
38. 检查:开展测量、审查与确认等活动,来判断工作和可交付成果是否符合需求和产品验收标准
39. 控制范围:监督项目和产品的范围状态,管理范围基准变更的过程。
作用:在整个项目期间保持对范围基准的维护
此过程在整个项目期间开展
40. 范围蔓延:未经控制的产品或项目范围的扩大(未对时间、成本和资源做对应调整)
41. 数据分析技术:偏差分析、趋势分析