项目范围管理

项目范围管理包括确保项目做且只做所需的全部工作，以成功完成项目。项目范围管理主要在于定义和控制哪些工作应该包括在项 内，哪些不应该包含在项目内。(定义项目需要做的事，做只需要做的事。)

管理基础

产品范围和项目范围

产品范围：指某项产品、服务或成果所具有的特征和功能 产品范围的完成情况是根据 产品需求来衡 “需求”是指根据特定协议或其他强制性规范，产品、服务或成果 必须具备的条件或能力。(产品范围，面向产品，强调结果) 项目范围 包括产品范围，是为交付具有规定特性与功能的产品、服务或成果而必须完 成的工作 项目范围的完成情况是根据项目管理计划来衡量的。(项目范围，面向项目，强调过程)

管理新实践

需求一直是项目管理的关注重点，需求管理过程结束于需求关闭，即把产品、服务或成 果移交给接收方，以便长期测量、监控、实现并维持收益。(注重需求和交付) 商业分析师，该角色的职责还应包括需求管理相关的活动，项目经理则负责确保这些活动列入项目管理计划，并且在预算内按时完成，同时能够创造价值。(重视商业分析师的作用) 项目经理与商业分析师之间应该是伙伴式合作关系。(项目经理和商业分析师是平级合作关系)

项目名范围管理过程

过程描述(背诵记忆)

裁剪考虑因素

因为每个项目都是独特的，所以项目经理可能根据需要裁剪项目范围管理过程。裁剪时应考虑的因素包括： 1.知识和需求管理 项目经理应建立哪些指南？为了在未来项目中重复使用需求，组织是否拥有正式或非正式的知识和需求管理体系？ 2.确认和控制 组织是否有正式或非正式的与确认和控制相关政策、程序和指南？ 3.开发方法：组织是否采用敏捷方法管理项目？开发方法属于迭代型还是增量型？是否采用预测型方法？混合型方法是否有效？ 4.需求的稳定性：项目中是否存在需求不稳定的领域？是否有必要采用精益、敏捷或其他适应型技术来处理不稳定的需求，直至需求稳定且定义明确？ 5.治理：组织是否拥有正式或非正式的审计和治理政策、程序和指南？ 简略：知识和需求管理，确认和控制，开发方法，需求的稳定性，治理

敏捷与适应方法(背诵理解)

规划范围管理

输入

1.项目章程(基准方向) 2.项目管理计划(质量管理计划，项目生命周期描述，开发方法) 3.事业环境描述(内外部环境) 4.组织过程资产(历史经验教训)

工具与技术

专家分析，数据分析(备选方案分析)，会议

输出(要求记住掌握)

范围管理计划

范围管理计划是项目管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围。(定义，制定，监督，控制和确定范围) 范围管理计划用于指导如下过程和相关工作:①制定项目范围说明书;②根据详细项目范围说明书创建WBS;③确定如何审批和维护范围基准;④正式验收已完成的项目可交付成果(范围管理计划用于定义范围，创建WBS，形成基准，验收可交付成果) 根据项目需要，范围管理计划可以是正式或非正式的，非常详细或高度概括的。(范围管理计划可以是正式或非正式，模糊或详细的)

需求管理计划

需求管理计划是项目管理计划的组成部分，描述如何分析、记录和管理需求。(需求管理计划是项目管理计划的一部分，用来处理项目需求) 需求管理计划的主要内容包括:①如何规划、跟踪和报告各种需求活动;②配置管理活动，例如，如何启动变更，如何分析其影响，如何进行追溯、跟踪和报告，以及变更审批权限;③需求优先级排序过程;④测量指标及使用这些指标的理由;⑤反映哪些需求属性将被列入跟踪矩阵等(需求活动，配置管理活动，需求优先排序，测量指标，与跟踪矩阵的关系)

收集需求

输入

1.立项管理文件 2.项目章程 3.项目管理计划（范围管理计划、需求管理计划、干系人参与计划） 4.项目文件（假设日志、干系人登记册、经验教训登记册） 5.协议 6.事业环境因素 7.组织过程资产

工具与技术

1.专家判断

2.数据收集（头脑风暴、访谈、焦点小组、问卷调查、标杆对照），要求记住 头脑风暴：收集创意 访谈：与干系人交流 焦点小组：联合相关关系人和特定领域专家讨论 问卷调查：发问卷获得多样化不同受众信息 标杆对照：与成功案例，先行者对比，发现差异不足进行参考修改。

3.数据分析（文件分析），分析相关文件

4.决策（投票、独裁型决策制定、多标准决策分析）,要求记住 投票:更新生成需求 独裁型决策：老大拍板 多标准决策分析：不同维度综合考量

5.数据表现（亲和图、思维导图）,要求记住 亲和图：创意分组 思维导图：整合创意，激发新创意

6.人际关系与团队技能（名义小组技术、观察和交谈、引导）,要求记住 名义小组技术：相关专业人员组成小组，设定问题，每个人对问题写出见解，再依次发言，讨论，每个成员独立思考修正意见，最后达成共识。(这个方法是帮助在头脑风暴中内向或不善讨论的人输出自己的专业，提高创意和讨论质量。) 观察和交谈：目的是明确需求，挖掘隐形需求。 引导：引导合作，达成共识结果。

7.系统交互图 是对产品范围的可视化描绘，可以直观显示业务系统（过程、设备、计算机系统等）及 其与人和其他系统（行动者）之间的交互方式。(可视化展示互动方式)

8.原型法(背诵) 原型法：指在实际制造预期产品之前，先造出该产品的模型，并据此征求对需求的早期反馈。原型法支持渐进明细的理念，需要经历从模型创建、用户体验、反馈收集到原型修改的反复循环过程。在经过足够的反馈循环之后，就可以通过原型获得足够的需求信息，从而进入设计或制造阶段。故事板是一种原型技术，通过一系列的图像或图示来展示顺序或导航路径。(原型循序渐进，故事板来呈现不同版本的原型)

输出

需求文件(要记住)

需求文件描述各种单一需求将如何满足项目相关的业务需求。一开始可能只有高层级的需求，然后随着有关需求信息的增加而逐步细化。(需求文件由高层级需求结合) 只有明确的（可测量和可测试的)、可跟踪的、完整的、相互协调的，且主要干系人愿意认可的需求，才能作为基准。 需求文件的格式多种多样，既可以是一份按干系人和优先级分类列出全部需求的简单文件，也可以是一份包括内容提要、细节描述和附件等的详细文件。

需求跟踪矩阵(要记住)

需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。(记录需求从来源到满足) 使用需求跟踪矩阵，把每个需求与业务目标或项目目标联系起来，有助于确保每个需求都具有业务价值。(需求矩阵能帮助确保需求具备业务价值) 需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法，有助于确保需求文件中被批准的每项需求在项目结束的时候都能实现并交付。(需求矩阵能帮助项目中的需求得到实现) 跟踪需求的内容包括:①业务需要、机会、目的和目标;②项目目标;③项目范围和WBS可交付成果;④产品设计;⑤产品开发;⑥测试策略和测试场景;⑦高层级需求到详细需求等。(需求，目标，范围，交付成果，开发，测试，高级到详细需求) 需求踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态和状态日期。为确保干系人满意，可能需要增加一些补充属性，如稳定性、复杂性和验收标准。(需求矩阵中记录要准确并能区分，可能要增加补充属性)

定义范围

输入

1.项目章程 2.项目管理计划（范围管理计划） 3.项目文件（假设日志、需求文件、 风险登记册） 4.事业环境因素 5.组织过程资产

工具与技术

1.专家判断 2.数据分析（备选方案分析） 3.决策（多标准决策分析） 4.人际关系与团队技能（引导） 5.产品分析(产品分解、需求分析、系统分析、系统工程、价值分析、价值工程等)

输出

项目范围说明书(要记住, 产品可验项)

项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。它记录了整个范围，包括:项目和产品范围;详细描述了项目的可交付成果;代表项目干系人之间就项目范围所达成的共识。为便于管理干系人的期望，项目范围说明书可明确指出哪些工作不属于本项目范围。 详细的项目范围说明书内容有:产品范围描述、可交付成果、验收标准、项目的除外责任【口诀：产品可验项】 产品范围描述:逐步细化在项目章程和需求文件中所述的产品、服务或成果特征。(交付产品，服务和成果的特征) 可交付成果:为完成某一过程、阶段或项目而必须产出的任何独特并可核实的产品、成果或服务能力，可交付成果也包括各种辅助成果，如项目管理报告和文件。(交付的产品，成果和特征) 验收标准:可交付成果通过验收前必须满足的一系列条件。(验收条件) 项目的除外责任:识别排除在项目之外的内容。明确说明哪些内容不属于项目范围，有助于管理干系人的期望及减少范围蔓延。(排除项目意外的责任)

创建WBS

WBS组织并定义了项目的总范围，代表着经批准的当前项目范围说明书中所规定的工作。(WBS规定了项目的范围) WBS最低层的组成部分称为工作包，其中包括计划的工作。工作包对相关活动进行归类，以便对工作安排进度，进行估算，开展监督与控制。在“工作分解结构”这个词语中，“工作”是指作为活动结果的工作产品或可交付成果，而不是活动本身。(WEB最底层组成是工作包，WBS中的工作指的是工作成果而不是工作活动)

输入

1.项目管理计划（范围管理计划） 2.项目文件（需求文件、项目范围说明书） 3.事业环境因素 4.组织过程资产

工具与技术

1. 专家判断
2. 分解(了解记忆) 理解分解 分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术。工作包是WBS最低层的工作，可对其成本和持续时间进行估算和管理。(WBS规定项目范围，WBS拆装出的最小范围是工作包，也就是工作交付成果) 创建WBS的常用的方法包括：自上而下的方法、使用组织特定的指南和使用WBS模板。(WBS使用特定指南，模板，自上而下拆解项目) 要把整个项目工作分解为工作包，通常需要开展如下活动:①识别和分析可交付成果及相关工作;②确定WBS的结构和编排方法;③自上而下逐层细化分解;④为WBS组成部分制定和分配标识编码;⑤核实可交付成果分解的程度是否恰当。(识别工作，确定工作结构编排，自上而下拆解，制定标识编码，核查插接程度)

WBS的结构可以采用多种形式: 1.以项目生命周期的各阶段作为分解的第二层，把产品和项目可交付成果放在第三层。(产品，项目阶段区分) 2.以主要可交付成果作为分解的第二层。(成果区分) 3.纳入由项目团队以外的组织开发的各种较低层次组件（如外包工作）。随后，作为外包工作的一部分，卖方须制定相应的合同WBS。

分解的技巧： 对WBS较高层组件进行分解，就是要把每个可交付成果或组件分解为最基本的组成部分，即可核实的产品、服务或成果。如果采用敏捷或适应型方法，可以将长篇故事分解成用户故事。WBS可以采用提纲式、组织结构图或能说明层级结构的其他形式。(高级组件要分解到产品，服务或成果，敏捷开发下要将长篇故事分解成用户故事，也就是紧缺到角色输出，工具有提纲式，组织结构图) 不同的可交付成果可以分解到不同的层次。工作分解得越细致，对工作的规划、管理和控制就越有力。但是，过细的分解会造成管理努力的无效耗费、资源使用效率低下、工作实施效率降低，同时造成WBS各层级的数据汇总困难。(WBS要分解到合适的成果，服务或产品级别，避免过度琐碎影响效率资源) 要在未来远期才完成的可交付成果或组件，当前可能无法分解。项目管理团队因而通常需要等待对该可交付成果或组成部分达成一致意见，才能够制定出WBS中的相应细节。这种技术又称为滚动式规划。(WBS无法分解不确定范围，可以逐步推进，这叫滚动式规划)

分解的注意点： 1.WBS必须是面向可交付成果的:项目的目标是提供产品或服务，WBS中的各项工作是为提供可交付的成果服务的（多次重复循环，软件测试，已交付成果为导向和构成） 2.WBS必须符合项目的范围:WBS必须包括也仅包括为了完成项目的可交付成果的活动。100%原则（包含原则）认为，在WBS中，所有下一级的元素之和必须100%代表上一级的元素(WBS分层内容关联性要求强，父与子层之间必须是完全精准的包含关系) 3.WBS的底层应该支持计划和控制:WBS是项目管理计划和项目范围之间的桥梁，WBS的底层不但要支持项目管理计划，而且要让管理层能够监视和控制项目的进度和预算(WBS能支持计划和控制) 4.WBS中的元素必须有人负责，而且只有一个人负责(WBS每一个元素都由单人负责，侧重责任落实到个人) 5.WBS应控制在4～6层:如果项目规模比较大，以至于WBS要超过6层，此时，可以使用项目分解结构将大项目分解成子项目，然后针对子项目来做WBS。每个级别的WBS将上一级的一个元素分为4～7个新元素，同一级元素的大小应该相似。一个工作单元只能从属于某个上层单元，避免交叉从属。(WBS控制在4-6层，拆过层数拆出子项目再做WBS拆解，每层向下拆除的子内容应该到4-7个之间，避免交叉从属) 6.WBS应包括项目管理工作（因为管理是项目具体工作的一部分），也要包括分包出去的工作。(WBS内容中包含管理和分包工作) 7.WBS的编制需要所有（主要）项目干系人的参与。(WBS编写需要干系人) 8.WBS并非是一成不变的:完成了WBS之后的工作中，仍然有可能需要对WBS进行修改。(WBS可以更新迭代) 100%原则：通过把WBS底层的所有工作逐层向上汇总，确保既没有遗漏的工作，也没有多余的工作。 ==> WBS拆解确保只完成必要工作。

输出

范围基准(记住)

范围基准是经过批准的范围说明书、WBS(包含工作表和规划包)和相应的WBS词典，只有通过正式的变更控制程序才能进行变更，它被用作比较的基础。范围基准是项目管理计划的组成部分。

项目文件（更新）

1.假设日志：随 创建WBS过程识别出更 假设条件或制约因素而更新 2.需求文件：可以更新需求文件，以反映在创建WBS过程提出并己被批准的变更

确认范围

确定范围的步骤(理解) 1.确认范围应该贯穿项目的始终。(整个项目过程在不断修正范围) 2.确认范围的步骤包括:①确定需要进行范围确认的时间;②识别范围确认需要哪些投入;③确定范围正式被接受的标准和要素;④确定范围确认会议的组织步骤;⑤组织范围确认会议。(确定范围的时间，投入，范围被接受的标准和要素，会议组织步骤，确定会议) 3.确认范围过程与控制质量过程的不同之处在于，前者关注可交付成果的验收，而后者关注可交付成果的正确性及是否满足质量要求。控制质量过程通常先于确认范围过程，但二者也可同时进行。(控制质量关注成果的正确性和质量，控制范围关注成果验收,控制范围一般先与确认范围，也可同时进行)

需要检查的问题(最多选择题) 项目干系人进行范围确认时，一般需要检查以下6个方面的问题: （1）可交付成果是否是确定的、可确认的。 （2）每个可交付成果是否有明确的里程碑，里程碑是否有明确的、可辨别的事件，例如，客户的书面认可等。 （3）是否有明确的质量标准 （4）审核和承诺是否有清晰的表达 （5）项目范围是否覆盖了需要完成的产品或服务的所有活动，有没有遗漏或错误。 （6）项目范围的风险是否太高:管理层是否能够降低风险发生时对项目的影响。

干系人关注点的不同 管理层：关注投资和产出 客户: 关注产品范围 项目管理人：项目制约因素 项目团队成员：自身参与与负责的元素

输入

1.项目管理计划（范围管理计划、需求 管理计划、范围基准） 2.项目文件（需求文件、需求跟踪矩阵、 质量报告、经验教训登记册） 3.工作绩效数据 4.核实的可交付成果

工具与技术

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

2.决策（投票） 投票，当由项目团队和其他干系人进行验收时，使用投票来形成结论。

输出

1.验收的可交付成果 符合验收标准的可交付成果应该由客户或发起人正式签字批准。应该从客户 或发起人那里获得正式文件，证明干系人对项目可交付成果的正式验收。(验收需要客户或发起人验收，签署对应文件)

2.变更请求 3.工作绩效信息 4.项目文件更新（需求文件、需求跟踪矩阵、经验教训登记册）

控制范围

控制范围(记忆背诵) 确保所有变更请求、推荐的纠正措施或预防措施都通过实施整体变更控制过程进行处理。在变更实际发生时，也需要采用控制范围过程来管理这些变更。(控制范围管理变更请求) 控制范围过程应该与其他项目管理知识领域的控制过程协调开展。 未经控制的产品或项目范围的扩大（未对时间、成本和资源做相应调整）被称为范围蔓延。

输入

1.项目管理计划（范围管理计划、需求管理计划、变更管理计划、配置管理计划、 范围基准、绩效测量基准） 2.项目文件（需求文件、需求跟踪矩阵、经验教训登记册） 3.工作绩效数据 4.组织过程资产

工具与技术

1.数据分析(记住，选择区分) 偏差分析:结果和基准比较分析 趋势分析:检查绩效变化

输出

1.工作绩效信息 2.变更请求 3.项目管理计划更新（范围管理计划、范围基准、进度基准、成 本基准、绩效测量基准） 4.项目文件更新（需求文件、需求跟踪矩阵、经验教训登记册）

区分范围蔓延和镀金的行为

镀金：客户没有提新需求，乙方自己做了额外客户不需要的工作，项目人员为了“讨好”客户而做的不解决实际问题、没有应用价值的项目活动。【项目实施人员往往愿意尝试新的技术或者为信息系统项目加上更牛X的功能】团队成员希望表现自己、讨好客户、擅自承诺、送人情、尽善尽美.....(不解决实际问题，讨好客户，做了项目外的事) 蔓延：客户提出新需求，超出了范围基准【客户不断提出要求，不断去改，最终交付物不满足要求】团队客户总是希望更便宜、更多功能、更好服务(指实施内容超出基准范围，导致范围扩大) 没有得到控制的范围扩大、没有得到控制的变更，没有走变更管理流程。比如：客户和某个团队成员关系很好，他提出要加一个功能，这个成员直接就帮他加了。客户没正式提出变更请求，没走流程。团队成员私自帮他加了内容，这是范围蔓延，属于镀金的一种形式。

渐进明细是正常的，因为项目范围不可能在开始的时候就非常清晰，需要不断地细化、完善。比如计划买双鞋，没有确定颜色、款式、价位，到商场后看到了好多双鞋，慢慢的对自己要买的鞋的颜色、款式、价位都有了明确的认识。这是渐进明细。渐进明细是正常的，逐步细化。而范围蔓延和镀金都是不正常的，反对镀金、反对范围蔓延。(范围确认需要渐进明细)

作文真题

习题检测

【例1-18上】关于WBS的描述，不正确的是（B）。 A.WBS必须且只能包括100%的工作 B.WBS的元素必须指定一个或多个负责人(一个元素一个负责人) C.WBS应该由全体项目成员、用户和项目干系人一致确认 D.分包出去的工作也应纳入WBS中

【例2-18上】（B）属于控制范围的活动。 A.与客户仔细讨论项目范围说明书，并请客户签字(范围确认) B.当客户提出新的需求时，说服用户放弃新的需求(控制范围) C.确认项目范围是否覆盖了需要完成的产品或服务进行的所有活动(范围确认) D.确认每项工作是否有明确的质量标准(范围去人)

【例3-18下】某公司决定在现有公文处理系统的基础上，新开发一个移动端APP便于大家远程办公。项目经理召开工作会议，就工作分解结构提出了如下的建议，其中（D）是不妥当的； A.项目组所有人员都要参与，任务分解的层次控制在4至6层之间 B.对目前尚不清楚具体活动的模块可以使用规划包进行分解 C.项目干系人对完成的WBS给予确认，并达成共识 D.项目经理负责项目分解(WBS需要全员参与，并非项目经理一个人说了算)，外包商负责外包合同WBS分解

【例4-18下】 （C）是控制范围常用的工具和技术。 A.引导式研讨会 B.产品分析 C.偏差分析(当然还有趋势分析) D.标杆对照

【例5-19上】关于工作分解结构（WBS）的描述，正确的是（A）。 A.WBS必须符合项目范围 B.WBS元素必须由多个人负责(单人负责) C.WBS必需控制在5-8层(4-6层吧) D.WBS的编制只需要项目团队成员参与(项目团队全员参与)

【例6-19上】关于范围控制的描述，正确的是（C）。 A.控制进度是控制范围的一种有效的方式(控制进度，控制范围是平级) B.项目执行组织本身发生变化不会引起范围变更(会引起) C.范围变更控制必须和其他控制过程综合在一起 D.政府政策的变化不可以成为范围变更的理由(外部环境影响)

【例7-19下】在项目管理的过程中，确认范围的输入不包括（C）。 A.项目管理计划 B.工作绩效数据 C.验收可交付成果 D.需求跟踪矩阵(确认范围输出)

【例8-19下】关于确认范围和质量控制的描述，不正确的是（C）。 A.确认范围强调可交付成果的接受程 B.质量控制强调可交付成果的正确性 C.确认范围和质量控制均由组织内部质量部门实施(确认范围由干系人确认，质量控制由内部质量实施) D.确认范围和质量控制都可以通过检查的方法来进行

【例9-20下】验收的可交付成果,属于项目范围管理中（D）过程的输出。 A.定义范围 B.控制范围 C.收集需求 D.确认范围

【例10-20下】在项目范围管理中,企业管理层主要关注（B）。 A.产品的范围 B.项目范围投入产出的合理性 C.交付成果是否满足质量要求 D.项目过程的合理性

【例11-21上】关于确定范围的描述，正确的是（C）。 A.确认范围是在正式验收阶段才执行的过程(阶段验收执行) B.分解技术是确认范围的主要工具与技术(分解是WBS中的技术) C.客户主要关心产品范围和可交付成果 D.确认范围强调的是结束项目所要做的流程性工作(项目收尾才是)

【例12-21下】关于收集需求的描述，不正确的是（A）。 A.德尔菲技术通过组织专家讨论、并投票来排列最有用创意(名义小组) B. QFD对质量需求分为基本需求、期望需求和意外需求 C.概括性的需求说明文件不能作为基准 D.如果不能将设计元素或测试案例回溯到需求文件，就可能出现镀金行为

【例13-21下】在确认范围过程中，（B）主要关注项目范围对项目进度、资金和资源的影响，这些因素是否超过了组织承受范围，是否在投入产出上具有合理性。 A.客户 B.管理层 C.项目经理 D.项目团队成员

【例14-22上】某公司承担了一个新项目，为一家小型制造企业开发协同工作系统，该制造企业之前没有使用过协同工作系统，业务比较复杂，需求会持续变更，作为项目经理应通过（D）来确保项目顺利完成。 A.项目前期多花时间，尽可能的明确和细化需求 B.更改项目完成时间，提前进行验收，以便处理验收时发现的问题 C.在开发中采用迭代开发的方式，及时调整功能 D.制定需求管理计划，规划如何分析、记录和管理需求(需求管理计划应对管理持续变更的需求)

【例15-22上】在需求文件中，（B）的需求可作为基准使用。 ①可测量和可测试②项目经理认可③完整且可跟踪④相对独立无依赖(相互协调) A.①② B.①③ C.③④ D.②③

【例16-22下】定义范围最重要的任务就是详细定义项目的范围边界，（D）不适合用于描述某个项目的范围。 A.系统开发完成后，开发人员针对系统操作为客户举行两次以上的培训 B.服务软件在对外传输数据过程中不允许以明文形式传输 C.将主会场原有的标清视频会议系统替换为高清（1080P）视频会议系统 D.智能数据分析系统核心功能在2个月内完成，以满足验收要求(有效信息只有时间，没有范围价值)

【例17-22下】关于的WBS描述正确的是（D）。 A.WBS分解得越详细越利于项目的执行(不能太琐碎) B.WBS的元素可以几个人同时负责(单人负责) C.WBS完成后，就不能对WBS进行修改(可以持续修改) D.WBS中下级元素之和等于上级元素

【例18-22下】关于范围确认和范围控制的描述，正确的是（B）。 A.当变更会对进度，成本产生较大影响时，变更申请不应该被通过(看对基准影响，项目实际需求) B.客户和项目团队成员往往有在当前版本中加入所有功能的意愿(本着多快好省的美好愿望) C.确认范围后该项目的范围不能再更改(项目范围可以被不断调整) D.由于政府政策调整而导致项目范围的变更申请，可直接通过(要走流程)

【例19-23上】（C）用于确认项目可交付成果的成功完成。 A.业务需求 B.解决方案需求 C.质量需求 D.过渡与就绪需求

【例20-23上】关于确认范围的描述，不正确的是（B）。 A.确认范围的作用之一是确保验收过程具有客观性 B.确认范围过程通常先于控制质量过程，二者也可同时进行(先质量控制，再确认范围) C.在确认范围时，要检查可交付成果是否有明确的质量标准 D.管理层、客户、项目管理人员在确认范围时的关注点有所不同

【例21-23上】关于WBS的描述，正确的是（A）。 A.WBS中的各项工作为可交付成果提供服务 B.WBS的内容一般会超出完成可交付成果的活动范围(只做有效工作) C.WBS中的元素可以由一人或多人负责(一个人负责) D.WBS应包括分包的工作，但不包括管理工作(包含管理工作)

【例22】在（A）生命周期中，项目开始时就对项目可交付成果进行定义，对任何范围变化都要进行变更管理。 A.预测型 B.适应型 C.敏捷型 D.迭代型

【例23】（D）不是规划范围管理过程的输入。 A.项目章程 B.项目管理计划 C.质量管理计划 D.需求管理计划(输出)

【例24】关于需求的理解，不正确的是（B）。 A.让干系人积极参与需求的探索和分解工作，并仔细确定、记录和管理对产品、服务或成果的需求，能直接促进项目成功 B.为更好地对项目进行了解，收集需求的过程应在整个项目期间定期开展(预定义时间点一次性开展) C.需求是指根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力 D.需求包括发起人、客户和其他干系人的已量化且书面记录的需要和期望

【例25】数据收集技术中，（D）将实际或计划的产品、过程和实践，与其他可比组织的实践进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。 A.头脑风暴 B.焦点小组 C.亲和图 D.标杆对照

【例26】(C)是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。 A.系统交互图 B.决策矩阵 C.需求跟踪矩阵 D.UC矩阵

【例27】应根据（A）来编制详细的项目范围说明书。 ①可交付成果②假设条件③制约因素④WBS(还没项目范围怎么分解工作) A.①②③ B.①②④ C.①③④ D.②③④

【例28】关于项目范围说明书的理解，不正确的是（D）。 A.项目范围说明书可明确指出哪些工作不属于本项目范围 B.项目范围说明书使项目团队能进行更详细的规划，并为评价变更请求或额外工作是否超过项目边界提供基准 C.项目范围说明书描述要做和不要做的工作的详细程度，决定着项目管理团队控制整个项目范围的有效程度 D.项目范围说明书不能代表项目干系人之间就项目范围所达成的共识(能代表)

【例29】范围基准包括（C） ①经过批准的范围说明书②项目章程(先有章程再有基准)③WBS 词典④WBS⑤项目管理计划(依赖基准产生计划) A.①②⑤ B.①②④ C.①③④ D.①④⑤

刷题纯享

【例1-18上】关于WBS的描述，不正确的是（）。 A.WBS必须且只能包括100%的工作 B.WBS的元素必须指定一个或多个负责人 C.WBS应该由全体项目成员、用户和项目干系人一致确认 D.分包出去的工作也应纳入WBS中

【例2-18上】（）属于控制范围的活动。 A.与客户仔细讨论项目范围说明书，并请客户签字 B.当客户提出新的需求时，说服用户放弃新的需求 C.确认项目范围是否覆盖了需要完成的产品或服务进行的所有活动 D.确认每项工作是否有明确的质量标准

【例3-18下】某公司决定在现有公文处理系统的基础上，新开发一个移动端APP便于大家远程办公。项 目经理召开工作会议，就工作分解结构提出了如下的建议，其中（）是不妥当的； A.项目组所有人员都要参与，任务分解的层次控制在4至6层之间 B.对目前尚不清楚具体活动的模块可以使用规划包进行分解 C.项目干系人对完成的WBS给予确认，并达成共识 D.项目经理负责项目分解，外包商负责外包合同WBS分解

【例4-18下】 （）是控制范围常用的工具和技术。 A.引导式研讨会 B.产品分析 C.偏差分析 D.标杆对照

【例5-19上】关于工作分解结构（WBS）的描述，正确的是（）。 A.WBS必须符合项目范围 B.WBS元素必须由多个人负责 C.WBS必需控制在5-8层 D.WBS的编制只需要项目团队成员参与

【例6-19上】关于范围控制的描述，正确的是（）。 A.控制进度是控制范围的一种有效的方式 B.项目执行组织本身发生变化不会引起范围变更 C.范围变更控制必须和其他控制过程综合在一起 D.政府政策的变化不可以成为范围变更的理由

【例7-19下】在项目管理的过程中，确认范围的输入不包括（）。 A.项目管理计划 B.工作绩效数据 C.验收可交付成果 D.需求跟踪矩阵

【例8-19下】关于确认范围和质量控制的描述，不正确的是（）。 A.确认范围强调可交付成果的接受程 B.质量控制强调可交付成果的正确性 C.确认范围和质量控制均由组织内部质量部门实施 D.确认范围和质量控制都可以通过检查的方法来进行

【例9-20下】验收的可交付成果,属于项目范围管理中（）过程的输出。 A.定义范围 B.控制范围 C.收集需求 D.确认范围

【例10-20下】在项目范围管理中,企业管理层主要关注（）。 A.产品的范围 B.项目范围投入产出的合理性 C.交付成果是否满足质量要求 D.项目过程的合理性

【例11-21上】关于确定范围的描述，正确的是（）。 A.确认范围是在正式验收阶段才执行的过程 B.分解技术是确认范围的主要工具与技术 C.客户主要关心产品范围和可交付成果 D.确认范围强调的是结束项目所要做的流程性工作

【例12-21下】关于收集需求的描述，不正确的是（）。 A.德尔菲技术通过组织专家讨论、并投票来排列最有用创意 B. QFD对质量需求分为基本需求、期望需求和意外需求 C.概括性的需求说明文件不能作为基准 D.如果不能将设计元素或测试案例回溯到需求文件，就可能出现镀金行为

【例13-21下】在确认范围过程中，（）主要关注项目范围对项目进度、资金和资源的影响，这些因素是 否超过了组织承受范围，是否在投入产出上具有合理性。 A.客户 B.管理层 C.项目经理 D.项目团队成员

【例14-22上】某公司承担了一个新项目，为一家小型制造企业开发协同工作系统，该制造企业之前没有使用过协同工作系统，业务比较复杂，需求会持续变更，作为项目经理应通过（）来确保项目顺利完成。 A.项目前期多花时间，尽可能的明确和细化需求 B.更改项目完成时间，提前进行验收，以便处理验收时发现的问题 C.在开发中采用迭代开发的方式，及时调整功能 D.制定需求管理计划，规划如何分析、记录和管理需求

【例15-22上】在需求文件中，（）的需求可作为基准使用。 ①可测量和可测试②项目经理认可③完整且可跟踪④相对独立无依赖 A.①② B.①③ C.③④ D.②③

【例16-22下】定义范围最重要的任务就是详细定义项目的范围边界，（）不适合用于描述某个项目的范围。 A.系统开发完成后，开发人员针对系统操作为客户举行两次以上的培训 B.服务软件在对外传输数据过程中不允许以明文形式传输 C.将主会场原有的标清视频会议系统替换为高清（1080P）视频会议系统 D.智能数据分析系统核心功能在2个月内完成，以满足验收要求

【例17-22下】关于的WBS描述正确的是（）。 A.WBS分解得越详细越利于项目的执行 B.WBS的元素可以几个人同时负责 C.WBS完成后，就不能对WBS进行修改 D.WBS中下级元素之和等于上级元素

【例18-22下】关于范围确认和范围控制的描述，正确的是（）。 A.当变更会对进度，成本产生较大影响时，变更申请不应该被通过 B.客户和项目团队成员往往有在当前版本中加入所有功能的意愿 C.确认范围后该项目的范围不能再更改 D.由于政府政策调整而导致项目范围的变更申请，可直接通过

【例19-23上】（）用于确认项目可交付成果的成功完成。 A.业务需求 B.解决方案需求 C.质量需求 D.过渡与就绪需求

【例20-23上】关于确认范围的描述，不正确的是（）。 A.确认范围的作用之一是确保验收过程具有客观性 B.确认范围过程通常先于控制质量过程，二者也可同时进行 C.在确认范围时，要检查可交付成果是否有明确的质量标准 D.管理层、客户、项目管理人员在确认范围时的关注点有所不同

【例21-23上】关于WBS的描述，正确的是（）。 A.WBS中的各项工作为可交付成果提供服务 B.WBS的内容一般会超出完成可交付成果的活动范围 C.WBS中的元素可以由一人或多人负责 D.WBS应包括分包的工作，但不包括管理工作

【例22】在（）生命周期中，项目开始时就对项目可交付成果进行定义，对任何范围变化都要进行变更 管理。 A.预测型 B.适应型 C.敏捷型 D.迭代型

【例23】（）不是规划范围管理过程的输入。 A.项目章程 B.项目管理计划 C.质量管理计划 D.需求管理计划

【例24】关于需求的理解，不正确的是（）。 A.让干系人积极参与需求的探索和分解工作，并仔细确定、记录和管理对产品、服务或成果的需求，能直接促进项目成功 B.为更好地对项目进行了解，收集需求的过程应在整个项目期间定期开展 C.需求是指根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力 D.需求包括发起人、客户和其他干系人的已量化且书面记录的需要和期望

【例25】数据收集技术中，（）将实际或计划的产品、过程和实践，与其他可比组织的实践进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。 A.头脑风暴 B.焦点小组 C.亲和图 D.标杆对照

【例26】是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。 A.系统交互图 B.决策矩阵 C.需求跟踪矩阵 D.UC矩阵

【例27】应根据（）来编制详细的项目范围说明书。 ①可交付成果②假设条件③制约因素④WBS A.①②③ B.①②④ C.①③④ D.②③④

【例28】关于项目范围说明书的理解，不正确的是（）。 A.项目范围说明书可明确指出哪些工作不属于本项目范围 B.项目范围说明书使项目团队能进行更详细的规划，并为评价变更请求或额外工作是否超过项目边界提供基准 C.项目范围说明书描述要做和不要做的工作的详细程度，决定着项目管理团队控制整个项目范围的有效程度 D.项目范围说明书不能代表项目干系人之间就项目范围所达成的共识

【例29】范围基准包括（） ①经过批准的范围说明书②项目章程③WBS 词典④WBS⑤项目管理计划 A.①②⑤ B.①②④ C.①③④ D.①④⑤

背诵记忆