10.项目范围管理
2022-06-07 15:45:26 48 举报AI智能生成
登录查看完整内容
信息系统项目管理师第5章：项目范围管理思维导图
作者其他创作
大纲/内容
（1）项目管理计划
（2）项目章程
（3）事业环境因素
（4）组织过程资产
输入
（1）专家判断
（2）会议
工具与技术
（1）范围管理计划
（2）需求管理计划
输出
规划范围管理
（3）干系人管理计划
（4）项目章程
（5）干系人登记册
（1）访谈
（2）焦点小组
（3）引导式研讨会
（4）群体创新技术
（5）群体决策技术
（6）问卷调查
（7）观察
（8）原型法
（9）标杆对照
（10）系统交互图
（11）文件分析
（1）需求文件
（2）需求跟踪矩阵
收集需求
（3）需求文件
（2）产品分析
（3）备选方案生成
（4）引导式研讨会
（1）项目范围说明书
（2）项目文件更新
定义范围
（2）项目范围说明书
（4）事业环境因素
（5）组织过程资产
（1）分解
（2）专家判断
（1）范围基准
创建WBS
（2）需求文件
（3）需求跟踪矩阵
（4）核实（确认）的可交付成果
（5）工作绩效数据
（1）检查
（2）群体决策技术
（1）验收的可交付成果
（2）变更请求
（3）工作绩效信息
（4）项目文件更新
确认范围
（4）工作绩效数据
（1）偏差分析
（1）工作绩效信息
（3）项目管理计划更新
（5）组织过程资产更新
控制范围
各阶段及输入输出
规划过程组
监控过程组
（1）明确项目边界：即明确哪些工作是包括再项目范围之内的，哪些工作是不包括再项目范围之内的
（2）对项目执行工作进行监控：保证该做的工作都做了，而没有多做。
（3）防止项目范围发生蔓延：范围蔓延是指未对时间、成本和资源做相应调整，未经个控制的产品或项目范围的扩大（如客户提出了新需求，超出了范围基准）
明确工作内容
（1）产品范围是指产品或者服务所应该包含的功能；项目范围是指为了能够交付产品，项目所必须做的工作
（2）产品范围是项目范围的基础，产品范围的定义是产品要求的描述；而项目范围的定义是产品项目管理计划的基础，两种范围在应用上有区别
（3）产品范围是否完成是根据产品是否满足了产品描述来判断；项目范围则是以范围基准来衡量（范围基准：是指经过批准的项目范围说明书、WBS和WBS词典）
（4）产品范围描述是项目范围说明书的重要组成部分，所以产品范围变更后，首先收到影响的是项目的范围
产品范围与项目范围
范围管理概述
规划范围管理是编制范围管理计划，书面描述将如何定义、确认和控制项目范围的过程，在整个项目中对如何管理范围提供指南和方向。范围管理计划需要项目管理团队全员参与。
项目整体管理的产出。其中可能包括项目范围管理计划。项目范围管理计划可能在项目管理计划中，也可能作为单独的一项。根据不同的项目而定。
项目管理计划（输入）
（1）如何制订项目范围说明书（定义范围）
（2）如何根据范围说明书创建WBS（工作分解结构）
（3）如何维护和批准WBS（工作分解结构）
（4）如何确认和正式验收已完成的项目可交付成果（确认范围）
（5）如何处理项目范围说明书的变更，该工作与实施整体变更控制过程直接关联（控制范围）
范围管理计划的内容（输出）
需求管理贯穿于整个过程，最基本的任务就是明确需求，并使项目团队和用户达成共识，即建立需求基线。另外，还要建立需求跟踪能力联系链，确保所有用户需求都被正确地应用，并且在需求发生变更时，能够完全地控制其影响范围，始终保持产品与需求的一致性。
需求管理
需求管理计划描述在整个项目生命周期内如何分析、记录和管理需求
（1）如何规划、跟踪和汇报各种需求活动
（2）需求管理需要使用的资源
（3）培训计划
（4）项目干系人参与需求管理的策略
（5）判断项目范围与需求不一致的准则和纠正规则
（6）需求跟踪结构
（7）配置管理活动
需求管理计划内容
整个组织的高层级需要，例如，解决业务问题或抓住业务机会，以及实施项目的原因
（1）业务需求
是指干系人或干系人群体的需要
（2）干系人需求
（3）解决方案需求
从当前状态过渡到将来状态所需的临时能力，例如数据转换和培训需求
（4）过渡需求
项目需要满足的行动、过程或其他条件
（5）项目需求
用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准。QFD对质量需求进行了细分，分为基本需求、期望需求和意外需求
（6）质量需求
。。。。其他
需求的分类
需求管理计划（输出）
ITO内容
可跟踪性是项目需求的一个重要特征，需求跟踪是将单个需求和其他元素之间的依赖关系和逻辑联系建立跟踪，这些元素包括各种类型的需求、业务规则、系统组件，以及帮助文件等。可验证性是需求的最基本特征。
是指检查需求文件中的每个需求是否都能在后继工作产品（成果）中找到对应点
正向跟踪
反向跟踪也称为逆向跟踪，是指检查设计文档、产品构件、测试文档等工作成果是否都能在需求文件中找到出处。
反向跟踪
双向可跟踪性
用户原始需求->需求文件（正向跟踪1）
需求文件->下游工作产品（正向跟踪2）
下游工作产品->需求文件（反向跟踪3）
需求文件->用户原始需求（反向跟踪4）
需求文件<->需求文件（跟踪）
五类需求可跟踪
需求跟踪
表示需求和其他产品元素之间的联系链的最普遍方式是使用需求跟踪（能力）矩阵
需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求理由、所有者、来源、优先级别、版本、当前状态、状态日期等
需求跟踪矩阵（输出）
需求文件描述各种单一的需求将如何满足与项目相关的业务需求。需求文件既可以是一份按干系人和优先级分类列出全部需求的简单文件，也可以是一份包括内容提要、细节描述和附件等的详细文件
（4）项目需求
（5）过渡需求
（6）与需求有关的假设条件、依赖关系和制约因素
需求文件内容
需求文件（输出）
通过与干系人直接交谈来获取信息的正式或非正式的方法，是最基本的一种收集需求的手段
访谈
将预先选定的干系人和专讲集中在一起，进行群体访谈和互动式讨论
焦点小组
通过要求主要的跨职能干系人一起参加会议，对产品需求进行集中讨论与定义。
引导式研讨会
是指可以组织一些群体活动来识别项目和产品需求。包括头脑风暴法、名义小组技术、德尔菲技术、概念/思维导图、亲和图和多标准决策分析等
群体创新技术
群体决策就是为达成某种期望结果而对多个未来行动方案进行评估。【一致同意、大多数原则、相对多数原则、独裁】
群体决策技术
问卷调查
是指直接观察个人在各自的环境中如何开展工作和实施流程
观察
原型法
将实际或计划的做法与其他类似组织的做法进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据
标杆对照法
是范围模型的一个例子，它是对产品范围的可视化描述，显示系统与参与者之间的交互方式。
系统交互图
通过分析现有文档，识别与需求相关的信息来挖掘需求
文件分析
工具与技术（收集需求用的）
针对产品提问并回答，形成对将要开发的产品的用途、特征和其他方面的描述。产品分析技术包括：产品分解、系统分析、需求分析、系统工程、价值工程（产品没做出来之前）和价值分析（产品做出来之后）
产品分析
用来指定尽可能多的潜在可选方案的技术，用于识别执行项目工作的不同方法
备选方案生成
（1）产品范围描述
（2）验收标准
（3）可交付成果
（4）项目的除外责任（什么不能做）
（5）制约因素
（6）假设条件
内容
（1）确定范围
（2）沟通基础
（3）规划和控制依据
（4）变更基础
（5）规划基础
主要作用
项目范围说明书（输出）
创建WBS是将项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程，其主要作用是对所要交付的内容提供一个结构化的视图
在每个分解单元中都存在可交付成果和里程碑。里程碑标志着某个可交付成果或者阶段的正式完成。
里程碑
工作宝石位于WBS每条分支最底层的可交付成果或项目工作组成部分，应便于完整地分派给不同的人或组织单元，所以要求明确个工作单元直接的界面。工作包应该非常具体，以便于承担者能够明确自己的任务。可以用8/80规则进行安排（即最少8h完成，总完成时间不应该大于80h）。
工作包
控制账户是一种管理控制点，在该控制节点上，将范围、预算（资源计划）、实际成本和进度进行整合，并与挣值进行比较以测量绩效。控制账户可以是工作包，也可以是工作包的上层节点，如果是上层节点，则一个控制账户可以包含多个工作包，但一个工作包只属于一个控制账户。
控制账户
规划包是指在控制账户之下，工作内容已知大师尚缺详细进度活动的WBS组成部分。随着情况的逐渐清晰，规划包最终将被分解成工作包以及相应的具体活动。
规划包
也称为WBS词汇表，是描述WBS各组成部分的文件，是对WBS中每个元素的描述。可能包括账户编码标识、工作描述、假设条件和制约因素、负责人或组织单元、进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献、协议信息等。
WBS词典
主要内容
结构示例
（1）识别和分析可交付成果及相关工作（要分解什么）
（2）确定WBS的结构和编排方法（怎么分解）
（1）项目生命周期的各个阶段作为分解的第二层，产品和项目可交付成果放在第三层
（2）主要可交付成果作为分解的第二层
（3）整合可能由项目团队以外的组织来实施的各种组件（例如：外包工作），然后作为外包工作的一部分，卖方需编制相应的合同WBS
（3）自上而下逐层细化分解（开始分解）
（4）为WBS组件制定和分配标识编码（编码）
（5）核实可交付成果分解的程度是恰当的（检查和确认）
创建WBS过程
（1）WBS必须是面向可交付成果的
（2）WBS必须符合项目的范围
（3）WBS的底层应该支持计划和控制
（4）WBS中的元素必须有人负责，而且只由一个人负责，尽管实际上可能需要多个人参与。
（5）WBS的指导，WBS应该控制在4~6层
（6）WBS应包括项目管理工作（因为管理是项目的具体工作的一部分），也要包括分包出去的工作
（7）WBS的编制需要所有（主要）项目干系人的参与，需要项目团队成员的参与
（8）WBS并非是一成不变的，在完成了WBS之后的工作中，仍然有可能需要对WBS进行修改
分解的注意事项
项目的范围基准是经过批准的项目范围说明书、WBS和WBS词典
范围基准（输出）
IOT内容
创建工作分解结构（WBS）
定义：确认范围是正式验收项目已完成的可交付成果的过程。确认范围包括与客户或发起人一起审查可交付成果，确保可交付成果已圆满完成，并获得客户或发起人的正式验收。
（1）确定需要进行范围确认的时间
（2）识别范围确认需要哪些投入
（3）确定范围正式被接受的标准和要素
（4）确定范围确认会议的组织步骤
（5）组织范围确认会议
确认范围的一般步骤
（1）管理层关注的项目范围，是指范围对项目的进度、资金和资源的影响，这些因素是否超过了组织承受范围，是否在投入产出上具有合理性。
（2）客户主要关心的是产品的范围，关心项目的可交付成果是否足够完成产品或服务。
（3）项目管理人员主要关注可交付成果是否足够和必须完成，时间、资金和资源是否足够，主要的潜在风险和预备解决的方案
（4）项目团队成员主要关心项目范围中自己参与的元素和负责的元素，通过定义范围中的时间检查自己的工作时间是否足够，自己范围内的工作是否有冲突
确认范围干系人关注点
（1）确认范围主要强调可交付成果获得客户或发起人的接受；质量控制强调可交付成果的正确性，并符合为其制定的具体质量要求（质量标准）。
（2）质量控制一般在确认范围前进行，也可同时进行；确认范围一般在阶段末尾进行，而质量控制并不一定在阶段末进行。
（3）质量控制属内部检查，由执行组织的相应质量部门实施；确认范围则是由外部干系人（客户或发起人）对项目可交付成果进行检查验收
确认范围与质量控制的不同
开展测量、审查与确认等活动，判断工作和可加服成果是否符合需求和可产品验收标准。
检查
控制范围是监督项目和产品的范围状态、管理范围基准变更的过程。
定义
在整个项目期间保持对范围基准的维护。对项目范围进行控制，就必须确保所有请求的变更、推荐的纠正措施或预防措施都经过实施整体变更控制过程的处理。在变更实际发生时，也要采用范围控制过程来管理这些变更。
作用
（1）政府政策的原因
（2）项目范围的计划编制不够详细周密，有一定的错误或遗漏
（3）市场上出现了或是设计人员提出了新技术、新手段或新方案
（4）项目执行组织本身发生了变化
（5）客户对项目、项目产品或服务的要求发生变化
范围变更的原因
（1）影响导致范围变更的因素，并尽量使其向有利的方向发展
（2）判断范围变更是否已经发生
（3）范围变更发生时管理实际的变更，确保所有被请求的变更按照项目整体变更控制过程处理
如何控制？
项目范围管理
0 条评论
回复 删除
下一页
