系统集成项目管理工程师之《第七章-项目范围管理》
2022-04-04 11:30:04 0 举报AI智能生成
登录查看完整内容
系统集成项目管理工程师之《第七章-项目范围管理》
作者其他创作
大纲/内容
明确项目边界
对项目执行工作进行监控
防止项目范围发生蔓延
项目范围管理需要做的工作
产品范围是指产品或服务所应包含的功能。
项目范围是指为了能够交付产品，项目必须做的工作。
产品范围是项目范围的基础。
产品范围的定义是产品要求的描述，而项目范围的定义是产生项目管理计划的基础。
判断项目范围是否完成，要以范围基准来衡量。
产品范围是否完成，则根据产品是否满足了产品描述来判断。
产品范围描述是项目范围说明书的重要组成部分。
产品范围、项目范围的区别
项目范围基准是经过批准的项目范围说明书、WBS和WBS词典
范围管理概述
编制范围管理计划，书面描述将如何定义、确认和控制项目范围的过程，其主要作用是在整个项目中队如何管理范围提供指南和方向。
如何制定项目范围说明书
如何根据范围说明书创建WBS
如何维护和批准WBS
如何确认和正式验收已完成的项目可交付成果
如何处理项目范围说明书的变更，该工作与实施整体变更控制过程直接相联
范围管理计划是制定项目管理计划和其他范围管理过程的主要输入，包含内容
需要建立需求跟踪能力联系链，确保所有用户需求都被正确地应用，并且需求发生变更时，能够完全控制其影响范围，保持产品和需求的一致性。
需求管理贯穿整个过程，最基本的任务就是明确需求，并使项目团队和用户达到共识，建立需求基线。
如何规划、跟踪和汇报各种需求互动
需求管理需要使用的资源
培训计划
项目干系人参与需求管理的策略
判断项目范围与需求不一致的准则和纠正规程
需求跟踪结构，需求跟踪矩阵
配置管理活动
需求管理计划描述在整个项目生命周期内如何分析、记录和管理需求，包括内容
编制范围管理计划
为了实现项目目的而确定、记录并管理干系人的需要和需求的过程，作用是为了定义和管理项目范围奠定基础。
业务需求
干系人需求
功能需求
非功能需求
分类
为了满足业务需求、干系人需求，产品、服务或成果必须具备的特性、功能和特征
解决方案需求
过渡需求
项目需求
基本需求
期望需求
意外需求
质量需求
需求分类
访谈
焦点小组
引导式研讨会
头脑风暴
名义小组技术
综合各专家观点，形成最终各方都认可的方案
德尔菲技术
从头脑风暴中获得的创意用一张简单的图联系起来
概念/思维导图
亲和图
多标准决策分析
群体创新技术
群体决策技术
问卷调查
观察
原型法
标杆对照
系统交互图
文件分析
收集需求的工具与技术
描述各种单一的需求将如何满足与项目相关的业务需求
需求文件
需求跟踪矩阵
收集需求过程的输出
与需求有关的假设条件、依赖关系和制约因素
需求文件的内容
控制需求基线
控制单个需求和需求文档的版本
跟踪基线中需求的状态
在产品开发过程中维持需求一致性和精确性的所有活动
需求管理
需求跟踪是将单个需求与其他元素之间的依赖关系和逻辑联系建立跟踪。可验证是需求最基本特性。
可跟踪性是项目需求的一个重要特征
正向跟踪，需求到产品功能
反向跟踪，产品功能到需求
每个配置项的需求到其涉及的产品需求都要具有双向可跟踪性。
箭头表示需求跟踪能力联系链
从用户原始需求可向前追溯到需求文件，这样就能区分出项目过程中或项目结束后由于变更受到影响的需求，也确保了需求文件中包括所有用户需求。同样，可以从需求文件回溯到相应的用户原始需求，确认每个需求的出处。
由于在项目实施过程中，产品需求转变为设计和测试等实现元素，所以通过定义单个需求和特定的产品元素之间的联系链，可以从需求文件追溯到产品元素。这种联系链使项目团队成员知道每个需求对应的产品元素，从而确保产品元素满足每个需求。第四类联系链是从产品元素回溯到需求文件，使项目团队成员知道每个产品元素存在的原因。如果不能将设计元素或测试案例回溯到一个需求文件，就可能出现镀金行为。当然，如果某个孤立的产品元素表明了一个正当的功能，则说明需求文件漏掉了一项需求。
第五类联系链是需求文件之间的跟踪，这种跟踪便于更好地处理各种需求之间的逻辑相关性，检查需求分解中可能出现的错误或遗漏。
表示需求和其他产品元素之间的联系链的最普遍方式是使用需求跟踪（能力）矩阵，需求跟踪矩阵是将产品需求从其来源连接到能满足需求的可交付成果的一种表格
应在需求跟踪矩阵中记录每个需求的相关属性，这些属性有助于明确每个需求的关键信息。需求眼踪矩阵中记录的典型属性包括唯一标识、需求的文字描达、收录该需求的理由、 所有者、来源、优先级别、版本、当前状态 （如进行中、己取消、已推迟、新增加、已批准、已分配、已完成）和状态日期。另外，为了确保干系人满意，可能需要增加一些补充属性，如稳定性、复杂性、验收标准等。
收集需求
定义范围是制定项目和产品详细描述的过程，其主要作用是明确所收集的需求中哪些将包含在项目范围内，哪些将排除在项目范国外，从而明确产品、服务或成果的边界。由于在收集需求的过程中识别出的所有需求未必都包含在项目中，所以定义范國过程就要从需求文件中选取最终的项目需要，然后制定出关于项目及其产品、 服务或成果的详细描述。
对于那些以产品为可交付成果的项目，产品分析是一种有效的工具。通常针对产品提问并回答，形成对将要开发的产品的用途、特征和其他方面的描述。
备选方案生成是一种用来指定尽可能多的潜在可选方案的技术，用于识别执行项目工作的不同方法。
作为定义范围过程的主要成果，项目范田说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。项目范明说明书记录了整个范国，包括项目范明和产品范围，详细描迏项目的可交付成果，以及为提交这些可交付成果而必须开展的工作。
项目目标
产品范围描述
项目边界
项目的可交付成果
项目的制约因素
假设条件
项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。项目范国说明书记录了整个范国，包括项目和产品范国。项目范围说明书详细描述项目的可交付成果，以及为创建这些可交付成果而必须开展的工作。包含的内容如下
确定范围
沟通基础
规划和控制依据
变更基础
规划基础
项目范围说明书的主要作用
范围定义
创建工作分解结构是把项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程
通过工作结构分解，把项目范围分解开来，使项目相关人员对项目一目了然，能够使项目的概况和组成明确、清晰、透明和具体。使项目管理者和项目千系人（如投资人或客户）都能通过 WBS 把握项目，了解和控制项目过程。
保证了项目结构的系统性和完整性。因为分解的过程要求包含项目的所有工作，这样才可能在规划和实施项目中保证不会存在巡漏，进而保证了项目的完整性
通过工作结构分解，可以建立完整的项目保证体系，因为这个分解过程将项目总目标关注的重点（如进度、成本和质量等） 分解到可控制的各项目单元，便于执行和实现目标要求。
项目工作结构分解能够明确项目相关各方的工作界面，便于责任划分和落实
最终工作分解结构可以直接作为进度计划和控制的工具
为建立项目沟通管理提供依据，便于把握信息重点
WBS 是项目各分计划和控制措施制定的基础和主要依据
有助于防止需求和范围蔓延
WBS 的作用和意义
WBS 最低层的工作单元称为工作包，是我们进行进度安排、成本估算和监控的基础。
工作分解结构是用来确定项目范国的，项目的全部工作都必须包含在工作分解结构当中，而且不包含在工作分解结构中的任何工作都不是项目的组成部分，都不能做，否则就是“镀金”
工作分解结构的编制需要所有项目千系人参与，需要项目团队成员参与。
工作分解结构是逐层向下分解的。一般情况下，工作分解结构应控制在 3~6层。
工作分解结构中的各要素应该是相对独立的，要尽量减少相互之间的交叉。
分级的树型结构，类似于组织结构图。树型结构图的WBS层次清晰、非常直观、结构性强，但是不容易修政，对于大型的、 复张的项目也很难表示出项目的全最。由于其具有直观性，一般在一些小的、适中的应用项目中用得较多
表格形式，类似于分级的图书目录。能够反映出项目的所有工作要素，但直观性较差，在一些大型的、复杂的项目中使用较多。
当前较常用的工作分解结构表示形式主要有以下两种：
里程碑标志着某个可交付成果或者阶段的正式完成。
工作包是位于工作分解结构每系分交敢低层的可交付成果或项目工作组成部分。作为一种经验法则，8/80 規则 （80 小时原则）建议工作包至少需要 8个小时来完成。而总完成时间不应大于80小时。
在制作分解结构的过程中，把每个工作包分配到一个控制账户，并根据“控制账户”作包建立唯一标识，这些标识为进行成本、进度与资源信息的层级汇总提供了层级结构。控制账户是一个管理控制点，在该控制点上，把范围、预算、实际成本和进度加以整合，并与挣值相比较，以测量绩效。控制账户设置在 WBS 中选定的管理节点上。每个控制账户可能包括一个或多个工作包，但是一个工作包只能属于一个控制账户。需要生成一些配套的文件，这些文件需要和工作分解结构配合使用，称为工作分解结构词典，它包括工作分解结构组成部分的详细内容、账户编码、工作说明、负责人、进度里程碑清单等，还可能包括合同信息、质量要求、技术文献、计划活动、资源和成本估计等。
识别和分析可交付成果及相关工作。
确定 WBS 的结构和编排方法。
自上而下逐层细化分解。
为 WBS 组件制定和分配标识编码。
核实可交付成果分解的程度是否怡当。
分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的单元，通常需要开展以下活动
项目生命周期的各阶段作为分解的第二层，产品和项目可交付成果放在第三层。
主要可交付成果作为分解的第二层。
整合可能由项目团队以外的组织来实施的各种组件（如外包工作），然后作为外包工作的一部分，卖方需编制相应合同的WBS。
在进行 WBS 分解时，可以有如下三种方式：
在层次上保持项目的完整性，避免遗漏必要的组成部分。
一个工作单元只能从属于某个上层单元，避免交叉从属。
相同层次的工作单元应用相同性质。
工作单元应能分开不同的责任者和不同的工作内容。
便于项目管理计划和项目控制的需要。
最底层工作应该具有可比性，是可管理的、可定量检查的。
应包括项目管理工作，包括分包出去的工作。
工作结构分解应把握如下原则
范围基准：经过批准的范围说明书、WBS 和相应的 WBS 词典组成了范围基准，只有通过正式的变更控制程序才能变更这个基准，它被用作比较的基础。
WBS 词典是针对每个 WBS 组件，详细描述可交付成果、活动和进度信息的文件。WBS 词典对 WBS 提供支持。WBS 词典中的内容包括：账户编码标识、工作描述、假设条件和制约因素、负责的组织、进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标淮、技术参考文献、协议信息。
创建工作分解结构（WBS）
正式验收已完成的项目可交付成果的过程，确认范围应该贯穿项目的始终
确认范围是强调可交付成果获得客户的接受
质量控制强调可交付成果的正确性，并符合为其制定的具体质量要求。
确认范围过程、控制质量过程的不同之处
确定需要进行确认范围的世界
识别确认范围需要哪些投入
确定范围正式被接受的标准和要素
确定确认范围会议的组织步骤
组织确认范围会议
确认范围的步骤
检查
项目范围确认所采用的方法
核实的可交付成果是指已经完成，并经质量过程检查为正确的可交付成果
确认范围
监督项目和产品的范围状态、管理范围基准变更的过程，其主要作用是在整个项目期间保持对范围基准的维护
政府政策的问题
项目范围的计划编制不周密详细，有一定的错误或者遗漏
市场上出现了新技术
项目执行组织本身发生变化
客户对项目、项目产品或服务的要求变化
范围变更的原因
影响导致范围变更的因素，并尽量使这些因素向有利的方面发展
判断范围变更是否已经发生
范围变更发生时管理实际的变更，确保所有被请求的变更按照项目整体变更控制过程处理
范围变更控制的工作
控制范围
第七章-项目范围管理
0 条评论
回复 删除
下一页
