企业网站的短视频中心模板,站长工具域名解析,dede5.7网站搬家,网站内容包括哪些项目范围管理包括确保项目“做”且“只做”所需的全部工作#xff08;即不能少做#xff0c;也不能多做#xff0c;如果多做#xff0c;就要消耗团队额外的时间和资源#xff0c;并且无法被认可#xff09;#xff0c;以成功完成项目。项目范围管理主要在于定义和控制哪… 项目范围管理包括确保项目“做”且“只做”所需的全部工作即不能少做也不能多做如果多做就要消耗团队额外的时间和资源并且无法被认可以成功完成项目。项目范围管理主要在于定义和控制哪些工作应该包括在项目内哪些不应该包括在项目内。 范围管理过程确保了项目团队和项目相关方就项目的可交付成果以及形成这些可交付成果所进行的工作达成共识。 范围包括产品范围和项目范围 产品范围某项产品、服务 或 成果所具有的特性和功能。项目范围为交付具有规定特性与功能的产品、服务 或 成果而必须完成的工作。 在交付产品的项目中项目范围包括产品范围。 目录
一、项目范围管理输入、输出、技术和工具
1.1 规划范围管理
1.2 收集需求
1.3 定义范围
1.4 创建WBS
1.5 确认范围
1.6 控制范围
1.7 管理新实战
1.8 裁剪考虑因素
1.9 敏捷与适应方法
二、规划范围管理
2.1 作用
2.2 范围管理计划
2.3 需求管理计划
2.4 需求管理计划和范围管理计划
2.5 验收文件
三、收集需求
3.1 作用
3.2 需求、可交付成果与项目目标的映射关系
3.3 工具与技术
3.4 需求管理过程
3.4.1 亲和图
3.4.2 思维导图
3.5 需求决策
3.6 需求文件 3.7 需求跟踪矩阵
3.8 敏捷场景下的需求管理
3.8.1 产品属性
3.8.2 精益画布
3.8.3 最小可发布版本
3.8.4 产品待办事项列表
3.8.5 分解和细化产品待办事项列表中的条目
3.8.6 用户故事
四、定义范围
4.1 作用
4.2 项目范围说明书
五、创建WBS
5.1 作用
5.2 分解的基本概念
5.3 分解步骤
5.4 WBS元素
5.5 WBS字典
5.6 控制账户
5.7 规划包
5.8 工作包的分解原则
5.9 范围基准
5.10 WBS的价值
六、确认范围
6.1 作用
6.2 确认范围的步骤
6.3 需要检查的问题
6.4 干系人关注点的不同
6.5 可交付成果的演变
6.6 质量控制和范围确认
6.7 其它知识点
七、控制范围
7.1 作用
7.2 范围蔓延 一、项目范围管理输入、输出、技术和工具
概念核心思想规划范围管理指南和方向为了记录如何定义、确认和控制项目范围及产品范围创建范围管理计划。收集需求甲方你要啥 易混淆。 收集需求为了实现项目目标确定、记录并管理干系人的需要和需要。 定义范围制定项目和产品详细描述。 定义范围乙方我干啥创建WBS细一点将项目可交付成果和项目工作分解为较小的、更易于管理的组件。确认范围甲方你签字 易混淆。 确认范围正式验收已完成的项目可交付成果。 控制范围监督项目和产品的范围状态管理范围基准的变更。 控制范围做且只做 1.1 规划范围管理 在整个项目期间对如何管理范围提供指南和方向。本过程仅开展一次或公在项目的预定义点开展。 1.2 收集需求 为定义产品范围和项目范围奠定基础。本过程仅开展一次或仅在项目的预定义点开展。 1.3 定义范围 描述产品、服务 或 成果的边界和验收标准。本过程需要在整个项目期间多次反复开展。 1.4 创建WBS 为所要交付的内容提供架构。本过程仅开展一次或仅在项目预定义点开展。 1.5 确认范围 使验收过程具有客观性通过确认每个可交付成果来提高最终产品、服务 或 成果获得验收的可能性。 1.6 控制范围 在整个项目期间保持对范围基准的维护。 高清链接项目范围管理输入、输出、技术和工具 密码:X0V8
1.7 管理新实战 需求一直是项目管理的关注重点。项目范围管理的新趋势和新兴实战更加注重与商业分析师一起合作以便 确定问题并识别商业需要识别并推荐能够满足需要的可行解决方案收集、记录并管理干系人需求满足商业和项目目标推荐项目集或项目产品、服务或最终成果功能应用。 商业分析师的职责还应包括需求管理相关的活动项目经理则负责确保这些活动列入项目管理计划并且在预算内按时完成同时能够创造价值。 项目经理与商业分析师之间应该是伙伴合作关系。 1.8 裁剪考虑因素 对项目范围管理过程裁剪时应该考虑的因素 知识和需求管理项目经理应该建立哪些指南为了未来项目中重复使用需求组织是否拥有正式或非正式的知识和需求管理体系确认和控制组织是否采用敏捷方法管理项目开发方法属于迭代型还是增量型是否采用预测型方法混合型方法是否有效需求的稳定性项目中是否存在需求不稳定的领域是否有必要采用精益、敏捷或其他适应弄技术来处理不稳定的需求直到需求稳定且定义明确治理组织是否拥有正式或非正式的审计和治理政策、程序和指南 1.9 敏捷与适应方法 对于需求不断变化、风险在或不确定性高的项目在项目开始时通常无法明确项目的范围而需要在项目期间逐渐明确。敏捷或适应型方法特意在项目早期缩短定义和协商范围的时间为后续细化范围、明确范围争取更多的时间。 采用敏捷或适用型生命周期旨在应对大量变更需要干系人持续参与项目。 采用多次迭代重复开展三个过程收集需求、定义范围 和 创建WBS。发起人和客户代表应该持续参与项目重复开展两个过程确认范围 和 控制范围。 二、规划范围管理 项目范围管理包括确保项目做且只做所需的全部工作以成功完成项目。项目范围管理主要在于定义和控制哪些工作应该包括在项目内哪些不应该包括在项目内。
2.1 作用 本过程的主要作用是在整个项目期间对如何管理范围提供指南和方向。 本过程仅开展一次或仅在项目的预定义点开展。 2.2 范围管理计划 范围管理计划是项目管理计划的组成部分描述将如何定义、制定、监督、控制和确认项目范围。可以是正式或非正式的非常详细或高度概括的。 主要内容包括 1. 如何制定项目范围说明书 2. 如何根据详细项目范围说明书创建WBS 3. 确定如何审批和维护范围基准 4. 如何正式验收已完成的项目可交付成果。 主要解决以下问题 1. 范围说明书的定义以及WBS和WBS词典的格式、流程。 2. 范围基准的生成和审批程序。 3. 范围变更管理的规则和程序。 4. 可交付成果的验收标准和流程。 2.3 需求管理计划 需求管理计划是项目管理计划的组成部分描述如何分析、记录和管理需求。主要内容包括 1. 如何规划、跟踪和报告各种需求活动 2. 配置管理活动 3. 需求优先级排序过程 4. 测量指标及使用这些指标的理由 5. 反映哪些需求属性将被列入跟踪矩阵。 2.4 需求管理计划和范围管理计划
RequirementsScopes需求管理计划范围管理计划 规划、跟踪和报告需求配置管理活动确定需求优先级排序确定产品测量指标跟踪矩阵的跟踪结构 制定详细的范围说明书创建WBS和WBS词典创建责任分配矩阵正式验收可交付成果处理对项目范围的变更 项目范围来源于需求但是需求管理计划的目地是记录、跟踪和管理需求所有需求只要被提出就应该被有效管理无论这个需求是否被满足。需求管理计划要定义需求识别、记录、跟踪、报告、变更、排优先级等计划的规则和方法。 范围管理计划就是我们应该如何管理好我们必须做的工作。例如如何清晰的表述工作范围如何明确分工如何管理变更如何验收确认。 2.5 验收文件 由客户提供经过客户确认签字的正式文件用于对项目可交付成果的验收。
三、收集需求 需求具有多样性、复杂性、隐蔽性、差异性、变化性 和 矛盾性的特性。
3.1 作用 本过程的主要应用是为定义产品范围和项目范围奠定基础。 本过程公开展一次或仅在项目的预定义点开展。 3.2 需求、可交付成果与项目目标的映射关系 1. 并不是所有需求都需要项目组去满足。 2. 需求是否被批准最终由发起人决定。 3. 被批准的需求需要同可交付成果及项目目标之间建立逻辑联系。 3.3 工具与技术 头脑风暴 Brainstorming一种用来生产和收集项目需求和产品需求的多种创意的技术通过团队成员集思广益、畅所欲言、互相启发来实现。但是头脑风暴会受与会人员的知识经验所限。 访谈 Interview访谈有经验的项目参与者、发起人、其他高管以及主题专家有助于识别和定义可交付的产品特征和功能。 焦点小组 Focus Group是召集预定的干系人和主题专家了解他们对所讨论的产品、服务或成果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论。焦点小组往往比“一对一”的访谈更热烈。 问卷调查 Questionnaire适用于以下几种情况受众多样化需要快速完成调查受访者地理位置分散适合开展统计分析。问卷设计应紧密围绕调查目的而向调查对象坚持人性化并优先选经广泛认可的标准量表。 标杆对照 Benchmarking 将实际或计划的产品、过程和实践与其他可比组织的实战进行比较以便识别最佳实践形成改进意见并为绩效考核提供依据。标杆对照所采用的可比组织可是内部的也可以是外部的。 原型法 Prototyping 指在实际制造预期产品之前选造出该产品的模型并据此征求对需求的早期反馈。原型包括微缩产品、计算机生成的二维和三维模型、实体模型或模拟。因为原型是有形的被我它使得干系人呆以体验最终产品的模型而不是仅限于讨论抽象的需求描述。原型法支持渐进明细的理念需要经历从模型创建、用户体验、反馈收集到原型修改的反复循环过程。在经过足够的反馈之后就可以通过原型获得足够的需求信息从而进入设计或制造阶段。 故事板是一种原型技术通过一系列的图像或图示来展示顺序或导航路径。故事板用于各种行业的各种项目中如电影、广告、教学设计以及敏捷和其他软件开发项目。在软件开发中故事板使用实体模型来展示网页、屏幕或其他用户界面的导航路径。 名义小组技术 Nominal group technique 用于促进头脑风暴的一种技术通过投票排列最有用的创意以便进一步开展头脑风暴或优先排序。名义小组是一种结构化的头脑风暴形式。其步骤包括以下四步 向集体提出一个问题或难题每个人在沉思后写出自己的想法主持人在活动挂图上记录所有人的想法集体讨论各个想法直到全体成员达成一个明确的共识个人私下投票决出各种想法的优先排序通常采用5分制1分最低5分最高。 为了减少想法数量、集中关注想法可进行数轮投票。每轮投票后都将清点选票得分最高者被选出。 联合应用程序开发或设计 JAD适用于软件开发行业。客户被邀请和开发团队一起通过二系列的研讨会收集需求和改进软件开发的过程。客户持续参与有利于客户充分了解项目并及时给出反馈也有利于团队更深入理解客户的真实需求。 质量功能展开 QFD这个工具在新产品研发项目中很常用可以把用户需求转化成产品功能以便开发出最符合用户需求的产品功能。质量功能展开通常分为以下四个步骤 第一步产品规划矩阵把用户需求转化为设计要求。第二步零件规划矩阵把设计要求转化为零件特性。第三步工艺规划矩阵把零件特性转化为工艺要求。第四步工艺/质量规划矩阵把工艺要求转化为生产要求。 3.4 需求管理过程 需求管理中数据表现的工具有亲和图、思维导图。
3.4.1 亲和图 亲和图法被称为KJ法。通过头脑风暴法把收到的事实、意见和设想等语言文字资料根据资料间的亲和性将其归类以便从复杂现象中找出规律、抓住本质、理出思路的一种方法。 再经过分享、讨论、投票待方式根据需求间的亲和性将其照着形成若干组需求。 3.4.2 思维导图 表达发散性思维的有效图形思维工具即运用图文并重的技巧把各级主题的关系用相互隶属与相互关联的层级图表现出来并把主题关键词与图像、颜色等建立记忆连接。 3.5 需求决策 当需求众多需要做出取舍或者需要结合多人的意见做出决策时通常采用以下决策技术 投票在进行投票之前要先确定投票的原则。 一致同意原则只有所有人同意方案才能通过。该方案也叫“一票否决制”。大多数同意原则只要获取通过半数或超过2/3 的得票方案即可通过。相对多数同意原则多个方案中得票最多的胜出不管得票是否超过半数。 独裁这种决策技术是由一个人做出最终决定必要时可起到高效决策的作用。 多标准决策分析在相互冲突的多方案中进行选择就是根据准则层的各项准则分别给方案层的各个方案打分然后汇总分数总分最高的方案胜出成为目标方案。 3.6 需求文件
类别定义1 业务需求整个组织的高层级需要。例如解决业务问题或抓住业务机会以及实施项目的原因。2 干系人需求干系人的需要。3 解决方案需求 为满足业务需求和干系人需求产品、服务或成果必须具备的特性、功能和特征。 解决方案需求又进一步分为功能需求和非功能需求 功能需求。功能需求描述产品应具备的功能例如产品应该执行的行动、流程、数据和交互。非功能需求。非功能需求是对功能需求的补充是产品正常运行所需的环境条件或质量要求例如可靠性、保密性、性能、安全性、服务水平、可支持性、保留或清除等。4 过渡和就绪需求描述了从“当前状态”过渡到“将来状态”所需的临时能力。如数据转换和培训需求。5 项目需求项目需要满足的行动、过程和其他条件。例如里程碑日历、合同责任、抽纸因素等。6 质量需求用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准。 3.7 需求跟踪矩阵 需求跟踪矩阵是把产品需求从来源连接到能满足需求的可交付成果的一种表格。使用需求跟踪矩阵把每个需求与业务目标或项目联系起来有助于确保每个需求都具有商业价值。需求跟踪矩阵提供了整个项目生命周期中跟踪需求的一种方法有助于确保需求文件中被批准的每项需求在项目结束的时候都能交付。 需求跟踪的内容包括但不限于 业务需要、机会、目的和目标项目目标项目范围和WBS可交付成果产品设计产品开发测试策略和测试场景高层级需求到详细需求。 需求跟踪矩阵中记录了需求的相关属性这些属性有助于明确每个需求的关键信息。需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级、版本、当前状态如进行中、已取消、已推迟、新增加、已批准、被分配和已完成和状态日期。为确保相关方满意可能需要增加一些补充属性如稳定性、复杂性 和 验收标准。需求跟踪矩阵示例如下列有相关需求属性
需求跟踪矩阵项目名称成本中心项目描述标识关联标识需求描述业务需要、机会、目的和目标项目目标WBS可交付成果产品设计产品开发测试案例0011.02.0
3.8 敏捷场景下的需求管理
3.8.1 产品属性 卡诺属性也叫“狩野模型”将产品属性分为五类如下图所求 魅力属性 Attractive让用户喜出望外的属性。即使产品不具备该属性用户的满意度也不会降低而如果产品具备该属性用户的满意度会大幅提升。例如对大都数用户而言手机的无线充电功能屏幕可折叠待功能并不是非有不可不过假如手机有这些炫酷的功能用户还是很开心的。期望属性 One-Dimensional也叫线性属性客户满意度与产品的属性呈线性关系。例如手机待机时间越长、手机的屏占比越大用户越满意。无差异属性 Indifference让用户不敏感的属性。无论产品具备还是不具备用户的满意度都不会改变。例如手机的线路板是几层的绝大都数据用户并不关心。必备属性 Must-Be用户对产品的基本需求。如果产品不具备用户满意度就会大幅度降低甚至无法接受。反向属性 Reverse用户根本没有此类需求。产品所具备的该类属性越多用户就越不满意。例如手机里预装的软件越多就越让用户讨厌。
3.8.2 精益画布 当企业有了一个很美妙的想法时很多企业会按照流程要求编制内容翔实的商业计划书、可行性研究报告。长达几十页甚至上百页的报告往往要花几周甚至几个月的时间。而在精益创业模式中使用一张精益画布就可以解决这个问题。 精益画布是从商业模式画布中发展而来的如上图包含9个部分如下图所示老人打车精益画布 2 用户痛点 因为老人不会用智能手机所以打不到车支付车费不方便 3 解决方案 99**一呼即到AI语音识别算法智能定位 4 价值主张 用司机手机刷脸支付儿女绑定手机app监控路线 9 竞争壁垒 专注老人市场 1 用户细分 不会用智能机的老人残障人士带电话手表的学生 8 关键指标 服务单量 500司机注册 20用户活跃度 20% 5 市场渠道 社区、街道、公益组织政府、媒体、儿女推荐等 7 成本结构 平台开发 1000营销推广 2000运营成本 3000合计6000 6 收入来源 平台提成 1000政府补贴 2000合作分润 3000合计6000
3.8.3 最小可发布版本 产品开发经历漫长的过程。对于创新产品来说如果企业没有发布过一个版本就没法验证这款产品到底有没有真正的客户。 虽然在商业论证阶段产品创意已经通过最小可行性产品Minimum Viable Product, MVP被验证过了但MVP和真正的产品不同MVP是验证假设的试验品而MMR是真正的可以被客户购买的产品。企业没生产出真正的产品只是用MVP验证出客户的“购买意愿”并不代表客户见了产品后会真的购买。 团队需要从产品待办事项列表中精挑细选出最有价值的特性并做出一个成本最小的产品迅速投放到市场上。 MMR原则如下 最简特性清单依据精益画布放弃不属于核心价值主张的特性 依据卡诺模型舍弃产品非必需的特性。团队针对每个特性都要问自己没有它会怎么样如果没有它并不影响用户使用那么它就不应该出现。最小特性颗粒尽力把产品特性拆分出子特性一直拆分到不能拆分为止如果继续拆分就无法为用户提供独立的价值。最少特性组合根据莫斯科法则MoSCoW把梳理出来的特性清单进一步排优先级只开发最基本的特性也就是产品必须有的特性。 莫斯科法则MoSCoW如下 必须有的特性如果没有产品不可行。应该有的特性非常重要但不是必需的特性可以想其他方法替代或暂时不提供。可以有的特性有了更好没有也行。只有在时间允许资源充裕的情况下企业才会考虑。不该有的特性不关键、不必要且不该在这个版本里考虑的特性。 3.8.4 产品待办事项列表 产品待办事项列表的特征如下。 详图适当优先级越高的待办事项其描述越详细 反之描述越简略。经过估算产中待办事项列表中的条目是经过估算的这些估算是粗颗粒度的通常以故事点或者理想人天的形式表达。涌现的产中待办事项列表中的条目是动态的不断演化的。根据客户和用户的反馈随时增减和调整待办事项列表优先级并且现有的条目可以不断被修订、细化甚至移除。按优先级排序最重要的事项优先级最高排在产品待办事项列表的最项层最先被实施。 3.8.5 分解和细化产品待办事项列表中的条目 如下图所示在下一次迭代开始之前虽然产品负责人应当准备好足够多的细颗粒条目但不必把所有条目都分解细化这样做的目的是把花费在描述产品上的时间和资源降到最低。因为条目是动态的变化的所以分解和细化条目的工作也是周期性的。 如果产品待办事项列表中有同样重要的活动那么团队应该先做哪个呢 我们可以采取WSJF原则即“最短作业优先”原则。公式“WSJF 延期满足的代价 / 这项活动的历时估算” 计算每项活动WSJF 的分数分数最高的活动就是我们应该优先做的。
3.8.6 用户故事 用户故事是一个表述用户需求的固定语法作为一个角色我想要活动以便于商业价值。 通常团队在识别用户需求时会用便利贴按照上述语法把用户的需求表达出来用于看板或产品待办事项列表分析。 四、定义范围 定义范围是制定项目和产品详细描述的过程。这个过程主要作用是明确所收集的需求哪些将包含在项目范围内哪些将排队在项目范围外从而明确项目、服务或成果的边界。 完整、准确地定义aifl通常是项目成功的前提。范围说明书是定义范围过程的最重要的成果。
4.1 作用 本过程的主要作用是描述产品、服务或成果的边界和验收标准。 本过程需要的整个项目期间多次反复开展。 4.2 项目范围说明书 项目范围说明是对项目范围、主要可交付成果、假设条件和制约因素的描述。项目范围说明书详细描述了项目的可交付成果以及团队为创建这些可交付成果而必须开展的的工作也代表了项目相关方之间就项目范围所达成的共识。 项目范围说明书是对项目范围、主要可交付成果、假设条件和抽纸因素的描述 1. 产品范围描述逐步细化在项目章程和需求文件中所述的产品、服务或成果特征。 2. 可交付成果为完成某一过程、阶段或项目而必须产出的任何独特并可核实的产品、服务能力或成果可交付成果也包括辅助成果如项目管理报告和文件。对可交付成果的描述可略可详。 3. 验收标准可交付成果通过验收前必须满足的一系列条件。 4. 项目除外责任识别排除在项目之外的内容。明确说明哪些内容不属于项目范围有助于管理干系人的期望及减少范围蔓延。 5. 制约因素对项目或过程的执行有影响的限制性因素。列举并描述与项目范围有关且会影响项目执行的各种内外部制约或限制条件如客户或执行组织事先确定的预算、强制性日期或进度里程碑。如果项目是根据协议实施的那么合同条款通常也是制约因素。关于制约因素的信息可以列入项目范围说明书也可以独立成册。 6. 假设条件在制订计划时不需要验证假设条件即可将其视为正确、真实或确定的因素。同时还应描述如果这些因素不成立可能造成的潜在影响。在项目规划过程中项目团队应该经常识别、记录并确认假设条件。假设条件的信息可以被列入项目范围说明书也可以独立成册。 虽然项目章程和项目范围说明书的内容存在一定程度的重叠但它们的详细程度完全不同。项目章程包括高层级的信息对项目范围的初步表述除方向的重大变更外一般项目章程一经制定就不能频繁地理性项目范围的表述而项目范围说明书则是对范围组成部分的详细描述这些组成部分需要在项目过程中渐进明细项目章程是项目范围说明书制定的重要依据而项目范围说明书需要随项目的发展动态更新维护渐进明细。就项目范围而言项目范围说明书是对项目章程的细化和具体化。
五、创建WBS 创建工作分解结构WBS是把项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程。
5.1 作用 本过程的主要作用是为所要交付的内容提供架构。 本过程仅开展一次或仅在项目的预定义点开展。 5.2 分解的基本概念 简单来说分解就是把一个项目按一定的原则分解项目分解成任务任务再分解成一项项工作再把一项项工作分配到每个人的日常活动中直到分解不下去为止。 分解是一种把范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术。 工作包是WBS最低层的工作可对其成本和持续时间进行估算和管理。分解的程度取决于所需的控制程序以实现对项目的高效管理。 工作包的详细程度因项目规模与复杂度而异。 5.3 分解步骤 识别和分析可交付成果及相关工作确定WBS的结构与编排方法自上而下逐层细化分解为WBS组成部分制定和分配标识编码核实可交付成果分解的程度是否失当 5.4 WBS元素 WBS包含如下几种元素。 1. 可交付成果 可交付成果是团队为完成某一过程、阶段或项目而必须产出的任何独特并可核实的产品、成果或服务能力其包括各种辅助成果如项目管理报告和文件。可交付成果的描述可略可详。 2. 子项目 子项目是整个项目的一部分。一个子项目是能够被相对独立地作为“项目”来管理的可由一个专业团队或一个分包组织负责。 3. 控制账户 控制账户是一个管理控制点。在该控制点上把范围、预算、实际成本和进度加以整合并与挣值相比较以测量绩效。 4. 工作包 工作包是WBS中最低层次的组件通常表达为可交付成果。工作包可以对相关活动进行归类以便对工作进度进行估算开展监督与控制。 5. 规划包 规划包也是WBS的最低层次的组件位于控制账户之下。它的工作范围是已知的但所包含的活动或对应的工期和预算是当前未知的需要随项目的深入进一步确定。 6. 活动 活动是工作包的组成部分不属于WBS组件。活动描述中包含一个表示其动作的动词如“开发微信支付接口”。一个活动通常有期望持续时间、期望成本、期望资源需求。活动经常被细分为任务。 7. 任务 任务通常是活动进一步分解的组成部分不属于WBS组件由某个团队成员负责。 WBS分解的100%原则一个WBS元素的下一层分解子层必须百分之百地表示上一层父层元素的工作不能有重复更不能有遗漏。
5.4 WBS结构 将项目生命周期的各阶段作为分解的第二层把产品和项目可交付成果放第三层。 主要可交付成果作为分解的第二层 分解的两种表现形式 分组的树形结构小型项目特点WBS层次清晰非常直观结构性很强。 5.5 WBS字典
WBS编码缩写描述标准历时费用负责人依赖1.1.1.0EA这个元素包含可交付成果的培训服务、手册复检培训帮助和培训设备用来指导客户最大效率地学习怎样操作和维护系统。CS133M 50K李四系统部署完成 WBS字典是针对WBS中每个组件详细描述可交付成果、活动和进度信息的文件。 WBS字典对WBS组成部分包括工作包和控制账户进行更详细的描述。 WBS字典中的内容可能包括但不限于 账户编码标识工作描述假设条件和制约因素负责的组织进度里程碑相关的进度活动所需资源成本估算质量要求验收标准技术参考文献协议信息 5.6 控制账户 控制账户是一个管理控制点。在该控制点上把范围、预算和进度加上整合并与挣值相比较来测量绩效。控制账户包含两个或更多工作包每个工作包只与一个控制账户关联。项目管理实践中通常控制账户和专业相对应。 5.7 规划包 规划包是一种低于控制账户而高于工作包的工作分解结构组件工作内容已知但详细的进度活动未知。一个控制账户可以包含一个或多个规划包。由于当前无法分解到编制项目管理计划所需要的详细程度规划包是暂时用来做计划的。随着情况的逐渐清晰规划包最终被分解成工作包以及相应的具体活动。 5.8 工作包的分解原则 WBS必须是面向可交付成果的。WBS必须符合项目的范围。100%原则WBS的底层应该支持计划和控制。WBS中的元素必须有人负责而且只有一个人负责。WBS控制在46层如果项目规模比较大以至于WBS要超过6层此时可以使用项目分解结构将大项目分解成子项目然后针对子项目来做WBS。WBS应包括项目管理工作也要包括分包出去的工作。WBS的编制需要所有主要项目干系人的参与。WBS并非是一成不变的。 5.9 范围基准 5.10 WBS的价值 WBS的价值体现在以下五个方面。 1. 基准的来源 范围基准是三大基准之首。有了范围我们才能确定进度基准和成本基准。 2. 计划的基础 项目进度、成本、质量、风险等所有计划都要依据基准来编制。 3. 工作的展现 WBS把项目所涵盖的工作分层次、结构化地展现出来。 4. 控制的依据 该项工作是否应该做要对照范围基准如果范围基准里没有就不应该做。 5. 团队的指南 团队根据WBS来确定工作的目标和分工。 六、确认范围 确认范围是获得项目发起人或客户对项目可交付成果正式验收的过程。通过项目过程中发起人或客户持续性地验收每个可交付成果可以保障最终产品、服务或成果获得验收。
6.1 作用 使验收过程是有客观性。通过确认每个可交付成果来提高最终产品、服务或成果获得验收的可能性。 确认范围过程应该根据需要在整个项目期间开展。 由主要干系人尤其是客户或发起人审查从控制质量过程输出的核实的可交付成果确认这些可交付成果已圆满完成并通过正式验收。
6.2 确认范围的步骤 确定需要进行范围确认的时间识别范围确认需要哪些投入确定范围正式被接受的标准和要素确定范围确认会议的组织步骤组织范围确认会议。 6.3 需要检查的问题 项目干系人进行范围确认时要检查的内容 可交付成果是否确定的、可确认的。每具可交付成果是否有明确的里程碑里程碑是否有明确的、可辨别的事件例如客户的书面认可等。是否有明确的质量标准。审核和承诺是否有清晰的表达。项目范围是否覆盖了需要完成的产品或服务的所有活动有没有遗漏或错误。项目范围的风险是否太高管理层是否能够降低风险发生时对项目的影响。 6.4 干系人关注点的不同 管理层主要关注项目范围是指范围对项目的进度、资金和资源的影响这些因素是否超过了组织承受范围是否在投入产出上具有合理性。客户主要关注产品范围关心项目的可交付成果是否足够完成产品或服务。项目管理人员主要关注项目制约的因素关心项目可交付成果是否足够和必须完成时间、资金和资源是否足够主要的潜在风险和预备解决的方法。项目团队成员主要关注项目范围中自己参与的元素和负责的元素通过定义范围中的时间检查自己的工作时间是否足够自己的项目范围中是否有多项工作而这些工作是否有冲突的地方。 6.5 可交付成果的演变 可交付成果指导与管理项目工作控制质量核实的可交付成果确认范围验收的可交付成果结束项目或阶段最终的产品、成果或服务 6.6 质量控制和范围确认 确认范围关注可交付成果的验收。 控制质量关注可交付成果的正确性及是否满足质量要求。 控制质量过程通常先于确认范围过程但二者也可同时进行。 6.7 其它知识点 核实的可交付成果指已经完成并被控制质量过程检查为正确的可交付成果。 验收的可交付成果由客户或发起人正式签字批准。应该从客户或发起人那里获得正式文件证明干系人对项目可交付成果的正式验收。这些文件将提交给结束项目或阶段过程。 七、控制范围 控制范围是监督项目和产品的范围状态管理范围基准变更的过程。
7.1 作用 在整个项目期间保持对范围基准的维护并确保所有变更请求、纠正措施或预防措施都通过实施整体变更控制程序进行处理。 本过程需要在整个项目期间开展。 7.2 范围蔓延 未经控制的产品或项目范围的扩大未对时间、成本和资源做相应调整被称为范围蔓延。 狭义的范围蔓延在客户要求下未经正常的范围变更控制程序而出现的产品或项目范围的扩大也叫“范围爬行”。镀金广义范围蔓延的一种指在定义范围的工作范围以外项目团队主动增加的额外工作但没有经过范围控制程序。 不管镀金还是范围爬行共同点者是没有经过整体变更控制程序而发生了范围变化。统称“范围蔓延”。
