高项 范围管理论文

六个过程：

1，规划范围管理。编制范围管理计划，书面描述将如何定义、确认和控制项目范围的过程。 

2，收集需求。为实现项目目标而确定、记录并管理干系人的需要和需求的过程。 

3，定义范围。制定项目和产品详细描述的过程。 

4，创建工作分解结构（WBS）。将项目可交付成果和项目工作分解为较小的、更易于管理的组件的过程。 

5，确认范围。正式验收己完成的项目可交付成果的过程。

6，控制范围。监督项目和产品的范围状态，管理范围基准变更的过程。

输入输出和工具：

过程	输入	工具	输出
1、规划范围管理	项目管理计划、 项目章程、 事业环境因素、 组织过程资产	专家判断、 会议	范围管理计划、 需求管理计划
2、收集需求	范围管理计划、 需求管理计划、 干系人管理计划、 项目章程、 干系人登记册	访谈、 焦点小组、 引导式研讨会、 群体创新技术、 群体决策技术、 问卷调查、 观察、 原型法、 标杆对照、 系统交互图、 文件分析。	需求分析、 需求跟踪矩阵
3、定义范围	范围管理计划、 项目章程、 需求文件、 组织过程资产	专家判断、 产品分析、 备选方案生成、 引导式研讨会	项目范围说明书、 项目文件更新
4、创建WBS	范围管理计划、 项目范围说明书、 需求文件、 事业环境因素、 组织过程资产	分解、 专家判断	范围基准、 项目文件更新
5、确定范围	项目管理计划、 需求文件、 需求跟踪矩阵、 核实的可交付成果、 工作绩效数据	检查、 群体决策技术	验收的可交付成果、 变更请求、 工作绩效信息、 项目文件更新
6、控制范围	项目管理计划、 需求文件、 需求跟踪矩阵、 工作绩效数据、 组织过程资产	偏差分析	工作绩效信息、 变更请求、 项目管理计划更新、 项目文件更新、 组织过程资产更新

4W1H

 

4W1H	制定项目章程	制定项目管理计划	指导和管理项目工作	监控项目工作	实施项目整体变更控制	结束项目或阶段
what	编写一份项目章程作用；明确定义项目开始/边界.确立项目正式地位，高级管理层直述他们对项目的支持。	制定一份包括13个子计划，3个基准的项目管理计划作用；生成一份核心文档，做为所有项目工作的依据	1、产出产品、服务或成果 2、产出一份工作绩效信息 3、随着执行的运行，及时提出变更请求并说明采取什么措施。作用；对项目工作提供全面管理	时时监督检查项目，掌控项目作用； 让干系人了解项目当前的状态，已采取的步骤，对预算、进度和范围的预测	按规划的变更机制和变更控制流程进行变更作用； 从整合的角度考虑记录在案的项目变更，降低因未考虑变更对整个项目目标活计划的影响而产生的项目风险	1、移交产品 2、行政工作/行政收尾/管理收尾/合同收尾，核实产品，总结经验教训并归档作用； 总结经验教训，正式结束项目工作，为开展新工作而释放组织资源
why	1、澄清需求， 把协议/SOW内容转化为项目章程； 2、确定项目总体要求，项目概述； 3、任命项目经理，授权项目经理可以动用组织资源； 4、确定项目成功标准	制定一个衡量项目的标尺，指导团队如何开展项目管理工作，每份子计划都说明了如何进行该知识领域的项目管理工作	为实现项目目的	防止项目行为偏离计划，通过监控掌握项目情况，及时了解项目状态和偏差情况	对范围/成本/进度不符合计划的情况即程序/政策进行变更调整	移交产品，积累经验，留下知识财富
who	发起人才有资格制定并批准项目章程，也可以委托项目经理代为编写，但必须发起人批注	项目经理带领项目管理团队/项目团队（如果项目规模小)编写，除了项目进度表由项目经理即管理团队批准外，其他子计划均需高层批准	项目团队	项目管理团队/项目团队（如果项目规模比较小的话)	项目管理团队进行，不涉及基准的、有储备的变更项目团队批准，涉及基准的无储备的变更有CCB批准	项目管理团队/项目团队（如果项目规模比较小)合同收尾是项目经理和合同管理人员的共同责任
where	发起人/高管与外部客签订合同后，或内部决定开展一个项目后，项目/阶段最开始时候做，项目早期	项目早期，项目章程批准后，开始制定项目管理计划	计划制定后，按照计划执行	贯穿始终的监控时做，执行时做	贯穿始终的监控时候做，执行时做	项目或阶段末进行合同收尾在管理收尾之前（行政收尾之前)
how	借鉴过去经验，结合本项目实际，进行商业论证，采用专家判断，引导技术	采用沟通方法，有效整合、将各子计划整合成项目管理计划，采用专家判断、引导技术	使用项目管理信息系统，辅以专家判断和会议	检查等各项专有监控技术，专家判断，分析技术，项目管理信息系统，会议	遵循整体变更控制流程、步骤、会议、专家判断	专家判断分析技术和会议

1，规划范围管理：

参考模板：

        规划XX管理是：xx。在x信息系统规划阶段，我依据XX等资料,邀请XX等关键干系人参加，以专题会议形式对平台建设的管理组织结构，审批流程、XX绩效审计周期、xx责任矩阵等内容进行了深入探讨。

根据会议达成共识，制定XX管理计划的主要内容有：1、2、3、。。。我们将XX管理计划纳入整体管理计划一起通过了评审，该计划为Xx管理提供准则和指南。思考：范围管理计划的目的、内容、制定原则步骤、需求管理计划

范例：

        作为一名合格的项目管理者，做任何事之前都应该先做好计划。好的计划，是成功实施项目的基础。有些人认为做项目范围计划花费了太多时间，不如把它们用于执行工作，项目将会更快更好地完成，我认为这是一个错误的想法，通过省略范围计划制定，虽然能短暂时间内节省一定的时间，但在长期来看，常常会因缺乏管理计划指导而使得范围定义不清、范围蔓延，以致无法完成项目。

        因此，在该项目中，我非常重视范围计划的制定，在正式做计划之前，我先查找了公司组织过程资产，找出制定范围管理计划的模板，再结合以往项目的经验，制定出一份初步的计划，然后召集项目团队成员讨论，对计划进行修改和完善，在全体参与下，最终完成一份详细的、科学的范围管理计划，用于指导项目如何定义、分解以及核实和控制范围。

2．收集需求：

1、收集需求的工具----强调访谈，记录，很多时候客户并不配合，他们往往显得非常忙碌，所以要客户1、安排时间需求调研；2、如果客户没时间时候要安排其它的方式收集需求，比如文件分析、比如观察法、原型法等

2、建立需求跟踪矩阵

3、需求文件--确认（持续确认、需求巡检）、核实（同行评审、检验）、解决需求相关的冲突、批准

4、需求文件：

        1）业务需求

        2）干系人需求

        3）解决方案需求

        4）项目需求（可跟踪性）

        5）过渡需求

        6）与需求有关的假设条件、依赖关系和制约因素

范例：

        一个成功的项目，应该做且只做成功完成项目所需的全部工作。为了保证这一点，就需要在项目前期定义一个明确的项目范围。在项目的早期阶段，我带领团队，到了客户现场收集需求，我组织了客户的运营部门、服务质量部门、IT部门以及我的需求团队，召开需求讨论会，共同商讨项目范围。在收集需求的时候，客户有时候需求描述得不是很清楚，造成了双方对需求理解有歧义，甚至有时候客户对于其需求自己都不清楚，只有一个模糊的概念﹔针对这种情况，我采用原型法将收集到的需求，做成模型供客户参考确认，以此消除彼此的歧义，充分挖掘用户的需求，并基于团队自身的经验以及专业水平，对客户的需求进行引导、细化，将其模糊的概念形象化，粗糙的需求具体化。

3，定义范围：

1、工具技术：专家判断、产品分析、备选方案生成和引导式研讨会。

        ①产品分析：对于那些以产品为可交付成果的项目，是一种有效的工具。

        ②备选方案生成：用来指定尽可能多的潜在可选方案的技术，用于识别执行项目工作的不同方法

2、项目范围说明书的内容：

        ①产品范围描述

        ②验收标准

        ③可交付成果

        ④项目的除外责任

        ⑤制约因素

        ⑥假设条件

范例：

        基于需求文件，我召集项目的主要干系人进行开会讨论，同时邀请了系统的最终用户代表（包括甲方的业务员，装卸工、调度等）对系统功能做评价，通过用户的角度，去发现和改进系统的功能，以此最终形成了完整的项目范围说明书，主要包含：

        ①条码项目的产品范围描述（包括取派件管理、装卸管理、异常管理等）﹔

        ②项目的主要可交付成果（用户文档、应用系统、源代码等） ﹔

        ③产品验收标准（系统运行稳定、功能满足业务需求、相关文档齐全等）﹔

        ④项目的除外责任（该项目涉及的仓库环境改造，强电、弱电改造不包含在该项目范围中）﹔

        ⑤项目制约因素（之前的预算和系统设计仅针对定日达产品进行，如果扩展到零担，必须追加投入、延长项目时间）﹔

        ⑥项目假设条件（假设项目涉及的场站改造、人员素质提高可以配合条码项目进行持续改进，假设甲方的业务系统满足条码项目上线后给其增加的负载）﹔

        ⑦项目的目标、总预算、资源，以及主要里程碑等。

4，创建工作分解结构（WBS）：

1、分解原则、步骤、方法

        1）团队成员（设计、编码等）让执行的人参与、因为自己的事情自己最认可

        2）滚动式规划方式分解，规划包、工作包

        3）和创建wbs的同事审核，工作包三个标准：可估算、可分工、可管理、可控制

2、范围基准的内容

范例：

        基于项目范围说明书，我和我的团队开始对项目范围进行分解，以形成该项目的WBS。在分解过程中，我按照以下原则进行分解。在各层次上保持项目的完整性，我将该项目涉及的需求调研、系统设计、开发、测试等完整的模块都一一列出，避免遗漏必要的组成部分。

        一个工作单元只从属于某个上层单元。对于该项目中的数据库设计，我就只将其归入系统设计单元中，在其他单元不再重复出现，避免了交叉从属。相同层次的工作单元应有相同性质。对于系统设计单元下的数据库设计、接口设计、系统设计等设计内工作，它们从属性上来讲，都属于设计，因此我将其一并归入系统设计单元下。工作单元应能分开不同的责任者和不同的工作内容。对于该项目中每个工作包，我都指定唯一的负责人和其负责的工作内容，便于项目管理进行计划和控制的管理。对于该项目的每个工作包，我都对其进行编号，并与组织结构图和成本控制点深度融合，便于项目的日后管理。应包括项目管理工作，包括分包出去的工作。

        对于该项目，我将项目管理和外包的AP部署也一并纳入WBS中，并逐层分解。WBS的最低层次的工作单元是工作包；对于该项目中工作单元，我参照8/80小时原则细化成具体的工作包，并指定具体的负责人。同时制作WBS词典，对工作包做具体描述。

5．确认范围：

1、确认范围与质量控制的区别：

        时间上：质量控制一般在确认范围前进行，也可同时进行；确认范围一般在阶段末尾进行，而质量控制并不一定在阶段未进行，验收的可交付物要签字。

        人员上：质量控制属内部检查，由执行组织的相应质量部门实施；确认范围则是由外部干系人（客户或发起人）对项目可交付成果进行检查验收。

2、检查也称为审查、评审、审计、走查、巡检、测试等，是指开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准。

3、群体决策就是为达成某种期望结果而对多个未来行动方案进行评估。群体决策技术可用来开发产品需求，以及对产品需求进行归类和优先排序。

达成群体决策的方法有：

        ①—致同意

        ②大多数原则

        ③相对多数原则

        ④独裁

范例：

        范围确认并不是件容易的事情，在与客户的沟通上，我们希望客户尽快确认，以便尽快开展后续的开发阶段工作，而客户则可能认为自己什么也没看到，怎么确认呢？针对这种情况，我在提交文档给客户的相关干系人后，重点对客户的IT人员进行沟通培训，详细介绍系统的设计，然后用他们的声音去向客户的业务部门做出介绍，这样既有益于专业人员之间的技术沟通，也有益于客户业务部门对系统范围的认可与信任。同时，在与客户的业务部门沟通时，我重点强调，虽然范围确认是正式的，但这并不意味着项目的范围就是铁板一块，不能再修改了，只要走标准的变更流程，且审批通过的，都是可以进行变更的。这样就消除了客户的顾虑，便于快速、高效地完成范围确认。

6，控制范围：

1、偏差分析、变更、范围蔓延、镀金的列举

2、范围控制的内容？

3、监控的内容、输出、文件的更新？

范例：

        虽然特意加强了前期的范围定义和后期的范围核实工作，但项目开发工作中，不可避免地还是有了一些变更申请。基于以前类似项目得到的经验，我们在关键过程中进行评审，甲方相关人员在确认过程中一定要签字认可，防止无休止的范围蔓延。虽然做了这样的安排，并且前期通过培训和沟通，确认了甲方的需求和项目边界，但甲方工作人员在范围核实工作中，还是提出了一些新的需求，对于所有的需求，我们要求提交CCB审核。对于影响项目后续开发的要求，我们坚决予以拒绝，对于一些不影响全局的变更，本着良好的合作关系，我们还是给予了处理。在范围控制中，我们还加强了配置管理工作，对项目中的文档、代码等元素建立配置项，专门配备了配置管理人员，没让其他人员兼任，因为配置管理工作做得比较好，在整个开发过程中，没有出现常见的IT项目开发管理中代码版本混乱、文档不全、更新错误等问题。

可考的子题目：

1、项目范围管理的含义与作用、意义

2、项目范围管理包含的主要内容、主要过程

3、项目范围管理中用到的工具和技术、输入输出

4、结合你在项目范围管理中遇到的实际问题与解决方法，论述如何做好项目的范围管理，并总结心得体会

5、请指出你参与管理过的信息系统项目最主要的范围、需求是什么？

6、如何制定范围管理计划（原则、步骤）？范围管理计划的内容有哪些？

7、如何收集需求？项目中的需求有哪些？需求跟踪矩阵？

8、范围说明书的内容有哪些？如何制定范围说明书？

9、如何创建WBS（原则、步骤、作用）？分解有何意义？

10、如何做好范围确认？范围确认的重要性？范围确认和质量控制有何区别？

11、如何做好范围控制？简述范围蔓延和镀金的行为？引起项目范围变更的因素有哪些？变更的原因？

12、简述需求管理和范围管理的区别与联系？

子题目回应参考：

1，确认项目范围对项目管理的意义（2016年上）

        项目范围说明书以及后续的各项可交付成果及时得到发起人或客户的签字验收，能大大提升项目的成功率。

2，项目范围对项目的意义（2017年上）

        业界数据显示，大部分的失败项目不是失败在技术上，而是失败在项目范围没有管理好。作为一个有多年信息系统项目建设经验的项目经理，我一直非常清楚，项目范围是一个信息系统项目建设成功的关键。项目范围管理的好，范围就是万善之源；如果没有管理好，范围就是万恶之源。因此我们说项目范围对项目的意义是成败的起点和根源，一点也不为过。

3，引起项目范围变更的因素（2017年上）

我认为引起项目范围变更的因素主要有三个方面。

        第一，前期范围调研不充分，范围描述的不准确；

        第二，用户出现新的需求；

        第三，政策改变导致范围变更。

4，如何做好项目范围控制，防止项目范围蔓延（2017年上）

        第一，定义科学合理的范围变更控制流程

        第二，甲乙双方明确范围或需求变更的接口人

        第三，所有变更一律要求书面化

        第四，严格按范围变更控制流程执行范围变更，绝不允许有特例以上四点做到位，则能很好的防止项目范围蔓延。

5．项目范围管理的主要过程，工具与技术（2016年上）（2014年上）（2017年上）

        在本项目中，我认真利用了项目范围管理的六个过程：规划范围管理，收集需求，定义范围，创建WBS，确认范围和控制范围，切实做好项目范围管理工作。

        在本项目规划范围管理的过程中，我们在项目管理计划的总体指导下，主要通过专家判断和会议这两个工具和技术制定了项目范围管理计划和需求管理计划。

        在收集需求的过程中，我们主要采用访谈，焦点小组引导式研讨会和静态原型展示相结合的工具与技术。

        在定义范围的过程中，我们主要采用产品分析的工具与技术。

        在创建WBS的过程中，我们与从事设计和编码的人员协同，主要通过利用分解这一工具与技术创建WBS，由于该系统我们选择了分批次迭代开发的模式，因此采用的是滚动式WBS分解规划，即已经明确的需求先分解，需求暂不明确的，先作为规划包，等需求明确后再分解。

        在范围确认时，使用得最多的工具与技术就是用户内部组织的评审和邀请第三方对系统进行验收测试。

        在项目建设的整个过程中，我一直很重视控制范围，严格采用公司规定的配置管理系统和我们与用户达成一致的需求变更控制程序，这两个主要的工具和技术来实施项目的范围控制和范围变更管理。

6，项目范围管理的主要活动以及相关的输入输出（2016年上）

        根据我的经验，我认为规划范围管理过程主要的输入有：项目管理计划和项目章程，主要输出有：范围管理计划和需求管理计划。

        收集需求过程的主要输入有：项目章程，干系人登记册，范围管理计划，需求管理计划，干系人管理计划，主要的输出是需求文件和需求分析矩阵。

        范围定义过程的主要输入有项目章程，范围管理计划和需求文件，主要输出有项目范围说明书。

        创建WBS的主要输入有项目管理计划，项目范围说明书，需求文件，而主要的输出是范围基准。确认范围过程的主要输入有项目管理计划，需求文件，需求跟踪矩阵，核实的可交付成果，工作绩效数据；而主要的输出是验收的可交付成果，工作绩效信息。

        控制范围的主要输入有项目管理计划，需求文件，需求跟踪矩阵，工作绩效数据；而主要的输出是项目绩效信息和变更请求。

7．项目范围管理的含义与作用（2014年上）

        项目范围管理的含义是关注项目内容的定义和控制，明确并确保哪些内容包含在项目中以作为项目开发的各项工作落实的依据。项目范围管理的作用是确保项目包含且只包含达到项目成功所必须完成的工作，同时通过有效的项目范围管理，就项目的建设范围在干系人中达成共识，确保项目范围的变更合理和受控。

8，论述需求开发，需求管理和范围管理的区别和联系（2005年上）

        我认为需求开发就是需求从调研开始到被双方认可的这一过程，因此需求开发一般包括需求获取,需求分析，需求定义和需求验证这四个主要活动；而需求管理就是针对需求开发这一过程，进行有效的跟踪和维护，确保需求被正确的开发出来，从而为后续工作顺利进行提供保障，因此需求管理是为需求开发提供服务的一个管理手段；范围管理则是针对项目所要完成的全部工作进行规划，识别，分解，确认和控制，从而达到做好了该做的工作这一目标。

9．列出信息系统项目范围说明书的主要内容，并简要论述如何依据项目范围说明书制订WBS。（2010年上）

        项目范围说明书主要内容有七大块。项目背景，项目开发需求（按功能编号组织），项目其他需求（除开发需求之外的），项目可交付成果，项目约束和假设条件，项目除外责任（明确哪些是项目之外的内容），成果物验收标准。

        在项目范围管理过程中，我个人认为最难做好的是WBS分解，因为分解WBS虽然容易，但要分解到合适却不容易。为了做到这一点，我们让从事设计和编码的人员参与WBS的分解，实践证明这样做既符合后续设计和编码的人员实际的能力水平（因为自己最了解自己），又能得到他们最大可能的认同和配合（因为自己做的事情自己最认可）﹔由于该项目我们采用的是滚动式规划，即已经明确的需求先分解，需求暂时不明确的，先做为规划包，等待需求明确后再分解。每次WBS分解后，我们都会和创建WBS的同事一起审核被分解到的所有工作包是否符合这三个标准：可估算，可分工，可控制。对于不能同时满足这三个条件的工作包，我们一定会再次分解和修订，直至满足这三条标准为止。

10．结合你承担的项目，从制订需求管理计划，需求变更管理和需求跟踪矩阵等三方面论述需求管理应实施的活动。（2009年下）

        凡事始于计划，项目启动后不久，我们就根据公司的相关政策，项目合同文件，项目招投标文件，项目初步需求等信息，并依据需求管理计划的九个基本步骤：

        1）建立并维护需求管理的组织方针

        2）确定需求管理需使用的资源

        3）分配相关工作人员的工作职责

        4）制订与需求管理相关的培训计划

        5）确定需求管理的相关干系人及介入时机

        6）制订判断项目工作与需求不一致的准则和纠正规程

        7）制定需求跟踪矩阵

        8）确定需求变更审批流程

        9）制定需求管理计划的审批流程

        编制了主要内容为需求管理所需要的软硬件资源，需求跟踪矩阵，和需求变更申请表的需求管理计划。

        需求管理计划通过评审，按审批规程得到审核和批准之后，我们就着手开始开展需求调研及需求管理相关的后续工作。

在需求变更管理方面，我们严格执行之前定义的变更流程的八个步骤。

        1）发起变更

        2）填写需求变更申请表

        3）分析变更对项目的影响

        4）将评估结果发给需求变更发起人审批

        5）将需求变更申请表及其结果发给CCB审批

        6）执行变更

        7）记录变更和实施情况

        8）归档需求变更的实施结果

        项目一路做下来，我们一共执行了88个变更，每一次变更都是在受控的情况下完成的。由于软件项目的特殊性，需求的双向跟踪一直是所有软件项目的难点和重点。本项目我们设计的需求跟踪矩阵主要包括两方面的内容：需求被实现的进度状态（设计，编码，测试和实施），与之对应的设计，编码和测试用例。由于该项目的建设内容多，因此我们采用每一个子系统一个需求跟踪矩阵的形式，这样方便需求跟踪矩阵的维护，同时也增强了需求跟踪矩阵的可读性。

        每一个子系统的需求跟踪矩阵都有专人去维护，及时填写每一个功能需求当前所处的状态以及每一个功能需求所对应的设计，代码文件名和测试用例名称。

        通过进度状态跟踪和过程产出物的跟踪，需求的实现进度和与后续产出物之间的一致性就一目了然。从而为项目监控和识别项目工作与需求之间是否存在不一致性提供了有力的工具保障和信息支持。

        实践证明，我们采用需求跟踪矩阵维护对需求的双向跟踪，虽然花了一些精力和成本，但在很大程度上避免了需求管理的混乱和无序，这种投入是非常值得的。

11．简要介绍需求管理流程的六大方面。（2009年下）

        总体来说，在项目需求管理方面（其实，在该项目的管理过程中，我们把需求管理和项目需求管理中的规划范围管理，收集需求，定义范围，创建WBS，确认范围，控制范围。六个过程有机地结合在了一起。关于本项目的范围管理，本文不重点论述），我带领团队认真落实了需求管理六大方面的工作。首先，我们制订了科学合理的需求管理计划，接着就需求调研之后的产出物《用户需求说明书》的内容与需求提出者进行了确认并达成了一致理解；然后在《用户需求说明书》通过评审后，让用户负责人签字认可并对后续可能出现的变更的具体操作方式给出承诺；在后续需求管理过程中严格遵循需求变更控制程序管理需求变更，我们主要采用需求跟踪矩阵维护对需求的双向跟踪；同时定期审查需求与由需求所衍生出来的工作产品之间的一致性并及时纠正它们之间的不一致性。

12．叙述你所参加的项目需求管理过程，并给予评价。（2009年下）

        回顾本项目，我认为我们实施的需求管理是比较到位和有效的。这主要体现在四个方面：

        一是在对需求的理解上我们和用户的分歧比以前我所负责的项目明显减少

        二是需求变更的可控性明显增强

        三是通过需求跟踪矩阵，我们对项目的实际进度把握得更加精准了

        四是当Bug和问题出现后，我们能通过需求跟踪矩阵迅速找到对应的文档和需要同步修改的内容，从而提高了工作效率。

13．确认范围与质量控制，项目收尾之间的区别于联系

        确认范围和质量控制的区别体现在三个方面。分别是执行顺序，实施时点，强调的侧重点。确认范围一般在质量控制之后施行，或者两者同时进行。确认范围一般在阶段末进行，而质量控制并不一定需要在阶段末施行。质量控制属于内部检查，由执行组织的相应质量部门进行；确认范围一般由外部干系人或发起人来实施。

        质量控制强调的是可交付成果的正确性，确认范围强调的是可交付成果获得客户或发起人的确认与验收。

        确认范围和项目收尾的区别与联系主要体现在以下两个方面： 两者都在阶段末进行。确认范围强调可交付成果物的验收，项目收尾强调的是产品的验收。是除了成果物验收之外，项目收尾还需要做流程性的工作。

14、范围变更控制的主要工作有哪些

        1）影响导致范围变更的因素，并尽量使这些因素朝有利的方面发展

        2）判断当前范围是否发生变更

        3）范围变更实际发生时，确保所有被请求的变更按照项目整体变更控制过程处理

15．范围控制的重要性

        范围控制是监督项目和产品的范围状态，管理范围基准变更的过程。信息系统项目发生变更请求在所难免，但如果不对项目范围基准进行有效的控制，不采用范围控制过程来管理实际的变更的话，就会出现未经批准的变更，甚至是项目范围的扩大。发生项目范围蔓延的风险。

16，如何防止范围蔓延

如果做好以下的五点，可以很好的防止范围蔓延：

        1）在收集需求时彻底理解客户的需求；

        2）对所有的需求，变更请求都书面记录，不接受口头的变更申请；

        3）事先编制项目范围管理计划，并规划定义范围控制流程；

        4）规范确认范围过程，必须接受干系人综合评审

        5）强调完工时间和预算的重要性

17，产品范围和项目范围的区别

        项目的范围基准是经过批准的项目范围说明书，WBS和WBS词典。判断项目范围是否已经完成，要以范围基准来衡量；而产品范围是否完成，则根据产品是否满足了产品描述来判断。

        产品范围描述是项目范围说明书的重要组成部分，因此，产品范围变更后，首先受到影响的是项目范围。

18，项目范围管理的含义和作用

        项目范围管理的含义是关注项目内容的定义和控制，明确并确保哪些内容包含在项目中以作为项目开发的各项工作落实的依据。

        项目范围管理的作用就是确保项目包含且只包含达到项目成功所必须完成的工作，同时通过有效的项目范围管理，就项目的建设范围在干系人中达成共识，确保项目范围的变更合理和受控。

19．收集需求的重要性

        收集需求是为了完成项目可交付成果物，而收集干系人需求和需要的过程。它为定义和管理项目范围奠定了基础。它的输出有需求文件和需求跟踪矩阵两项，分别作为输入用在了之后的子过程：定义范围，创建WBS，确认范围和控制范围过程中，如果收集需求做的不够充分，势必对范围管理之后的子过程造成影响。

20．确认范围的工具与技术

        确认范围是开展测量，审查和确认等活动，来判断可交付成果物。他的工具与技术有检查和群体决策技术。检查包括了审查，产品评审，审计，走查和巡检。

21，WBS分解的五个步骤

        1）识别和分析可交付成果及相关工作

        2）确定WBS结构和编排方法

        3）自上而下逐层细化分解

        4）为WBS组件制订和分配标识编码

        5）核实可交付成果分解得程度是否恰当

        一般将项目生命周期的作为分解的第二层，产品和项目可交付成果放在第三层。WBS不是某个团队成员的责任，应该由全体项目团队成员，用户和项目干系人共同完成和一致确认。