导图社区 第五章项目范围管理
项目管理师是指掌握项目管理原理、技术、方法和工具,参与或领导启动、计划、组织、执行、控制和收尾过程的活动,确保项目能在规定的范围、时间、质量与成本等约束条件下完成既定目标的人员。
编辑于2022-06-21 11:42:52第五章项目范围管理
项目范围管理
项目目标得更具体的表达,必须在干系人之间达成一致 做范围内的事,而且只做范围内的事,既不少做也不多做
1明确项目边界 2对项目执行工作进行监控 3防止项目范围发生蔓延
范围蔓延:客户提出新要求,超出范围基准;未经控制的产品或项目范围扩大 ——项目外部原因造成的蔓延
范围镀金:客户没有提新要求,项目自己额外做了不需要工作 ——项目团队内部原因造成的蔓延
范围潜变:客户不断提出小的、不易察觉的范围改变,不加控制,累加导致项目严重偏离范围基准,项目失控或失败
产品范围(技术主线):产品或服务缩影保险的功能 ——强调结果
判断产品范围是否完成:根据产品是否满足了产品描述来判断
项目范围(管理主线):为了能够交付产品,项目必须做的工作 ——强调过程
判断项目范围是否完成:项目范围基准(经批准的项目范围说明书、WBS、WBS词典)
产品范围市项目范围的基础,产品范围的定义是项目范围的描述,项目范围的定义是产品项目管理计划的基础 产品范围描述市项目范围说明书的重要组成部分,产品范围变更后首先影响项目范围
规划范围管理
输入:1项目管理计划 2项目章程 3事业环境因素 4组织过程资产
工具与技术:专家判断 会议
输出:1范围管理计划 2需求管理计划
范围管理计划
内容: 1.如何制定项目范围说明书 2.如何根据范围说明书创建WBS(工作分解结构) 3.如何维护和批准WBS 4.如何确认和正式验收已完成的项目可交付成果 5.如何处理项目项目范围说明书的变更
WBS编制指南内容: 1.确定WBS满足职能和项目的要求,包括重置和非重置成本 2.检查WBS是否为所有的项目工作提供了逻辑细分 3.保证每一个特定层的总成本等于下一个层次构成要素的成本和 4.从全面适应和连续角度来检查WBS 5.所有的工作职责需分配到个人或组织单位
需求管理计划
需求管理计划描述在整个项目生命周期内如何分析、记录和管理需求。贯穿于整个过程, 最基本任务: 明确需求,并使项目团队和用户达成共识,建立需求基线,建立需求跟踪能力联系链,确保所有用户需求都被正确地应用,并且在需求发生变更时,能够完全地控制其影响范围,始终保持产品与需求的一致性。
内容: ①如何规划、跟踪和汇报各种需求活动 ②需求管理需要使用的资源、③培训计划 ④项目干系人参与需求管理的策略 ⑤判断项目范围与需求不一致的准则和纠正规程 ⑥需求跟踪结构、⑦配置管理活动
收集需求
输入:1范围管理计划 2需求管理计划 3干系人管理计划 4项目章程 5干系人登记册
输出: 需求文件(穷尽法) 需求跟踪矩阵
工具与技术:1访谈 2焦点小组 3引导式研讨会 4群体创新技术 5群体决策技术 6问卷调查 7观察 8原型法 9标杆对照 10系统交互图 11文件分析
需求分类
业务需求:实施项目的原因(整个组织的高层级需要)
解决方案需求(功能需求、非功能需求)
干系人需求
过渡需求
项目需求
质量需求:用于确认可交付成果完成的标准1.基本需求2.期望需求3.意外需求
工具与技术
访谈
焦点小组(一对多群体访谈,获得更有价值的集体意见)
引导式研讨会(快速定义跨职能需求,协调干系人差异,做终于形成既定目标的一致意见)
群体创新技术
头脑风暴法BS(各抒己见)
名义小组技术(BS的深化、结构化BS,投票排序)
德尔菲技术:防止个人观点被不正确放大(专家、匿名、多轮、趋同、消除偏见)
概念/思维导图(心智图、脑图,反映共性与差异,激发新创意)
亲和图(KJ图,核心是BS,有助于WBS制订)
多标准决策分析(多种标准、权重、评估、排序)
群体决策技术(一致同意、大多数原则、相对多数原则、独裁)
标杆对照(别人家的孩子,可比组织、内部、外部、识别最佳实践、形成改进意见、为绩效考核提供依据)
问卷调查
观察
原型法(减轻风险、渐进明细、敏捷、故事板)
系统交互图(拓扑图、可视化)
文件分析(分析现有文档)
需求文件
既可以是一份按干系人和优先级分类列出全部需求的简单文件,也可以是一份包括内容提要、细节描述和附件等的详细文件
内容:①业务需求②干系人需求③解决方案需求④项目需求⑤过渡需求 ⑥与需求有关的假设条件、依赖关系和制约因素
需求跟踪
需求管理包括在产品开发过程中维持需求一致性和精确性的所有活动,包括控制需求基线,保持项目计划与需求一致,控制单个需求和需求文档的版本情况,管理需求和联系链之间的联系,或管理单个需求和项目其他可交付物之间的依赖关系,跟踪基线中需求的状态。
可跟踪性:需求跟踪是将单个需求和其他元素之间的依赖关系和逻辑联系建立跟踪,包括各种类型的需求、业务规则、系统组件,以及帮助文件等。
双向可跟踪性
正向跟踪:检查需求文件中的每个需求是否都能在后继工作产品(成果)中找到对应点; (以免需求被做漏、做偏)
反向跟踪:逆向跟踪,检查设计文档、产品构件、测试文档等工作成果是否都能在需求文件中找到出处。(是查需求源头,了解为什么要做这个需求,来源背景和原因是什么)
1.从用户原始需求可向前追溯到需求文件,可区分受变更影响的需求,确保需求文件包括所有用户需求
2.从需求文件回溯到相应的用户原始需求,确认每个需求的出处
3.从需求文件追溯到产品元素,可知每个需求对应的产品元素,从而确保产品元素满足需求
4.产品元素回溯到需求文件,使项目团队成员知道产品元素存在的原因 (如无法回溯到需求文件,则可能是镀金;如果孤立的产品元素是一个正当功能,则可能是需求遗漏)
5.需求文件之间的跟踪,便于更好地处理各种需求之间的逻辑相关性,检查需求分解中可能出现的错误或遗漏
需求跟踪矩阵
表示需求和其他产品元素之间的联系链的最普遍方式是使用需求跟踪(能力)矩阵,需求跟踪矩阵是将产品需求从其来源连接到能满足需求的可交付成果的一种表格。
需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态(例如,进行中、已取消、已推迟、新增加、已批准、已分配、己完成等)和状态日期。
定义范围
输入:1范围管理计划 2项目章程 3需求文件 4组织过程资产
工具与技术:1专家判断 2产品分析 3备选方案生成 4引导式研讨会
输出:1项目范围说明书 2项目文件更新
项目范围说明书
内容
①产品范围描述(逐步细化在项目章程和需求文件中所描述的产品、服务或成果的特征) ②验收标准(定义可交付成果通过验收前必须满足的一系列条件,以及验收的过程) ③可交付成果 ④项目的除外责任(需识别出什么是被排除在项目之外的。明确说明哪些内容不属于项目范围,有助于管理干系人的期望) ⑤制约因素 ⑥假设条件
作用:①确定范围、②沟通基础、③规划和控制依据、④变更基础、⑤规划基础
创建WBS
输入:1范围管理计划 2项目范围说明书 3需求文件 4事业环境因数 5组织过程资产
工具与技术:1分解 2专家判断
输出:1范围基准 2项目文件更新
WBS层次
里程牌
里程碑标志着某个可交付成果或者阶段的正式完成。重要的检查点是里程碑、重要的里程碑是基线
工作包
工作包应便于完整地分派给不同的人或组织单元,所以要求明确各工作单元直接的界面。工作包应非常具体,以便承担者能明确自己的任务、努力的目标和承担的责任。8/80规则(80小时原则)建议工作包的大小应该至少需要8小时来完成,而总完成时间也不应该大于80小时
控制账户
一种管理控制点。在该控制点上,将范围、预算(资源计划)、实际成本和进度加以整合,并将它们与挣值进行比较,以测量绩效。 控制账户是WBS某个层次上的要素,既可以是工作包,也可以是比工作包更高层次上的一个要素。
规划户
在控制账户之下,工作内容已知但尚缺详细进度活动的WBS组成部分。规划包是在控制账户之下、工作包之上的WBS要素。 规划包是暂时用来做计划的,随着情况的逐渐清晰,规划包最终将被分解成工作包以及相应的具体活动。
WBS词典
也称WBS词汇表,描述WBS各组成部分的文件。对于WBS的每一组成部分,包括账户编码标识、工作描述、假设条件和制约因素、负责人或组织单元、进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献、协议信息等。(WBS字典实际是相当于新华字典,是对WBS中每个元素的描述)
范围基准
项目范围说明书--是对项目范围、主要可交付成果、假设条件和制约因素的描述。记录了整个范围, 包括项目和产品范围。
WBS--全部工作范围的层级分解(有助于防止范围蔓延)
WBS词典--针对每个WBS组件,详细描述可交付成果、活动和进度信息的文件(有助于评价变更的影响)
WBS分解
分解需开展活动
①识别和分析可交付成果及相关工作。
②确定WBS的结构和编排方法。
③自上而下逐层细化分解。
④为WBS组件制定和分配标识编码。
⑤核实可交付成果分解的程度是恰当的
应该由全体项目团队成员、用户和项目干系人共同完成和一致确认。
WBS划分原则
①功能或者技术原则:在创建WBS时,需要考虑将不同人员的工作分开。
②组织结构:对于职能型的项目组织而言,WBS也要适应项目的组织结构形式
③系统或者子系统:总的系统划分为几个主要的子系统,然后对每个子系统再进行分解。
WBS分解方法
①项目生命周期的各阶段作为分解的第二层,产品和项目可交付成果放在第三层
②主要可交付成果作为分解的第二层
③整合可能由项目团队以外的组织来实施的各种组件(例如,外包工作),然后作为外包工作的一部分,卖方需编制相应的合同WBS。
WBS表示形式
树型结构(组织结构图式):WBS层次清晰、直观性和结构性强,但不容易修改,对大的、复杂的项目很难表示出项目的全貌(小项目)。
表格形式(列表式):表格形式的直观性比较差,但能够反映出项目所有的工作要素(大项目)。
WBS分解注意8个方面
①WBS必须是面向可交付成果的:所有下一级的元素之和必须100%的代表上一级元素。
②WBS必须符合项目的范围。WBS必须包括,也仅包括为了完成项目的可交付成果的活动
③WBS的底层应该支持计划和控制。WBS是项目管理计划和项目范围之间的桥梁,WBS的底层不但要支持项目管理计划,而且要让管理层能够监视和控制项目的进度和预算。
④WBS中的元素必须有人负责,而且只由一个人负责,尽管实际上可能需要多个人参与。
⑤WBS的指导,WBS应控制在4〜6层。当然,大项目可以超过6层。
⑥WBS应包括项目管理工作(因为管理是项目具体工作的一部分),也要包括分包出去的工作。
⑦WBS的编制需要所有(主要)项目干系人的参与,需要项目团队成员的参与。
⑧WBS并非是一成不变的。在完成了WBS之后的工作中,仍然有可能需要对WBS进行修改。
确认范围
输入:1项目管理计划 2需求文件 3需求跟踪矩阵 4核实的可交付成果 5工作绩效数据
工具与技术:1检查 2群体决策技术
输出:1验收的可交付成果 2变更请求 3工作绩效信息 4项目文件更新
正式验收项目已完成的可交付成果的过程 贯穿项目始终 客户或发起人一起审查可交付成果
确认范围的步骤:①确定需要进行范围确认的时间、②识别范围确认需要哪些投入、③确定范围正式被接受的标准和要素、④确定范围确认会议的组织步骤、⑤组织范围确认会议。
关注点不同:
管理层:关注项目范围,指范围对项目的进度、资金和资源的影响,这些因素是否超过了组织承受范围,是否在投入产出上具有合理性。【企业管理层不会关心太细节的东西。只需要关心投入产出的合理性】
客户:关心产品的范围,关心项目的可交付成果是否足够完成产品或服务
项目管理人员:关注可交付成果是否足够和必须完成,时间、资金和资源是否足够,主要的潜在风险和预备解决的方法。
项目团队成员:关心项目范围中自己参与的元素和负责的元素
核实产品:针对产品是否完成,在项目(或阶段)结束时由发起人或客户来验证,强调产品是否完整; 确认范围:针对项目可交付成果,由客户或发起人在阶段末确认验收的过程。
确认范围与项目收尾的不同:
①虽然确认范围与项目收尾工作都在阶段未进行,但确认范围强调的是核实与接受可交付成果,而项目收尾强调的是结束项目(或阶段)所要做的流程性工作。
②确认范围与项目收尾都有验收工作,确认范围强调验收项目可交付成果,项目收尾强调验收产品。
确认范围与质量控制的不同:
①确认范围主要强调可交付成果获得客户或发起人的接受;质量控制强调可交付成果的正确性,并符合为其制定的具体质量要求(质量标准)。
②质量控制一般在确认范围前进行,也可同时进行;确认范围一般在阶段末尾进行,而质量控制并不一定在阶段未进行。
③质量控制属内部检查,由执行组织的相应质量部门实施;确认范围则是由外部干系人(客户或发起人)对项目可交付成果进行检查验收。
控制范围
输入:1项目管理计划 2需求文件 3需求跟踪矩阵 4工作绩效数据 5组织过程资产
工具与技术:偏差分析
输出:1工作绩效信息 2变更请求 3项目管理计划更新 4项目文件更新 5组织过程资产更新
监督项目和产品的范围状态、管理范围基准变更的过程,其主要作用是在整个项目期间保持对范围基准的维护。对项目范围进行控制,就必须确保所有请求的变更、推荐的纠正措施或预防措施都经过实施整体变更控制过程的处理。在变更实际发生时,也要采用范围控制过程来管理这些变更。
①影响导致范围变更的因素,并尽量使这些因素向有利的方面发展。
②判断范围变更是否已经发生。
③范围变更发生时管理实际的变更,确保所有被请求的变更按照项目整体变更控制过程处理
补充
1)在层次上保持项目的完整性,避免遗漏必要的组成部分。
2)—个工作单元只能从属于某个上层单元,避免交叉从属。
3)相同层次的工作单元应用相同性质。
4)工作单元应能分开不同的责任者和不同的工作内容。
5)便于项目管理计划和项目控制的需要。
6)最底层工作应该具有可比性,是可管理的,可定量检查的。
7)应包括项目管理工作,包括分包出去的工作。