信息系统项目管理师——第9章项目范围管理（重要）

本章属于10大管理知识领域，选择、案例、论文都会考。选择题考大概3分，案例题考的比较多，需要重点记录，论文也考的比较多，建议作为第二梯队准备。

1.管理基础

1.1 产品范围和项目范围

• 产品范围:指某项产品、服务或成果所具有的特征和功能。产品范围的完成情况是根据产品需求来衡量的。
• 项目范围:包括产品范围，是为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。项目范围的完成情况是根据项目管理计划来衡量的。

1.2 管理新实践

• 需求一直是项目管理的关注重点，需求管理过程结束于需求关闭，即把产品、服务或成果移交给接收方，以便长期测量、监控、实现并维持收益。

2.项目范围管理过程

2.1过程概述

2.2裁剪考虑因素

裁剪时应考虑的因素包括:知识和需求管理，确认和控制，开发方法，需求的稳定性，治理。

2.3敏捷和适应方法

敏捷或适应型

• 对于需求不断变化、风险大或不确定性高的项目，在项目开始时通常无法明确项目的范围，而需要在项目期间逐渐明确
• 敏捷或适应型方法特意在项目早期缩短定义和协商范围的时间，为后续细化范围、明确范围争取更多的时间
• 敏捷方法有目的地构建和审查原型，并通过多次发布版本来明确需求，范围会在整个项目期间被定义和再定义
• 采用敏捷或适应型生命周期，旨在应对大量变更，需要于系人持续参与项目。通过多次迭代来开发可交付成果，并在每次迭代开始时定义和批准详细的范围。在每次迭代中，都会重复开展三个过程:收集需求:定义范围:创建WBS
• 在适应型或敏捷型生命周期中，发起人和客户代表应该持续参与项目。在每次迭代中，都会重复开展两个过程：确认范围:控制范围
• 在开展确认范围、控制范围及其他控制过程时，使用未完成项(包括产品需求和用户故事)反映当前需求

预测型

• 在预测型项自中，经过批准的项目范围说明书、工作分解结构(WBS)和相应的WBS词典构成项目范围基准，只有通过正式变更控制程序，才能进行基准变更
• 在开展确认范围、控制范围及其他控制过程时，基准被用作比较的基础

敏捷和预测的区别

• 敏捷型管理
  • 在开始时只花少量时间进行范围定义，目的是为了快速进入开发状态。在之后的开发过程中，会存在大量的变更，通过快速迭代和反复确认来管理范围
• 预测型管理
  • 在开始时花大量时间进行详细的需求分析和范围定义)形成范围基准。在之后的开发过程中，按照计划来进行，有涉及基准的变更，那么走交更流程，通过变更控制来管理范围

确认范围和控制质量

• 确认范围是正式验收已完成的项目可交付成果的过程
• 控制质量过程输出的核实的可交付成果是确认范围过程的输入，而验收的可交付成果是确认范围过程的输出之一，由获得授权的干系人正式签字批准
• 干系人需要在规划阶段早期介入(有时需要在启动阶段就介入),对可交付成果的质量提出意见

3.规范范围管理

规划范围管理是什么?

规划范围管理是为了记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程。

规划范围管理的作用?

在整个项目期间对如何管理范围提供指南和方向。

规划范围管理在项目期间开展的频次?

仅开展一次或仅在项目的预定义时开展

输入

• 1.项目章程。项目章程记录了高层级的需求。
• 2.项目管理计划
  • 质量管理计划:在项目中实施组织的质量政策、方法和标准的方式会影响管理项目和产品范围的
    方式。
  • 项目生命周期描述:定义了项目从开始到完成所经历的一系列阶段。
  • 开发方法:开发方法定义了项目是采用预测型、适应型还是混合型开发方法。
• 3.事业环境因素。
  组织文化、基础设施、人事管理制度和市场条件等。
• 4.组织过程资产
  政策和程序、历史信息和经验教训知识库等。

工具和技术

• 1.专家判断。
  专家利用自身的技能或经验来做出判断。
• 2.数据分析
  备选方案分析:只要是制订计划一般都有备选方案分析。
• 3.会议
  参会者包括项目经理、项目发起人、选定的项目团队成员、选定的干系人、范围管理各过程的负责人以及其他必要人员。

输出

• 1.范围管理计划
  范围管理计划是项目管理计划的组成部分，范围管理计划可以是正式或非正式的，非常详细或高度概括的。
• 2.需求管理计划
  需求管理计划是项目管理计划的组成部分，主要内容包括:
  • 如何规划、跟踪和报告各种需求活动;
  • 配置管理活动，例如，如何启动变更，如何分析其影响，如何进行追溯、跟踪和报告，以及变更审批权限;
  • 需求优先级排序过程;
  • 测量指标及使用这些指标的理由;
  • 反映哪些需求属性将被列入跟踪矩阵等。

4.收集需求

收集需求是什么?

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

收集需求的作用?

为定义产品范围和项目范围奠定基础

收集需求在项目期间开展的频次?

仅开展一次或仅在项目的预定义时开展

输入

• 1.立项管理文件
  商业论证描述为满足业务需要而应该达到的必要、期望及可选标准
• 2.项目章程。
  项目章程记录了项目概述以及将用于制定详细需求的高层级需求
• 3.项目管理计划
  范围管理计划:包含如何定义和制定项目范围的信息。需求管理计划:包含如何收集、分析和记录项目需求的信息干系人参与计划:从该计划中了解干系人的沟通需求和参与程度，以便评估并适应干系人对需求活动的参与程度。
• 4.项目文件
  假设日志:识别了影响需求的其他因素的假设条件。干系人登记册:了解哪些干系人能够提供需求方面的信息，及记录干系人对项目的需求和期望。经验教训登记册:提供了有效的需求收集技术，尤其针对使用敏捷或适应型产品开发方法的项目。
• 5.协议。协议包含项目和产品需求。
• 6.事业环境因素。组织文化、基础设施、人事管理制度、市场条件等。
• 7.组织过程资产。政策和程序;包含以往项目信历史信息和经验教训知识库等。

工具和技术

• 1.专家判断。专家利用自身的技能或经验来做出判断。
• 2数据收集
  • 头脑风暴:一种用来产生和收集对项目需求与产品需求的多种创意的技术。
  • 访谈:通过与干系人直接交谈，来获取信息的正式或非正式的方法。访谈的典型做法是向被访者提出预设和即兴的问题
    并记录他们的回答。
  • 焦点小组:召集干系人和主题专家讨论议题，比一对一访谈更有利于互动交流。
  • 问卷调查:是指设计一系列书面问题，向众多受访者快速收集信息。问卷调查方法非常适用于受众多样化，需要快速完成调查，受访者地理位置分散并且适合开展统计分析的情况
  • 标杆对照:将实际或计划的产品、过程和实践，与其他可比组织的实践进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。标杆对照所采用的可比组织可以是内部的，也可以是外部的。
• 3.数据分析
  • 文件分析:指审核和评估任何相关的文件信息。可供分析有助于获取需求的文件包括，协议;商业计划，业务流程；接口文档;业务规则库;现行流程;市场文献;问题日志；政策和程序、法规文件，如法律、准则、法令等:建议邀书;用例等。
• 4.决策
  • 投票:本技术用于生成、归类和排序产品需求。
  • 独裁型决策制定:采用这种方法，将由一个人负责为整个集体制定决策。
  • 标准决策分析:该技术借助决策矩阵，对众多创意进行评估和排序。
• 5.数据表现
  • 亲和图:用来对大量创意进行分组的技术，以便进一步审查和分析。
  • 思维导图:把从头脑风暴中获得的创意整合成一张图，用以反映创意之间的共性与差异，激发新创意。
• 6.人际关系与团队技能
  • 名义小组技术:是用于促进头脑风暴的一种技术，通过投票排列最有用的创意，以便进一步开展头脑风暴或优先排序。
  • 观察和交谈:是指直接察看个人在各自的环境中如何执行工作(或任务)和实施流程。通过实际执行一个流程或程序，来体验该流程或程序是如何实施的，以便挖掘隐藏的需求。
  • 引导:引导与主题研讨会结合使用，把主要干系人召集在一起定义产品需求。
• 7.系统交互图。系统交互图是对产品范围的可视化描绘
• 8.原型法
  原型法是指在实际制造预期产品之前，先造出该产品的模型。原型包括微缩产品、计算机生成的二维和三维模型、实体模型或模拟。原型
  法支持渐进明细的理念，需要经历从模型创建、用户体验、反馈收集到原型修改的反复循环过程。故事板是一种原型技术，通过一系列的图像或图示来展示顺序或导航路径。

输出

• 1.需求文件
  • 只有明确的(可测量和可测试的)、可跟踪的完整的、相互协调的，且主要干系人愿意认可的需求，才能作为基准。
    *业务解决方案和技术解决方案。前者是干系人的需要，后者是指如何实现这些干系人需要的方案。
    *需求的类别一般包括:
    *业务需求:整个组织的高层级需要。
    *干系人需求:干系人的需要。
    *解决方案需求:解决方案需求又进一步分为功能需求和非功能需求:①功能需求:描述产品应具备的功能②非功能需求:对功能需求的补充，是产品正常运行所需的环境条件或质量要求。
    *过渡和就绪需求:如数据转换和培训需求。这些需求描述了从"当前状态"过渡到“将来状态”所需的临时能力。
    *项目需求:项目需要满足的行动、过程或其他条件，例如里程碑日期、合同责任、制约因素等。
    *质量需求:用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准，例如，测试、认证、确认等【GX202305)
• 2.需求跟踪矩阵
  *需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。
  *跟踪需求的内容包括:①业务需要、机会、目的和目标;②项目目标;③项目范围和WBS可交付成果;④产品设计;⑤产品开发;⑥测试策略和测试场景;⑦高层级需求到详细需求等

5.定义范围

定义范围是什么?

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

定义范围的作用?

描述产品、服务或成果的边界和验收标准。

定义范围在项目期间开展的频次?

需要在整个项目期间反复开展

收集完需求后为什么还要定义范围?

由于在收集需求过程中识别出的所有需求未必都包含在项目中，所以定义范围过程需要从需求文件中选取最终的项目需求，然后制定出关于项目及其产品、服务或成果的详细描述

输入

• 1.项目章程。
  项目章程中包含对项目的高层级描述、产品特征和审批要
  求。
• 2.项目管理计划
  范围管理计划:记录了如何定义、确认和控制项目范围
• 3.项目文件
  假设日志:
  需求文件:识别了应纳入范围的需求。风险登记册:包含了可能影响项目范围的应对策略
• 4.事业环境因素。
  组织文化、基础设施、人事管理制度、市场条件等。
• 5.组织过程资产
  用于制定项目范围说明书的政策、程序和模板，以往项目的项目档案;以往阶段或项目的经验教训等。

工具和技术

• 1.专家判断。
  专家利用自身的技能或经验来做出判断。
• 2.数据分析。
  可用于定义范围过程的数据分析技术是备选方案分析。
• 3.决策。
  可用于定义范围过程的决策技术是多标准决策分析。
• 4.人际关系与团队技能。
• 5.产品分析
  产品分析技术主要包括:产品分解需求分析、系统分析、系统工程、价值分析、价值工程等。

输出

• 1.项目范围说明书
• 项目范围说明书描述要做和不要做的工作的详细程度，
  决定着项目管理团队控制整个项目范围的有效程度。
• 详细的项目范围说明书包括内容有:♥♥♥♥♥♥
  • 产品范围描述:项目章程和需求文件中所述的产品、服务或成果特征。
  • 可交付成果:为完成某一过程、阶段或项目而必须产出的任何独特并可核实的产品、成果或服务能力，可交付
    成果也包括各种辅助成果，如项目管理报告和文件。
  • 验收标准:可交付成果通过验收前必须满足的一系列条件。
  • 项目的除外责任:明确说明哪些内容不属于项目范围，有助于管理干系人的期望及减少范围蔓延。
  • 虽然项目章程和项目范围说明书的内容存在一定程度的重叠，但它们的详细程度完全不同。项目章程包含高层级的信息，而项目范围说明书则是对范围组成部分的详细描述，这些组成部分需要在项目过程中渐达明细反复的
    程就是要变更
• 2.项目文件(更新)
  假设日志、需求文件、需求跟踪矩阵、干系人登记册

6.创建WBS

创建WBS是什么?

创建工作分解结构(WBS)是把项目可交付成果和项目工作分解成较小、更易于管理的组件的过程。

创建WBS的作用?

为所要交付的内容提供架构。

创建WBS在项日期间开展的频次?

仅开展一次或仅在项目的预定义时开展

WBS究竟是什么?

WBS是对项目团队为实现项目目标，创建所需可交付成果而需要实施的全部工作范围的层级分解。WBS组织并定义了项目的总范围，代表着经批准的当前项目范围说明书中所规定的工作。

WBS是否包含管理工作，是否包含计划?

WBS包含管理工作，也包含计划工作

工作包是什么?

WBS最低层的组成部分称为工作包，工作包对相关活动进行归类，以便对工作安排进度，进行估算，开展监督与控制

在“工作分解结构”这个词语中，工作指的是什么?

在“工作分解结构”这个词语中，“工作”是指作为活动结果的工作产品或可交付成果，而丕是活动本身

输入

• 1.项目管理计划
  范围管理计划:定义了如何根据项目范围说明书创建WBS。
• 2.项目文件
  需求文件:详细描述了各种单一需求如何满足项目的业务需要。项目范围说明书:描述了需要实施的工作以及不包含在项目中
  的工作。
• 3.事业环境因素
• 4.组织过程资产

工具和技术

• 1.专家判断。专家利用自身的技能或经验来做出判断。
• 2.分解
  分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术。
  工作包是WBS最低层的工作，可对其成本和持续时间进行估算
  和管理。
  • 1)分解活动 (分解步骤)♥♥♥♥♥
    • 识别和分析可交付成果及相关工作;
    • 确定WBS的结构和编排方法;
    • 自上而下逐层细化分解;
    • 为WBS组成部分制定和分配标识编码;
    • 核实可交付成果分解的程度是否恰当。
  • 2)WBS结构
    WBS的结构可以采用多种形式:♥♥♥♥♥
  • 以项目生命周期的各阶段作为分解的第二层，把产品和项目可交付成果放在第三层。
  • 以主要可交付成果作为分解的第二层。纳入由项目团队以外的组织开发的各种较低层次组件(如外包工
    作)。
  • 如果采用敏捷或适应型方法，可以将长篇故事分解成用户故事。WBS可以采用提纲式、组织结构图或能说明层级结构的其他形式。
  • 要在未来远期才完成的可交付成果或组件，当前可能无法分解。项目管理团队因而通常需要等待对该可交付成果或组成部分达成一致意见，才能够制定出WBS中的相应细节。这种技术又称为滚动式规划。
• 3)注意事项【GX202305]♥♥♥♥♥
  • WBS必须是面向可交付成果的;
  • WBS必须符合项目的范围:在WBS中，所有下一级的元素之和必须100%表上一级的元素。
  • WBS的底层应该支持计划和控制;
  • WBS中的元素必须有人负责，而且只有一个人负责，这个规定又称为独立责任原则。
  • WBS应控制在4~6层，同一级元素的大小应该相似，一个工作单元只能从属于某个上层单元，避免交叉从属。
  • WBS应包括项目管理工作，也要包括分包出去的工作
  • WBS的编制需要所有(主要)项目干系人的参与。
  • WBS并非是一成不变的，在完成了WBS之后的工作中，仍然有可能需要对WBS进行修改。

输出

• 1范围基准
  范围基准是经过批准的范围说明书、(WBS和相应的WBS词典，只有通过正式的变更控制程序才能进行变更，它被用作比较的基础。范围基准是项目管理计划的组成部分。
  • 1)项目范围说明书
    项目范围说明书包括对项目范围、主要可交付成果、假设条件和制约因素的描述。
  • 2)WBS
    WBS是对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解。
  • 3)工作包
    • WBS的最低层是带有独特标识号的工作包。这些标识号为成本、进度和资源信息的逐层汇总提供了层级结构，即账户编码。
    • 控制账户则是一个管理控制点，控制账户包含两个或更多工作包，每个工作包只与一个控制账户关联。
  • 4)规划包
    规划包是一种低于控制账户而高于工作包的工作分解结构组件，工作内容已知，但详细的进度活动未知，一个控制账户可以包含一个或多个规划包。
  • 5)WBS字典
    WBS字典中的内容一般包括:账户编码标识、工作描述、假设条件和制约因素、负责的组织、进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献、协议信息等。
• 2.项目文件(更新)

7.确认范围

确认范围是什么?

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

确认范围的作用?

• ①使验收过程具有客观性;
• ②通过确认每个可交付成果来提高最终产品、服务或成果获得验收的可能性;

确认范围在项目期间开展的频次?

需要在整个项目期间定期开展。

确认范围的步骤?

• ①确定需要进行范围确认的时间;
• ②识别范围确认需要哪些投入;
• ③确定范围正式被接受的标准和要素;
• ④确定范围确认会议的组织步骤;
• ⑤组织范围确达会议;

确认范围和控制质量、核实产品有什么区别?

确认范围前需要做哪些工作?

• ①可交付成果是否是确定的、可确认的。
• ②每个可交付成果是否有明确的里程碑，里程碑是否有明确的、可辨别的事件。
• ③ 是否有明确的质量标准。
• ④审核和承诺是否有清晰的表达。
• ⑤项目范围是否覆盖了需要完成的产品或服务进行的所有活动。
• ⑥项目范围的风险是否太高，管理层是否能够降低风险发生时对项且的影响。

不同的干系人对项目范围的关注点有什么不同?

• 管理层主要关注项目范围:是指范围对项目的进度、资金和资源的影响，这些因素是否超过了组织承受范围，是否在投入产出上具有合理性。
• 客户主要关注产品范围:关心项目的可交付成果是否足够完成产品或服务。
• 项目管理人员主要关注项目制约因素:关心项目可交付成果是否足够和必须完成，时间、资金和资源是否足够，主要的潜在风险和预备解决的方法。
• 项目团队成员主要关心项目范围中自己参与的元素和负责的元素。

输入

• 1.项目管理计划
  范围管理计划:定义了如何正式验收已经完成的可交付成果需求管理计划:描述了如何确认项目需求。范围基准:用范围基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施。
• 2.项目文件
  • 需求文件:将需求与实际结果比较，以决定是否有必要进行变更，采取纠正措施或预防措施。
  • 需求跟踪矩阵:含有与需求相关的信息，包括如何确认需求。
  • 质量报告:该报告内容可包括由团队管理或需上报的全部质量保证事项、改进建议，以及在控制质量过程中发现的情况的概述。
  • 经验教训登记册:在项目早期获得的经验教训可以运用到后期阶段，以提高验收可交付成果的效率与效果。
• 3.工作绩效数据
  工作绩效数据可能包括符合需求的程度、不一致的数量、不一致的严重性或在某时间段内开展确认的次数。
• 4.核实的可交付成果
  核实的可交付成果是指已经完成，并被控制质量过程检查为正确的可交付成果。

工具和技术

• 1.检查
  检查是指开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准。检查有时也被称为审查、产品审查和巡检等。
• 2.决策。
  可用于确认范围过程的决策技术是投票。

输出

• 1.验收的可交付成果
  符合验收标准的可交付成果应该由客户或发起人正式签字批准。应该从客户或发起人那里获得正式文件，证明干系人对项目可交付成果的正式验收。这些文件将提交给结束项目或阶段过程。
• 2.变更请求
  对已经完成但未通过正式验收的可交付成果提出变更请求，开展相应的缺陷补救工作。
• 3.工作绩效信息
• 4.项目文件(更新)
  • 需求文件:记录实际的验收结果，更新需求文件。
  • 需求跟踪矩阵:根据验收结果更新需求跟踪矩阵，包括所采用的验收方法及其使用结果。
  • 经验教训登记册:更新经验教训登记册。

8.控制范围

控制范围是什么?

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

控制范围的作用?

在整个项目期间保持对范围基准的维护

控制范围在项目期间开展的频次?

需要在整个项目期间反复开展

范围蔓延是什么意思?

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

输入

• 1.项目管理计划
  • 范围管理计划:记录了如何控制项目和产品范围。
  • 需求管理计划:记录了如何管理项目需求。
  • 变更管理计划:定义了管理项目变更的过程。
  • 配置管理计划:定义了哪些是配置项，哪些配置项需要正式变更控制，以及针对这些配置项的变更控制过程。
  • 范围基准:用范围基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施。
  • 绩效测量基准:使用挣值分析时，将绩效测量基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施。
• 2.项目文件
  • 需求文件:用于发现任何对商定的项目或产品范围的偏离。
  • 需求跟踪矩阵:有助于探查任何变更或对范围基准的任何偏离对项目目标的影响，它还可以提供受控需求的状态。
  • 经验教训登记册:项目早期的经验教训可以运用到后期阶段，以改进范围控制。
• 3.工作绩效数据
  工作绩效数据可能包括收到的变更请求的数量，接受的变更请求的数量或者核实、确认和完成的可交付成果的数量。
• 4.组织过程资产。现有的、正式的和非正式的与范围控制相关的就会范政策、程序和指南;可用的监督和报告的方法与模板等。

工具和技术

• 1.数据分析
  • 偏差分析:用于将基准与实际结果进行比较，以确定偏差是否处于临界值区间内或是否有必要采取纠正或预防
    措施。
  • 趋势分析:旨在审查项目绩效随时间的变化情况，以判断绩效是正在改善还是正在恶化。
  • 确定偏离范围基准的原因和程度，并决定是否需要采取纠正或预防措施，是项目范围控制的重要工作。

输出

• 1.工作绩效信息
  包括收到的变更的分类、识别的范围偏差和原因、偏差对进度和成本的影响，以及对将来范围绩效的预测。
• 2.变更请求
  分析项目绩效后，可能会就范围基准和进度基准，或项目管理计划的其他组成部分提出变更请求。
• 3.项目管理计划(更新)
  • 范围管理计划:更新范围管理计划，以反映范围管理方式的变更。
  • 范围基准:有时范围偏差太过严重，以至于需要修订范围基准，以便为绩效测量提供现实可行的依据。
  • 进度基准:有时进度偏差太过严重，以至于需要修订进度基准，以便为绩效测量提供现实可行的依据。
  • 成本基准:有时成本偏差太过严重，以至于需要修订成本基准，以便为绩效测量提供现实可行的依据。
  • 绩效测量基准:有时绩效偏差太过严重，需要提出变更请求来修订绩效测量基准，以便为绩效测量提供现实可行的依据。
• 4.项目文件(更新)
  • 需求文件:可以通过增加或修改需求而更新需求文件。
  • 需求跟踪矩阵:应该随同需求文件的更新而更新需求跟踪矩阵。
  • 经验教训登记册:更新经验教训登记册，以记录控制范围的有效技术，以及造成偏差的原因和选择的纠正措施。