7项目范围管理Word文档下载推荐.docx
《7项目范围管理Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《7项目范围管理Word文档下载推荐.docx（13页珍藏版）》请在冰豆网上搜索。
2.编制范围管理计划过程的输出
1）范围管理计划
范围管理计划是项目或项目集管理计划的组成部分，描述了如何定义、制定、监督、控制和确认项目范围，是制定项目管理计划过程和其它范围管理过程的主要依据。
范围管理计划要对将用于下列工作的管理过程做出规定：
（1）制定详细项目范围说明书。
（2）根据详细项目范围说明书创建WBS。
（3）维护和批准工作分解结构（WBS）。
（4）正式验收已完成的项目可交付成果。
（5）处理对详细项目范围说明书或WBS的变更。
该工作与实施整体变更控制过程直接相联。
根据项目需求，范围管理计划可以是正式或非正式的，非常详细或高度概括的。
2）需求管理计划
需求管理计划是项目管理计划的组成部分，描述了如何分析、记录和管理需求，以及阶段与阶段间的关系对管理需求的影响。
需求管理计划的主要内容至少包括：
（1）如何规划、跟踪和报告各种需求活动。
（2）配置管理活动。
（3）需求优先级排序过程。
（4）产品测量指标及使用这些指标的理由。
（5）用来反映哪些需求属性将被列入跟踪矩阵的跟踪结构。
（6）收集需求过程。
7.3范围定义
7.3.1范围定义
定义范围是制定项目和产品详细描述的过程。
本过程主要作用是，明确所收集需求哪些将包含在项目范围内，哪些将排除在项目范围外，从而明确项目、服务或输出的边界。
1.范围定义的内容和作用
由于在收集需求过程中识别出的所有需求未必都包含在项目中，所以定义范围过程就要从需求文件中选取最终的项目需求，然后制定出关于项目及其产品、服务或输出的详细描述。
定义范围最重要的任务就是详细定义项目的范围边界，范围边界是应该做的工作和需要进行的工作分界线。
定义范围可以增加项目时间、成本和资源估算的准确度，定义项目控制的依据，明确相关责任人在项目中的责任，明确项目的范围、合理性和目标，以及主要可交付成果。
2.定义范围的输入、输出
1）定义范围的输入
（1）范围管理计划
（2）项目章程
（3）需求文件
1业务需求
2干系人需求
3解决方案需求
4项目需求
5过渡需求
6与需求相关的假设条件、依赖关系和制约因素。
2）范围定义的输出
（1）项目范围说明书。
（2）项目文件更新。
3.范围定义的工具和技术
1）产品分析
产品分析旨在弄清楚产品范围，把对产品的需求转化成项目的需求。
产品分析技术包括产品分解、系统分析、需求分析、系统工程、价值工程和价值分析等。
2）焦点小组
召集预定的干系人和主题专家，了解他们对所讨论的产品、服务或成果的期望和态度。
由以为受过训练的主持人引导大家进行互动式讨论。
焦点小组会议是一种群体访谈而非一对一访谈。
3）备选方案生成
制定尽可能多的潜在可选方案的技术。
4）引导式研讨会
把主要干系人召集在一起，通过集中讨论来定义产品需求。
快速定义跨职能需求和协调干系人差异的重要技术。
能比单项会议更早发现问题、更快解决问题。
目标化矩阵是进行干系人收集需求调查的有效工具之一。
在软件开发行业，有一种称为“联合应用设计/开发（JAD）”的引导式研讨会。
这种研讨会注重把业务主体专家和开发团队集中在一起，来改进软件开发过程。
在制造行业，则只用“质量功能开展（QFD）”这种引导式讨论会，来帮助确定新产品的关键特征。
7.3.2范围说明书
对项目范围、主要可交付成果、假设条件和制约因素的描述。
详细的范围说明书或引用的文档通常包括以下内容：
1）项目目标
2）产品范围描述
3）项目需求
4）项目边界
5）项目的可交付成果
6）项目的制约因素
7）假设条件
7.3.3创建工作分解结构
创建工作分解结构是把项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程。
工作分解结构（WBS）是项目管理的基础，项目的所有规划和控制工作都必须基于工作分解结构。
WBS是对项目团队为实现项目目标、创建可交付成果而需要实施的全部工作范围的层级分解。
WBS组织并定义了项目的总范围，代表着经批准的当前项目范围说明书中所规定的工作。
1.WBS的作用和意义
1）通过工作结构分解，把项目范围分解开来，使项目相关人员对项目一目了然，能够使项目的概况和组成明确、清晰、透明和具体。
使项目管理者和项目干系人如投资人或客户，都能通过WBS把握项目、了解和控制项目过程。
2）保证了项目结构的系统性和完整性。
3）通过工作结构分解，可以建立完整的项目保证体系，因为这个分解过程将项目的总目标关注的重点，如进度、成本和质量等分解到可控制的各项目单元，便于执行和实现目标要求。
4）项目工作结构分解能够明确项目相关各方的工作界面，便于职责划分和落实。
5）最终工作结构分解，可以直接作为进度计划和控制的工具。
6）为建立项目沟通管理提供依据，便于把握信息重点。
7）是项目各分计划和控制措施制定的基础和主要依据。
8）有助于防止需求和范围蔓延。
2.WBS包含的内容
WBS最底层的工作单元被称为工作包，是我们进行进度安排、成本估算和监控的基础。
工作包对相关活动进行归类。
（1）工作分解结构是用来确定项目范围的，项目的全部工作都必须包含在工作分解结构中，不包含在内的任何工作都不是项目的组成部分。
（2）WBS的编制需要所有项目干系人的参与，需要项目团队成员的参与。
（3）WBS是逐层向下分解的。
工作分解结构最高层的要素总是整个项目或分项目的最终成果。
每下一个层次都是上一层次相应要素的戏份，上一层次是下一层次各要素的和。
工作分解结构中每条分支分解层次不必相等，如某条分支分解到了第四层，而另一条可能只分解到第三层。
工作分解结构应控制在3~6层为宜。
工作分解结构中的各要素应该是相对独立的，要尽量减少相互之间的交叉。
工作分解结构一般用图标形式表达。
比较常见的表现形式有以下两种：
（1）分级的树型结构
类似于组织结构图。
树型结构图的WBS层次清晰，非常直观，结构性强，但是不容易修改，对于大型的、复杂的项目也很难表示出项目的全景。
由于其直观性，一般在一些小的、适中的应用项目中用的较多。
（2）表格形式
类似于分级的图书目录。
该表能够反映出项目所有的工作要素，可是直观性较差。
但在一些大型的、复杂的项目中使用较多，因为有些项目分解后，内容分类较多、容量较大。
用缩进图标的形式表示比较方便，也可装订为手册。
特点如下：
1）每层中的所有要素之和是下一层的工作之和。
2）每个工作要素应该具体指派一个层次，而不应该指派给多个层次。
3）工作分解结构需要有投入工作的范围描述，使项目团队成员对要完成的工作有全面的了解。
工作分解结构中的一些概念。
（1）里程碑
里程碑标志着某个可交付成果或者阶段的正式完成。
“里程碑=具体时间+在这个时间应完成的事件”，里程碑关注事件是否完成。
（2）工作包
工作包是位于工作分解结构每条分支最底层的可交付成果或项目工作组成部分。
作为一种经验法则，8/80（80小时原则）建议工作包的大小应该至少需要8个小时来完成，而总完成时间也不应该大于80小时。
每个工作包分配到一个控制账户，控制账户是一个管理控制点，把范围、预算、实际成本和进度加以整合，与挣值相比较，以测量绩效。
控制账户设置在WBS中选定的管理节点上，每个控制账户可能包括一个或多个工作包，但是一个工作包只能属于一个控制账户。
某个可交付成果，如果有下列特征之一，就可能被当作工作包：
1）规模较小，可以在短时间（80小时）完成。
2）从逻辑上讲，不能再分了。
3）所需资源、时间、成本等已经可以比较准确的估算，已经可以对其进行有效的时间、成本、质量、范围和风险控制。
（3）WBS编码设计
为了简化WBS的信息交流过程，通常利用编码技术对WBS进行信息交换。
编码设计对于WBS是个关键技术。
设计时必须仔细考虑收集到的信息和收集使用的方法，使信息能够通过WBS编码进入到应用记录系统中。
7.3.4创建工作分解结构的工具与技术
1.分解
要把整个项目工作分解为工作包，通常需要开展以下活动：
（1）识别和分析可交付成果及相关工作。
（2）确定WBS的结构和编排方法。
（3）自上而下逐层细化分解。
（4）为WBS组件制定和分配标识编码。
（5）核实可交付成果分解的程度是否恰当。
工作分解的过程，也是项目结构化和层次化的过程，在整个过程中，除了产生最终认定的工作分解结构外，同时可以根据项目的需要进一步确定子项目，通过子项目管理者去做进一步的细化工作。
对于项目一般分3~5层比较合适，如果太多层次，最好将项目进一步划分为不同的子项目，如果太少，对于较大的项目而言不便于控制和管理。
工作结构分解应把握如下原则：
（1）在层次上保持项目的完整性，避免遗漏必要的组成部分。
（2）一个工作单元只能从属于某个上层单元，表面交叉从属。
（3）相同层次的工作单元应用相同性质。
（4）工作单元应能分开不同的责任者和不同的工作内容。
（5）便于项目管理计划和项目控制的需求。
（6）最底层工作应该具有可比性，是可管理的，可定量检查的。
（7）应包括项目管理工作，包括分包出去的工作。
2.专家判断
依据各自信息，把项目可交付成果分解为更小的组成部分，专家判断常用于分析这些信息，以便创建有效的WBS。
7.3.5创建工作分解结构的输入和输出
1.创建工作分解结构的输入
2.创建工作分解结构的输出
1）范围基准
经过批准的范围说明书、工作分解结构和相应的WBS词典组成了范围基准，只有通过正式的变更控制程序才能进行变更这个基准，它被用作比较的基础。
（2）WBS。
（3）WBS词典。
WBS词典是针对每个WBS组件，详细描述可交付成果、活动和进度信息的文件。
2）项目文件更新
7.4项目范围确认
确认范围是正式验收已完成的项目可交付成果的过程，需要审查可交付物和工作成果。
本工程的主要作用是，使验收过程具有客观性：
同时通过验收每个可交付成果，提高最终产品、服务或成果获得验收的可能性。
7.4.1项目范围确认的工作要点
1.制定并执行确认程序
确认范围过程与控制质量过程的不同之处在于，前者关注可交付成果的验收，后者关注可交付成果的正确性及是否满足质量要求，控制质量过程通常先于确认范围过程，但二者也可同时进行。
确认范围的一般步骤：
（1）确定需要进行确认范围的时间。
（2）识别确认范围需要哪些投入。
（3）确定范围正式被接收的标准和要素。
（4）确定确认范围会议的组织步骤。
（5）组织确认范围会议。
2.项目干系人对项目范围的正式承认
项目干系人进行确认范围时，一般需要检查一下6个方面的问题：
（1）可交付成果是否确实的、可确认的或者可核实的。
（2）每个交付成果是否有明确的里程碑，里程碑是否明确可辨别的。
（3）是否有明确的质量标准。
（4）审核或者承诺是否表达清晰。
（5）项目范围是否覆盖了需要完成的产品或服务进行的所有活动。
（6）项目范围的风险发生概率，管理层是否能降低可预见性的风险对项目的影响。
7.4.2项目范围确认所采用的方法
1.检查
指开展测量、审查与确认活动，来判断工作和可交付成果是否符合需求和产品验收标准，是否满足项目干系人的要求和期望。
确认范围完成时，应当对确认中调整的WBS及WBS词典进行更新。
2.群体决策技术
为达成某种期望结果，而对多个未来行动方案进行评估的过程。
本技术用于生成产品需求，并对产品需求进行归类和优先级排序。
达成群体决策的方法有很多，例如：
（1）一致同意。
（2）大多数原则，获得群体中超过50%人员的支持，就能做出决策。
（3）相对多数原则。
（4）独裁。
由某一个人为群体做出决策。
7.4.3项目范围确认的输入、输出
1.项目范围确认的输入
1）项目管理计划
2）需求文件
3）需求跟踪矩阵
是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。
提供了在整个项目生命周期中跟踪需求的一种方法，有助于确保需求文件中被批准的每项需求在项目结束的时候都能交付。
还为管理产品范围变更提供了框架。
需求跟踪矩阵通常包括以下内容，具体取舍根据项目需求：
（1）业务需要、机会、目的和目标。
（2）项目目标。
（3）项目范围/WBS可交付成果。
（4）产品设计。
（5）产品开发
（6）测试策略和测试场景。
（7）高层及需求到详细需求。
应在需求跟踪矩阵中记录每个需求的相关属性。
这些属性有助于明确每个需求的关键信息。
需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态（如活跃中、已取消、已推迟、新增加、一批准、被分配和已完成）和状态日期。
为确保干系人满意，可能需要增加一些补充属性，如稳定性、复杂性和验收标准。
3）
4）核实的可交付成果
5）工作绩效数据
2.项目范围确认的输出
1）验收的可交付成果
符合验收标准的可交付成果应该由客户或发起人以书面的形式正式签字批准，没有被接收的应该记录下来，并记录未被客户接收的原因。
2）变更请求
3）工作绩效信息
4）项目文件更新
7.5项目范围控制
7.5.1项目范围控制设计的主要内容
范围控制是监督项目和产品的范围状态，管理范围基准变更的过程。
主要作用是，在整个项目期间保持对范围基准的维护。
7.5.2项目范围控制与项目整体变更管理的联系
变更是项目干系人常常由于项目环境或者是其他原因要求面对项目的范围计划进行修改，甚至是重新规划，有事变更也叫变化。
项目的范围变更控制、管理是对项目中存在的或潜在的变化采用正确的策略和方法来降低项目的风险。
范围变更管理过程中经常遇到的问题包括：
（1）项目范围蔓延
（2）得不到投资人的批准
（3）项目小组未尽责任
7.5.3项目范围控制与用户需求变更的联系
用户的需求变更必须控制在可控范围之内。
需求基线定义了项目的范围。
用户需求变化导致需求基线变化以及项目范围变化。
每次需求变更并经过需求评审后，都要重新确定新的需求基线。
随着项目进展，需求基线将越定越高，容许的需求变更将越来越少。
需求变更及项目范围变更一定要遵循由变更控制委员会制定的变更控制流程。
7.5.4项目范围控制涉及及所用的工具与技术
进行项目范围控制时，所用的技术和工具是偏差分析。
偏差分析是一种确定实际绩效与基准的差异程度及原因的技术。
7.5.5项目范围控制的输入、输出
1.项目范围控制的输入
2.项目范围控制的输出。
升级会员 