5项目管理--项目范围管理

        项目范围管理包括确保项目做且只做所需的全部工作。

        “范围” = 产品范围 + 项目范围。

        产品范围：产品、服务或成果具有的 特征和功能 。

        项目范围：为了交付具有规定特性和功能的产品，必须 完成的工作 。

        用项目管理计划衡量项目范围的完成情况，用产品需求衡量产品范围的完成情况。

5.1 规划范围管理

        范围管理计划无范围 ，只是一个描述如果管理范围的指南。

过程	输入	工具核技术	输出
	项目章程	专家判断	范围管理计划
规划范围管理	项目管理计划	数据分析	需求管理计划
	质量管理计划	备选方案分析
	项目生命周期描述	会议
	开发方法
	事业环境因素
	组织过程资产

5.1.1 输入

        项目章程：项目章程记录项目目的、项目概述、假设条件、制约因素，以及项目意图实现的高层级需求。

5.1.2 工具和技术

        理解为主

5.1.3 输出

        1.范围管理计划：描述如何定义、制定、监督、控制和确认 项目范围 。

     

        2. 需求管理计划：描述如何分析、记录和管理 项目和产品需求 。

        注意：

        范围管理计划无范围，范围是记录在范围基准中的；

        需求管理计划无需求，需求是记录在需求文件中的。

5.2 收集需求

        为实现目标而确定、记录并管理相关方的需要和需求的过程。

        需求是指根据 特定协议 或其他 强制性规范 ，产品、服务或成果必须具备的 条件或能力。

过程	输入	工具和技术	输出
收集需求	项目童程	专栄判断	霸求文样
	项目管理计划	敬据收集	寄求噩踪矩阵
	范围管理计剣
	審木管理计划	访谈
	相关方參与计划	榇点小组
	项目文件	inlftag
	惬•没日志	标杆对明
	绞验數训瓮•记册	勞据分析
	相关方登记册	文件分析
	商业文件	决並
	商业论if	投票
	协议	独裁型决笫
	归业界堆因素	多标准快策分析
	组织il程資产	数推表现
		亲和困
		思雄导图
		人际关系与团队技说
		名义小组
		观察/交谈
		引导
		系统交互图
		原型法

5.2.1 输入

        项目章程： 项目章程记录了项目概述以及将用于制定详细需求的 高层级需求 。

        相关方登记册： 相关方登记册用于了解哪些相关方能够提供需求方面的信息，及记录相关方对项目的需求和期望。

        商业论证：描述了为满足业务需要而应该达到的必要、期望及可选标准。

        协议： 协议会包含项目和产品需求。

5.2.2 工具和技术

分类	名称		关键词
数据收集	头脑风暴		大量创意、各种想法、畅所欲言
	访谈		直接交谈、预设和即兴问题、一对一、多对多、获取机密信息
	焦点小组		同一领域（同职能）、主题专家（SME）
	问卷调查		受众多样化、需快速完成、地理位置分散、适合开展统计分析
	标杆对照		识别最佳实践，形成改进意见。标杆可以是内部或外部、同行业或不同行业的。
数据分析	文件分析		分析现有文件
决策	投票	一致同意	每个人都同意、德尔菲（专家、匿名、多轮、趋同、消除偏见）
		大多数同意	超过 50%、一般把决策小组的人数定为奇数
		相对同意	相对多数，通常候选项超过两个时使用。
	独裁型决策制定		一个人做决策
	多标准决策分析		决策矩阵、多种标准、评估
数据表现	亲和图		分组、进一步审查和分析
	思维导图		整合、反映共性与差异、激发新创意、脑图
人际关系与团队技能	名义小组		促进头脑风暴、投票、优先排序
	观察和交谈		“工作跟随”、难以或不愿清晰说明、挖掘隐藏的需求
	引 导	与主题研讨会结合使用、跨职能、协调相关方差异。
		JAD	软件开发行业、业务主题专家和开发团队集中
		QFD	制造行业、收集客户需要（客户声音）开始、分类和排序
		用户故事	需求研讨会、角色、目标、动机
系统交互图	拓扑图、可视化
原型法	支持渐进明细的理念。例如：故事板，能减轻返工的风险。 步骤（反复循环）： 1.模型创建、2.用户体验、3.反馈收集、4.原型修改（可能需要走变更流程）

5.2.3 输出

        1. 需求文件 ：需求文件描述各种 单一需求 将如何满足与项目相关的 业务需求 。

        2. 需求跟踪矩阵 ：需求跟踪矩阵是 把产品需求从其来源 连接到能满足需求的 可交付成果 的一种表格。把每个 需求与业务目标或项目目标联系起来 ， 有助于确保每个需求都具有商业价值 。有助于 确保需求 文件中被批准的每项需求 在项目结束的时候都能交付 。最后，需求跟踪矩阵还为管理产品范围变更提供了框架。

5.3 定义范围

        定义范围是制定项目和产品详细描述的过程。本过程的主要作用是，描述产品、服务或成果的边界和验收标准。

        需要多次反复开展定义范围过程 ：在迭代型生命周期的项目中，先为整个项目确定一个高层级的愿景，再 一次针对一个迭代期明确详细范围 。

过程	输入	工具和技术	,出
定义范围	项目章程	专家判断	项目范围说明节
	项目管理计划	数据分析	项冃文件更新
	范围管理计划	备选方案分析	假设日志
	项目文件	决策	需求文件
	假设日志	多标准决策分析	需求跟踪矩阵
	需求文件	人际关系与团队技能	相关方資记册
	风险登记册	引导
	事业环境因素	产品分析
	组织过程资产

5.3.1 输入

        项目章程 ：项目章程中包含对项目的高层级描述、产品特征和审批要求。

        需求文件 ：需求文件识别了应纳入范围的需求。

5.3.2 工具和技术

        产品分析：用以把高层级的产品或服务描述转变为有意义的可交付成果。

        包括： 产品分解 ；需求分析；系统分析；系统工程；价值分析；价值工程。

5.3.3 输出

        项目范围说明书：记录了整个范围， 包括项目和产品范围 ；详细描述了项

        目的可交付成果；还 代表项目相关方之间就项目范围所达成的共识 。

        详细的项目范围说明书包括以下内容：

                产品范围描述：细化项目章程和需求文件中的产品、服务或成果的特征。

                可交付成果 ： 可交付成果也包括各种辅助成果，如项目管理报告和文件。

                验收标准 ： 可交付成果通过验收前必须满足的一系列条件。

                项目的除外责任：明确说明哪些内容不属于项目范围，有助于管理相关方的期望及减少范围蔓延。

                说到可交付成果和验收标准，首选范围说明书，次选WBS词典。

5.4 创建 WBS

        把项目可交付成果和项目工作分解成较小、更易于管理的组件的过程。

        WBS 组织并定义了项目的总范围 ，代表着经批准的当前项目范围说明书中

        所规定的工作。 WBS 最低层的组成部分称为工作包 。

        WBS 最低层的组成部分称为工作包， 其中包括计划的工作 。

过程	输入	工具和技术	输出
创建WBS	项目管理计划	专家判断	范围基准
	范围管理计划	分解	项目文件更新
	项目文件	假设日志
	项目范围说明书		需求文件
	一需求文件
	裏业环境因素
	组织过程.资产

5.4.1输入

        项目范围说明书： 描述了需要实施的工作及不包含在项目中的工作。

        需求文件： 需求文件详细描述了各种单一需求如何满足项目的业务需要。

5.4.2工具和技术

        分解：

        可以项目生命周期的各阶段作为分解的第二层；

        可以以主要可交付 成果作为分解的第二层 ；

        作为外包工作的一部分，卖方须制定相应的合同 WBS。

        不同的可交付成果可以分解到不同的层次 。工作分解得越细致，对工作的规划、管理和控制就越有力。但是， 过细的分解会造成管理努力的无效耗费 、 资源使用效率低下、工作实施效率降低，同时造成 WBS 各层级的数据汇总困难。要在未来远期才完成的可交付成果或组件，当前可能无法分解，需要 滚动式规划 。

        几个重要的原则：80小时原则；4~6层原则；100%原则；责任唯一。

5.4.3输出

        

        范围基准：经过批准的范围说明书、WBS 和相应的 WBS 词典。

        WBS中的 控制账户 则是一个管理控制点。 在该控制点上，把范围、预算和进度加以整合，并与挣值相比较，以测量绩效。

        WBS 词典：针对 WBS 中的每个组件，详细描述可交付成果、活动和进度信息的文件。

5.5 确认范围

        确认范围是正式验收已完成的项目可交付成果的过程。本过程的主要作用是，使验收过程具有客观性；同时 通过确认每个可交付成果，来提高最终产品、服务或成果获得验收的可能性 。

        确认范围过关注可交付成果的验收，而控制质量关注可交付成果的正确性及是否满足质量要求。控制质量过程通常先于确认范围过程，但二者也可同时 进行。

过程	输入	工具和技术	输出
确认范围	项日管理计划	捡査	验收的戚交付成果
	范用管理计划	决策	工作绩效信息
	需求管理计划	投票	变史谙求
	范围暴准		项目文件更新
	项目文件		経验教训告记册
	经验教训登记册		需求文件
	质址报告		需求跟踪矩阵
	需求丈件
	需求跟踪矩阵
	核实的可交付成果
	工作绩效数据

5.5.1输入

        核实的可交付成果： 核实的可交付成果是指已经完成，并被控制质量过程检查为正确的可交付成果。

5.5.2工具和技术

        检查：开展测量、审查与确认等活动，来判断工作和可交付成果是否 符合 需求 和产品 验收标准 。

5.5.3输出

        验收的可交付成果 ：符合验收标准的可交付成果应该 由客户或发起人正式签字批准 。

        变更请求： 未通过验收则

        1.记录原因。

        2.走变更流程，开展缺陷补救。

5.6 控制范围

        控制范围是监督项目和产品的范围状态， 管理范围基准变更 的过程。本过程的主要作用是，在整个项目期间保持对范围基准的维护。

        未经控制的产品或项目范围的扩大（未对时间、成本和资源做相应调整） 被称为 范围蔓延 。

过程	输入	工具和技术	输出
控制范用	项目管理计划	数据分析	工作绩效信息
	范围管理计划	偏差分析	变更请求
	需求管理计划	趋势分析	项目管理计划更新
	变史管理计划		范围管理计划
	配置管理计划		范困基准
	范围基准		进度基准
	绩效測缺基准		成本基准
	项目文件		绩效测量基准
	经段教训登记册		项目文件更新
	需求文件		经验教训登记册
	需求跟踪矩阵		需求文件
	工作绩效数据		需求跟踪矩阵
	组织过程资产

5.6.1输入

5.6.2工具和技术

        偏差分析：用于将基准与实际结果进行比较，以 确定偏差是否处于 临界值 区间内 或 是否有必要采取纠正或预防措施 。

        趋势分析：审查项目绩效随时间的变化情况，以 判断绩效是正在改善还是正在恶化 。

5.6.3输出

        理解为主