导图社区 信息系统项目管理师教程(第4版)第九章_项目范围管理
该文件是信息系统项目管理教程(第4版)《第九章_项目范围管理》的自制思维导图。包含了规划范围管理、收集需求、定义范围、创建WBS、确认范围、控制范围等内容。根据历年考点重点,标注了重要性,详细的整合了所有内容,可以让最后中复习以及开始学习事半功倍。花了十几个小时将全章节阅读进行整理归纳,全部都是最新版的内容。
编辑于2023-12-13 09:39:36该文件是信息系统项目管理教程(第4版)《第十九章_配置与变更管理》的自制思维导图。包含了项目配置管理和变更管理内容。根据历年考点重点,标注了重要性,详细的整合了所有内容,可以让最后中复习以及开始学习事半功倍。花了十几个小时将全章节阅读进行整理归纳,全部都是最新版的内容。
该文件是信息系统项目管理教程(第4版)《第十八章_项目绩效域》的自制思维导图。包含了项目八大绩效域内容。根据历年考点重点,标注了重要性,详细的整合了所有内容,可以让最后中复习以及开始学习事半功倍。花了十几个小时将全章节阅读进行整理归纳,全部都是最新版的内容。
该文件是信息系统项目管理教程(第4版)《第十七章_干系人管理》的自制思维导图。包含了识别干系人、规划干系人参与、管理干系人参与、监督干系人参与内容。根据历年考点重点,标注了重要性,详细的整合了所有内容,可以让最后中复习以及开始学习事半功倍。花了十几个小时将全章节阅读进行整理归纳,全部都是最新版的内容。
社区模板帮助中心,点此进入>>
该文件是信息系统项目管理教程(第4版)《第十九章_配置与变更管理》的自制思维导图。包含了项目配置管理和变更管理内容。根据历年考点重点,标注了重要性,详细的整合了所有内容,可以让最后中复习以及开始学习事半功倍。花了十几个小时将全章节阅读进行整理归纳,全部都是最新版的内容。
该文件是信息系统项目管理教程(第4版)《第十八章_项目绩效域》的自制思维导图。包含了项目八大绩效域内容。根据历年考点重点,标注了重要性,详细的整合了所有内容,可以让最后中复习以及开始学习事半功倍。花了十几个小时将全章节阅读进行整理归纳,全部都是最新版的内容。
该文件是信息系统项目管理教程(第4版)《第十七章_干系人管理》的自制思维导图。包含了识别干系人、规划干系人参与、管理干系人参与、监督干系人参与内容。根据历年考点重点,标注了重要性,详细的整合了所有内容,可以让最后中复习以及开始学习事半功倍。花了十几个小时将全章节阅读进行整理归纳,全部都是最新版的内容。
项目范围管理
管理基础
项目范围管理包括确保项目做且只做所需的全部工作,以成功完成项目
项目范围管理主要在于定义和控制哪些工作应该包括在项目内,哪些不应该包含在项目内
范围含义
产品范围
指某项产品、服务或成果所具有的特征和功能
完成情况是根据产品需求来衡量的
“需求”是指根据特定协议或其他强制性规范,产品、服务或成果必须具备的条件或能力
项目范围
为交付具有规定特性与功能的产品、服务或成果而必须完成的工作
完成情况根据项目管理计划(中的范围基准)来衡量
1. 产品范围变化,项目范围不一定变化 如:给粉刷墙面,产品是粉刷后的墙,项目是粉刷墙面这个工作,油漆颜色改变,并不会影响项目中具体的工作 2. 项目范围变化,产品范围不一定变化 如:开发一个软件作为产品,项目是为交付软件所需的工作,若给软件增加一轮测试,项目范围变化了,但产品范围并没有变化
管理新实践
商业分析师(BA)
若项目没有配备商业分析师,可由项目经理+核心开发人员负责需求管理相关的活动
负责需求管理相关的活动
项目经理
负责确保需求管理相关的活动列入项目管理计划
商业分析师和项目经理之间应该是伙伴式合作关系
管理过程
剪裁考虑因素包括
知识和需求管理、确认和控制、开发方法、需求的稳定性、治理
敏捷与适应方法
敏捷或适应型项目
采用敏捷或适应型生命周期,旨在应对大量变更,需要干系人持续参与项目
应将适应型项目的整体范围分解为一系列拟实现的需求和拟执行的工作(产品未完成项),通过多次迭代来开发可交付成果,并在每次迭代开始时定义和批准详细的范围
每一次迭代工作
项目团队重复开展三个过程
收集需求、定义范围、创建 WBS
发起人和客户代表重复开展两个过程
确认范围、控制范围
预测型(瀑布型)项目
经过批准的项目范围说明书、工作分解结构(WBS)和相应的 WBS 词典构成项目范围基准
只有通过正式变更控制程序,才能进行基准变更
规划范围管理
过程概述
定义
是为了记录如何定义、确认和控制项目范围及产品范围,而创建范围管理计划的过程
主要作用
在整个项目期间对如何管理范围提供指南和方向
本过程仅开展一次或仅在项目的预定义点开展
范围管理计划
定义
是项目或项目集管理计划的组成部分,描述将如何定义、制定、监督、控制和确认项目范围
制定和细化时需要分析
1. 项目章程中的信息
2. 项目管理计划中已批准的子计划
3. 组织过程资产中的历史信息
4. 相关事业环境因素
输入
1. 项目章程
记录项目目的、项目概述、假设条件、制约因素,以及项目想要实现的高层级的需求
2. 项目管理计划
1. 质量管理计划
在项目中实施组织的质量政策、方法和标准的方式会影响管理项目和产品范围的方式
2. 项目生命周期描述
3. 开发方法
3. 事业影响因素
组织文化、基础设施、人事管理制度和市场条件等
4. 组织过程资产
政策和程序、历史信息和经验教训知识库等
工具与技术
专家判断
数据分析
备选方案分析技术
用于评估、收集需求,详述项目和产品范围,创造产品,确认范围和控制范围的各种方法
会议
输出
1. 范围管理计划
定义
是项目管理计划的组成部分,描述将如何定义、制定、监督、控制和确认项目范围
根据项目需要,范围管理计划可以是正式或非正式的,非常详细或高度概括的
指导(后续)工作
1. 制定项目范围说明书(定义范围)
2. 根据详细项目范围说明书创建 WBS(创建 WBS)
3. 正式验收已完成的项目可交付成果(确认范围)
4. 确定如何审批和维护范围基准(控制范围)
2. 需求管理计划
定义
是项目管理计划的组成部分,描述如何分析、记录和管理需求
主要内容
1. 如何规划、跟踪和报告各种需求活动
2. 配置管理活动,例如,如何启动变更,如何分析其影响,如何进行追溯、跟踪和报告,以及变更审批权限
3. 需求优先级排序过程
4. 测量指标及使用这些指标的理由
需求必须是可量化(可测量)的,如:页面响应速度不超过2s
5. 反映哪些需求属性将被列入跟踪矩阵
收集需求
过程概述
定义
是为实现目标而确定、记录并管理干系人的需要和需求的过程
主要作用
为定义产品范围和项目范围奠定基础
需求
定义
根据特定协议或其他强制性规范,产品、服务或成果必须具备的条件或能力
包括
发起人、客户和其他干系人的已量化且书面记录的需要和期望
处理
足够详细地挖掘、分析和记录这些需求,并将其包含在范围基准中,在项目执行开始后对其进行测量
后续作用
将作为工作分解结构(WBS)的基础,也将作为成本、进度、质量和采购规划的基础
输入
1. 立项管理文件
是商业论证产生的文件,会影响收集需求过程,它描述了为满足业务需要而应该达到的必要、期望及可选标准
2. 项目章程
高层级需求
用于制定详细需求(逐步细化)
3. 项目管理计划
1. 范围管理计划
2. 需求管理计划
3. 干系人参与计划
从该计划中了解干系人的沟通需求和参与程度,以便评估并适应干系人对需求活动的参与程度
4. 项目文件 (按过程输出分类)
1. 制定项目章程
假设日志
识别了有关产品、项目、环境、干系人以及会影响需求的其他因素的假设条件
2. 管理项目知识
经验教训登记册
提供了有效的需求收集技术,尤其针对使用敏捷或适应型产品开发方法的项目
3. 识别干系人
干系人登记册
用于了解哪些干系人能够提供需求方面的信息,及记录干系人对项目的需求和期望
5. 协议
6. 事业影响因素
组织文化、基础设施、人事管理制度、市场条件等
7. 组织过程资产
政策和程序;包含以往项目信息的历史信息和经验教训知识库等
工具与技术
1. 专家判断
可行性研究与评估;需求获取;需求分析;需求文件;以往类似项目的项目需求;图解技术
2. 数据收集
头脑风暴、访谈、焦点小组、问卷调查、标杆对照
3. 数据分析
文件分析
通过分析现有文件,识别与需求相关的信息来获取需求
4. 数据表现
亲和图(分组归类)、思维导图(整合 )
5. 决策
投票(用于生成、归类和排序产品需求)、独裁型决策制定、多标准决策分析
6. 人际关系与团队技能
1. 名义小组技术
先头脑风暴,再投票排序
2. 观察和交谈
可能挖掘出隐藏的需求
3. 引导
与主题研讨会结合使用,把主要干系人召集起来一起定义需求
7. 系统交互图
对产品范围的可视化描绘,可以直观显示业务系统(过程、设备、计算机系统等)及其与人和其他系统 (行动者)之间的交互方式
8. 原型法
定义
指在实际制造预期产品之前,先造出该产品的模型,并据此征求对需求的早期反馈
包括
微缩产品、计算机生成的二维和三维模型、实体模型或模拟
工具
Axure
原型技术
故事板
通过一系列的图像或图示来展示顺序或导航路径
输出
需求文件
作用
描述各种单一需求将如何满足项目相关的业务需求(高层级需求)
基准
明确的(可测量和可测试的)、可跟踪的、完整的、相互协调的,且主要干系人愿意认可的需求
需求类别
1. 业务需求
整个组织的高层级需要,例如,解决业务问题或抓住业务机会,以及实施项目的原因
2. 干系人需求
干系人的需要
3. 解决方案需求
系统需求,为满足业务需求和干系人需求,产品、服务或成果必须具备的特性功能和特征
进一步划分
功能需求
描述产品应具备的功能
例如:产品应该执行的行动、流程、数据和交互
非功能需求
是对功能需求的补充,是产品正常运行所需的环境条件或质量要求
例如:可靠性、保密性、性能、安全性、服务水平、可支持性、保留或清除等
4. 过渡和就绪需求
如数据转换和培训需求,这些需求描述了从“当前状态”过渡到“将来状态”所需的临时能力
5. 项目需求
项目需要满足的行动、过程或其他条件,例如里程碑日期、合同责任、制约因素等
6. 质量需求
用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准,例如,测试、认证、确认等
需求跟踪矩阵
定义
是把产品需求从其来源连接到能满足需求的可交付成果的一种表格
作用
把每个需求与业务目标或项目目标联系起来,有助于确保每个需求都具有业务价值
提供了在整个项目生命周期中跟踪需求的一种方法,有助于确保需求文件中被批准的每项需求在项目结束的时候都能实现并交付
还为管理产品范围变更提供了框架
跟踪需求的内容
1. 业务需要、机会、目的和目标
2. 项目目标
3. 项目范围和 WBS 可交付成果
4. 产品设计
5. 产品开发
6. 测试策略和测试场景
中级案例分析考过填空题
7. 高层级需求到详细需求
记录的典型属性
唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态和状态日期
定义范围
过程概述
定义
是制定项目和产品详细描述的过程
主要作用
描述产品、服务或成果的边界和验收标准
需要在整个项目期间多次反复开展
定义范围过程需要从需求文件(收集需求过程的输出)中选取最终的项目需求,然后制定出关于项目及其产品、服务或成果的详细描述
需要分析现有风险(风险登记册)、假设条件和制约因素(假设日志)的完整性,并做必要的增补或更新
详细的项目范围说明书
对项目成功至关重要
应根据项目启动过程中记载的主要可交付成果、假设条件和制约因素来编制详细的项目范围说明书
在项目规划过程中,随着对项目信息了解的逐渐深入,应该更加详细、具体地定义和描述项目范围
输入
1. 项目章程
包含对项目的高层级描述、产品特征和审批要求
2. 项目管理计划 - 范围管理计划
记录了如何定义、确认和控制项目范围
3. 项目文件 (按过程输出分类)
1. 制定项目章程
假设日志
识别了有关产品、项目、环境、干系人以及会影响项目和产品范围的假设条件和制约因素
2. 收集需求
需求文件
识别了应纳入范围的需求
3. 识别风险
风险登记册
包含了可能影响项目范围的应对策略,例如缩小或改变项目和产品范围,以规避或缓解风险
4. 事业影响因素
组织文化、基础设施、人事管理制度、市场条件等
5. 组织过程资产
用于制定项目范围说明书的政策、程序和模板;以往项目的项目档案;以往阶段或项目的经验教训等
工具与技术
1. 专家判断
应征求具备类似项目的知识或经验的个人或小组的意见
2. 数据分析
备选方案分析
评估实现项目章程中所述的需求和目标的各种方法
3. 决策
多标准决策分析
一种借助决策矩阵来使用系统分析方法的技术,目的是建立诸如需求、进度、预算和资源等多种标准来完善项目和产品范围
4. 人际关系与团队技能
引导
5. 产品分析
作用
用于定义产品和服务,包括针对产品或服务提问并回答,以描述要交付产品的用途、特征及其他方面
把高层级的产品或服务描述转变为有意义的可交付成果
步骤
获取高层级的需求
将其细化到最终产品设计所需的详细程度
技术包括
产品分解、需求分析、系统分析、系统工程、价值分析、价值工程等
输出
项目范围说明书
定义
对项目范围、主要可交付成果、假设条件和制约因素的描述
作用
记录了整个范围,包括:项目和产品范围、详细描述了项目的可交付成果、代表项目干系人之间就项目范围所达成的共识
内容
1. 产品范围描述
逐步细化在项目章程和需求文件中所述的产品、服务或成果特征
2. 可交付成果
为完成某一过程、阶段或项目而必须产出的任何独特并可核实的产品、成果或服务能力,可交付成果也包括各种辅助成果,如项目管理报告和文件。对可交付成果的描述可略可详
3. 验收标准
可交付成果通过验收前必须满足的一系列条件
一一对应
4. 项目的除外责任
避免容易产生分歧和误解的地方,如给甲方做一个信息管理管理系统,但不给他们提供服务器,这一点要标注在项目除外责任中
识别排除在项目之外的内容。明确说明哪些内容不属于项目范围,有助于管理干系人的期望及减少范围蔓延
5. 假设条件
6. 制约因素
与项目章程的联系与区别
项目章程
包含高层级的信息
范围说明书
对范围组成部分的详细描述,这些组成部分需要在项目过程中渐进明细
内容存在一定程度的重叠,但详细程度完全不同
描述要做和不要做的工作的详细程度,决定着项目管理团队控制整个项目范围的有效程度
项目文件(更新)
1. 需求文件
2. 需求跟踪矩阵
收集需求过程的输出
3. 假设日志
4. 干系人登记册
创建 WBS
过程概述
定义
是把项目可交付成果和项目工作分解成较小、更易于管理的组件的过程
主要作用
为所要交付的内容提供架构
WBS (工作分解结构)
定义
是对项目团队为实现项目目标,创建所需可交付成果而需要实施的全部工作范围的层级分解
“工作”含义
指作为活动结果的工作产品或可交付成果,而不是活动本身
工作包
WBS 最低层的组成部分称为工作包,其中包括计划的工作
工作包对相关活动进行归类以便对工作安排进度,进行估算,开展监督与控制
就是最小的可交付成果
WBS 组织并定义了项目的总范围,代表着经批准的当前项目范围说明书中所规定的工作
输入
项目管理计划 - 范围管理计划
定义了如何根据项目范围说明书创建WBS
项目文件 (按过程输出分类)
1. 收集需求
需求文件
详细描述了各种单一需求如何满足项目的业务需要
2. 定义范围
项目范围说明书
描述了需要实施的工作以及不包含在项目中的工作
事业影响因素
项目所在行业的 WBS标准,这些标准可以作为创建WBS的外部参考资料
组织过程资产
用于创建WBS 的政策、程序和模板;以往项目的项目档案;以往项目的经验教训等
工具与技术
专家判断
征求具备类似项目知识或经验的个人或小组的意见
分解
概述
定义
是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术
工作包
定义
WBS 最低层的工作,可对其成本和持续时间进行估算和管理
详细程度
因项目规模和复杂程度而异
分解程度
取决于所需的控制程度,以实现对项目的高效管理
创建 WBS 的方法
1. 自上而下的方法
可用于归并较低层次的组件
2. 使用组织特定的指南
3. 使用 WBS模板
分解活动
1. 识别和分析可交付成果及相关工作(识别需要分解的可交付成果及工作)
2. 确定 WBS 的结构和编排方法(确定分解结构)
树型结构(组织系结构图):适用于小型项目 表格结构(提纲式):适用于大型项目
3. 自上而下逐层细化分解(自上而下逐步分解)
4. 为 WBS 组成部分制定和分配标识编码(标识 WBS 组成部分)
5. 核实可交付成果分解的程度是否恰当(检查分解程度是否恰当)
WBS 结构
结构形式
1. 项目生命周期的各阶段作为分解的第二层 产品和项目可交付成果放在第三层
2. 以主要可交付成果作为分解的第二层
3. 纳入由项目团队以外的组织开发的各种较低层次组件(如外包工作)。随后,作为外包工作的一部分,卖方须制定相应的合同WBS
外包出去的工作也必须纳入 WBS 中
对 WBS 较高层组件进行分解,就是要把每个可交付成果或组件分解为最基本的组成部分,即可核实的产品、服务或成果
如果采用敏捷或适应型方法,WBS可以采用提纲式、组织结构图或能说明层级结构的其他形式
不同的可交付成果可以分解到不同的层次
分解细致的优缺点
优点
工作分解得越细致,对工作的规划、管理和控制就越有力
缺点
过细的分解会造成管理努力的无效耗费、资源使用效率低下、工作实施效率降低,同时造成 WBS 各层级的数据汇总困难
注意事项
1. WBS 必须是面向可交付成果的
项目的目标是提供产品或服务,WBS 中的各项工作是为提供可交付的成果服务的
2. WBS 必须符合项目的范围
WBS 必须包括也仅包括为了完成项目的可交付成果的活动
在 WBS 中,所有下一级元素之和必须 100% 代表上一级元素之和(100% 原则)
3. WBS 的底层应该支持计划和控制
WBS 是项目管理计划和项目范围之间的桥梁
WBS 的底层不但要支持项目管理计划,而且要让管理层能够监视和控制项目的进度和预算
4. WBS 中的元素必须有人负责,而且只有一个人负责(独立责任原则)
有且仅有一个负责人,但可以多人参与,WBS 和责任人可以使用工作责任矩阵来描述
5. WBS 应控制在 4~6 层
每个级别的 WBS 将上一级的一个元素分为 4~7 个新元素,同一级元素的大小应相似
一个工作单元只能从属某个上级单元,避免交叉从属
6. WBS 应包括项目管理工作(因为管理是项目具体工作的一部分),也要包括分包出去的工作
7. WBS 的编制需要所有(主要) 项目干系人的参与
8. WBS 并非是一成不变的
在完成了 WBS 之后的工作中,仍然有可能需要对 WBS 进行修改,需要通过正式的变更控制程序才能变更
9. 8/80原则
补充
工作包的工期控制在8-80小时之间
输出
范围基准
定义
是经过批准的范围说明书、WBS 和相应的 WBS 词典,只有通过正式的变更控制程序才能进行变更,它被用作比较的基础
项目范围说明书
包括对项目范围、主要可交付成果、假设条件和制约因素的描述
WBS
是对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解
控制账户
一个管理控制点,在该控制点上,把范围、预算和进度加以整合,并与挣值相比较来测量绩效
包含
工作包
WBS 的最低层是带有独特标识号的工作包
标识号
为成本、进度和资源信息的逐层汇总提供了层级结构,即账户编码
控制账户包含两个或以上工作包,每个工作包只能与一个控制账户关联
规划包
是一种低于控制账户而高于工作包的工作分解结构组件,工作内容已知,但详细的进度活动未知
一个控制账户可以包含一个或以上规划包
WBS 字典
定义
是针对 WBS 中的每个组件,详细描述可交付成果、活动和进度信息的文件(对 WBS 的补充说明)
作用
WBS 字典对 WBS 提供支持,其中大部分信息由其他过程创建,然后在后期添加到字典中
内容包括
账户编码标识、工作描述、假设条件和制约因素、负责的组织.进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献、协议信息等
项目文件(更新)
假设日志
需求文件
确认范围
过程概述
应贯穿项目的始终
定义
是正式验收已完成的项目可交付成果的过程
主要作用
使验收过程具有客观性
通过确认每个可交付成果来提高最终产品、服务或成果获得验收的可能性
应根据需要在整个项目期间定期开展
参与者
由主要干系人,尤其是客户或发起人审查从(质量管理)控制质量过程输出的核实的可交付成果,确认这些可交付成果已经圆满完成并通过正式验收
确认范围的依据
项目范围管理知识领域的相应过程获得的输出(如需求文件或范围基准)
从其他知识领域的执行过程获得的工作绩效数据
确认范围的步骤
可能考排序
1. 确定需要进行范围确认的时间
2. 识别范围确认需要哪些投入
3. 确定范围正式被接受的标准和要素
4. 确定范围确认会议的组织步骤
5. 组织范围确认会议
与控制质量过程比较
确认范围过程关注可交付成果的验收,而控制质量过程关注可交付成果的正确性及是否满足质量要求
通常情况下,在确认范围前,项目团队需要先进行质量控制工作(先质量控制,再确认范围),例如,在确认软件项目的范围之前,需要进行系统测试等工作,以确保确认工作的顺利完成
控制质量过程通常先于确认范围过程,但二者也可同时进行
需要检查的问题
案例分析考过
1. 可交付成果是否是确定的、可确认的
2. 每个可交付成果是否有明确的里程碑,里程碑是否有明确的、可辨别的事件,例如,客户的书面认可等
3. 是否有明确的质量标准
可交付成果的交付不但要有明确的标准标志,而且要有是否按照要求完成的标准,可交付成果和其标准之间是否有明确联系
4. 审核和承诺是否有清晰的表达
发起人必须正式同意项目的边界,项目完成的产品或者服务,以及项目相关的可交付成果
项目团队必须清楚地了解可交付成果是什么
5. 项目范围是否覆盖了需要完成的产品或服务的所有活动,有没有遗漏或错误
6. 项目范围的风险是否太高
管理层是否能够降低风险发生时对项目的影响
干系人关注点的不同
1. 管理层主要关注项目范围
指范围对项目的进度、资金和资源的影响,这些因素是否超过了组织的承受范围,是否在投入产出上具有合理性
2. 客户主要关注产品范围
关心项目的可交付成果是否足够完成产品或服务
3. 项目管理人员主要关注项目制约因素
关心项目可交付成果是否足够和必须完成,时间、资金、资源是否足够,主要的潜在风险和预备解决的方法
4. 项目团队成员主要关注项目范围中自己参与的元素和负责的元素
通过定义范围中的时间检查自己的工作时间是否足够,自己在项目范围中是否有多项工作,而这些工作是否有冲突的地方
输入
项目管理计划
1. 范围管理计划
定义了如何正式验收已经完成的可交付成果
2. 需求管理计划
描述了如何确认项目需求
3. 范围基准
用范围基准与实际结果比较,以决定是否有必要进行变更、采取纠正措施或预防措施
项目文件 (按过程输出分类)
1. 收集需求
需求文件
将需求与实际结果比较,以决定是否有必要进行变更,采取纠正措施或预防措施
需求跟踪矩阵
含有与需求相关的信息,包括如何确认需求
2. 管理质量
质量报告
内容可包括由团队管理或需上报的全部质量保证事项、改进建议,以及在控制质量过程中发现的情况的概述
3. 管理项目知识
经验教训登记册
在项目早期获得的经验教训可以运用到后期阶段,以提高验收可交付成果的效率与效果
工作绩效数据
包括符合需求的程度、不一致的数量、不一致的严重性或在某时间段内开展确认的次数
核实的可交付成果
指已经完成,并被控制质量过程检查为正确的可交付成果
工具与技术
检查(审查、产品审查和巡检)
开展测量、审查与确认等活动,来判断工作和可交付成果是否符合需求和产品验收标准
决策
输出
验收的可交付成果
对于符合验收标准的可交付成果,应该拟定一个正式文件,由客户或发起人正式签字批准
变更请求
对已经完成但未通过正式验收的可交付成果及其未通过验收的原因,应该记录在案。可能需要针对这些可交付成果提出变更请求,开展相应的缺陷补救工作
工作绩效信息
包括项目进展信息,例如,哪些可交付成果已经被验收,哪些未通过验收以及原因。记录这些信息并传递给干系人
项目文件(更新)
1. 需求文件
记录实际的验收结果,更新需求文件
2. 需求跟踪矩阵
根据验收结果更新需求跟踪矩阵,包括所采用的验收方法及其使用结果
3. 经验教训登记册
控制范围
过程概述
定义
是监督项目和产品的范围状态,管理范围基准变更的过程
主要作用
在整个项目期间保持对范围基准的维护
需要在整个项目期间开展
控制范围过程应该与其他项目管理知识领域的控制过程协调开展
管理变更
控制项目范围确保所有变更请求、推荐的纠正措施或预防措施都通过实施整体变更控制过程进行处理
范围蔓延
未经控制的产品或项目范围的扩大(未对时间、成本和资源做相应调整)
输入
项目管理计划
1. 范围管理计划
记录了如何控制项目和产品范围
2. 需求管理计划
记录了如何管理项目需求
3. 变更管理计划
定义了管理项目变更的过程
4. 配置管理计划
定义了哪些是配置项,哪些配置项需要正式变更控制,以及针对这些配置项的变更控制过程
5. 范围基准
用范围基准与实际结果比较,以决定是否有必要进行变更、采取纠正措施或预防措施
6. 绩效测量基准
使用挣值分析时,将绩效测量基准与实际结果比较,以决定是否有必要进行变更、采取纠正措施或预防措施
项目文件 (按过程输出分类)
1. 管理项目知识
经验教训登记册
2. 收集需求
需求文件
用于发现任何对商定的项目或产品范围的偏离
需求跟踪矩阵
有助于探查任何变更或对范围基准的任何偏离对项目目标的影响,它还可以提供受控需求的状态
工作绩效数据
包括收到的变更请求的数量,接受的变更请求的数量或者核实、确认和完成的可交付成果的数量
组织过程资产
现有的、正式的和非正式的与范围控制相关的政策、程序和指南;可用的监督和报告的方法与模板等
工具与技术
数据分析
偏差分析
将基准与实际结果(工作绩效数据)进行比较,以确定偏差是否处于临界值区间内或是否有必要采取纠正或预防措施
趋势分析
审查项目绩效随时间的变化情况,以判断绩效是正在改善还是正在恶化
确定偏离范围基准的原因和程度,并决定是否需要采取纠正或预防措施,是项目范围控制的重要工作
输出
工作绩效信息
有关项目和产品范围实施情况(对照范围基准)的相互关联且与各种背景相结合的信息
包括
括收到的变更的分类、识别的范围偏差和原因、偏差对进度和成本的影响,以及对将来范围绩效的预测
变更请求
项目管理计划(更新)
1. 范围管理计划
2. 范围基准
在针对范围、范围说明书、WBS 或 WBS 词典的变更获得批准后,需要对范围基准做出相应的变更
3. 进度基准
在针对范围、资源或进度估算的变更获得批准后,需要对进度基准做出相应的变更
4. 成本基准
在针对范围、资源或成本估算的变更获得批准后,需要对成本基准做出相应的变更
5. 绩效测量基准
在针对范围、进度绩效或成本估算的变更获得批准后,需要对绩效测量基准做出相应的变更
若偏差过大需重新制定基准
项目文件(更新)
1. 需求文件
增加或修改需求
2. 需求跟踪矩阵
随需求文件变化
3. 经验教训登记册
习题
正确答案选 C,各个管理过程本身就是相互交叠、相互作用的,而控制范围过程中,若范围发生变化,则会引起进度、成本、质量的变化,故这几个过程需要整合起来
选项 B,项目执行组织变动可能会引起项目范围变化,若组织中某个人员离职,但项目中某个工作只有他能胜任,此时就不得不暂时将该工作搁置,直至找到新的人员顶替该员工的工作