项目管理-项目范围管理(课件).ppt

《项目管理-项目范围管理(课件).ppt》由会员分享，可在线阅读，更多相关《项目管理-项目范围管理(课件).ppt（37页珍藏版）》请在三一文库上搜索。

1、 经过自己多年的努力，在市区的繁华地段购买了一套不错 的三居室房子；为了尽快入住，你准备将房子的装修工程 包给一家朋友们都特别推荐的一家装修公司。当你和装修 公司的业务（项目）经理进行沟通时，你发现这个业务经 理总是不停的说。 请记录下，这个业务经理都主要在说哪些事： 1.哪些方面工作给我们做； 2.工期多少； 3.效果如何的好； 4.多少钱； 【导入案例导入案例】 多 快 好 省 范围 时间 质量 成本 Date 1 概述 项目范围管理 确保项目做且只做成功完成项目所需的 全部工作的各过程 既不多做 也不少做 Date 2 产品范围 (Product Scope）： 是指客户对项目最终产品或

2、服务所期望包 含的特征和功能的总和； 项目范围（Project Scope ）： 是为了交付满足产品范围要求的产品或服 务所必须完成的全部工作的总和。 概述 Date 3 知识领识领域项项目管理过过程组组 启动过动过 程组组规规划过过程组组执执行过过程组组监监控过过程组组收尾过过程组组 4项目整合管理4.1制定项目章 程 4.2 制定项目管理计 划 4.3 指导与管理项目工 作 4.4监控项目工作 4.6 结束项目或阶 段 4.5实施整体变更控 制 5 项项目范围围管理 5.1 规规划范围围管理 5.5确认认范围围 5.2收集需求 5.3定义义范围围5.6控制范围围 5.4创创建WBS 6项目

3、时间 管理 6.1规划进度管理 6.7控制进度 6.2定义活动 6.3排列活动顺 序 6.4估算活动资 源 6.5估算活动持续时 间 6.6制定进度计划 7项目成本管理 7.1规划成本管理 7.4控制成本 7.2估算成本 7.3制定预算 8项目质量管理 8.1规划质量管理8.2实施质量保证8.3控制质量 9项目人力资源管 理 9.1 规划人力资源管 理 9.2组建项目团队 9.3建设项 目团队 9.4管理项目团队 10项目沟通管理 10.1规划沟通管理10.2管理沟通10.3控制沟通 11项目风险 管理 11.1规划风险 管理 11.6控制风险 11.2识别风险 11.3 实施定性风险 分 析

4、 11.4 实施定量风险 分 析 11.5规划风险应对 12项目采购管理 12.1规划采购管理12.2实施采购12.3控制采购12.4结束采购 13项目干系人管理 13.1 识别 干系人 13.2 规划干系人管理 13.3管理干系人参与13.4 控制干系人参与 Date 4 在整个项目中，对如何管理范围提供指南和方向 。 5.1 规划范围管理 5.1 规规划范围围管理 输输入工具与技术术输输出 项目管理计划专家判断范围管理计划 项目章程会议需求管理计划 事业环境因素 组织过 程资产 范围管理计划 如何定义、制定、监控、控制和 确认项目范围 需求管理计划如何分析、记录和管理需求 Date 5 为

5、定义和管理项目范围（包括产品范围）奠定基 础 5.2 收集需求 5.2 收集需求 输输入工具与技术术输输出 范围管理计划 访谈 问卷调查需求文件 需求管理计划 焦点小组 观察需求跟踪矩阵 干系人管理计 划 引导式研讨会 原型法 项目章程 群体创新技术 标杆对照 干系人登记册 群体决策技术 系统交互图 文件分析 Date 6 指发起人、客户和其它干系人的已量化且记录下 来的需要和期望，是WBS的基础 5.2.1 需求 需求 业务需求 干系人需求 解决方案需求 过渡需求 项目需求 质量需求 功能需求 非功能需求 Date 7 5.2.2 输出 需求文件 q 记录干系人的需求 q 单一需求如何满足业

6、务需求 需求跟踪矩阵 q 链接需求与需求源的表格 q 对需求进行跟踪 q 需求与业务目标或项目目标相联系 q 确保需求都具有商业价值 q 产品范围变更的框架 编 号 关联编 号 需求描 述 业务需求、机会 、目的、目 标 项目目 标 WBS可交 付 成 果 产品设 计 产品开 发 测试用 例 0011.0 0022.0 Date 8 5.2.3 工具与技术访谈 q通常“一对一”访谈 q预设或即兴问题 q愿意且能说清楚 q也可用于获取机密信息 目的：识别和定义可交付成果的特征和功能 Date 9 5.2.3 工具与技术焦点小组会议 q 群体访谈 q 互动式讨论，求得更有 价值的意见 q 寻求集体

7、而非个人意见 预先选定的干系人和主题专家集中在一起， 了解其对产品、服务或成果期望和态度 Date 10 5.2.3 工具与技术引导式研讨会 q 快速定义跨职能需求 q 协调干系人差异 q 有助于建立信任，促进关系，改善沟通，达成一致意见 q 比单项会议更快的发现和解决问题 q 软件行业：联合应用开发JAD 把用户和开发团队集中在一起，改进软件开发流程 q 制造行业：质量功能开发QFD 从收集客户需求开始，客观的对需求分类和排序，设置目标 主要干系人参加会议，对产品需求进行集中讨论定义 Date 11 5.2.3 工具与技术群体创新技术 通过群体的集思广益活动，来识别产品和项目需求的技术 q多

8、标准决策分析 q头脑风暴 q名义小组技术 q概念/思维导图 q亲和图 Date 12 群体创新技术（多标准决策分析） 指做决策时必须考虑多重相互矛盾的标准 价格 安全性能 节能环保 性能 舒适 外观 借助决策矩阵，多重标准，作出决策 Date 13 群体创新技术（头脑风暴） 避免权威人士在场，时间30-45分钟 q自由畅谈、禁止批评 q所有的观点被记录下 q延迟评判 q首要任务追求数量 Date 14 群体创新技术（名义小组技术） 头脑风暴法的深化应用 名 义 小 组 1 名 义 小 组 2 q 全体投票排列最有用创意 q 独立思考，写下方案并陈述 q 主管有权决定接受或拒绝方案 Date 1

9、5 群体创新技术（思维导图） 从头脑风暴法 获得创意，用 思维导图联系 起来，反应创 意之间共性和 差异，从而引 导出新的创意 Date 16 群体创新技术（亲和图） 对头脑风暴中的主意进行分类（注意的相似性） 目的：以便审查和分析，综合求创新。 Date 17 5.2.3 工具与技术群体决策 为达成某种期望结果，而对多个方案进行评估 q一致同意（可用德尔菲技术） q大多数原则：群体中超过50%支持，即作出决策 q相对多数原则：群体里相对多数意见作出决策 q独裁：某一个人对群体作出决策 目的：生产产品需求，并对其进行归类和优先级排序 Date 18 群体决策（德尔菲技术） q 获得专家意见的常

10、用方法，减少偏见 q 问卷收集匿名专家的意见 q 基本规则： 1. 一人一票 2. 专家之间背靠背 3. 专家以匿名提出意见 4. 旨在取得一致意见 Date 19 5.2.3 工具与技术问卷调查 原型法 观察 问卷调查 q 预先设计调查表 q 干系人数量多 q 想快速完成 q 相对结果统计分析 原 型 法 q 用产品使用模型征求需求意见 q 不是只讨论抽象的需求 q 渐进明细 观 察 工作跟踪 q 旁站式、体验式 q 干系人数量少 q 不愿或说不清楚需求 Date 20 5.2.3 工具与技术杠杆对照 系统交互图 杠杆对照 与可比项目的实践进行对照 系统交互图 可内部，也可外部 识别最佳实践

11、 形成改善意见 绩效考核提供基础 对产品范围的可视化描绘，图形直观地展现 业务系统与其它系统之间的接口关系 Date 21 明确收集的需求，哪些在范围内，明确边 界 5.3 定义范围 5.3 定义义范围围 输输入工具与技术术输输出 范围管理计划专家判断项目范围说明书 项目章程产品分析项目文件更新 需求文件备选方案生成 组织过 程资产引导式研讨会 Date 22 5.3.1 输出-范围说明书 q提供基准 评价变更请求 衡量是否超过项目边界 q干系人共识 包含内容： 1. 产品范围描述 2. 验收标准 3. 可交付成果 4. 项目的除外责任 5. 制约因素 6. 假设条件 Date 23 5.3.

12、2 蔓延 镀金 范围蔓延 镀 金 未得到控制的变更 可交付物和范围定义不一致 为讨好客户，做了不该做的事 情等行为称为镀金 项目角度：都是失败的项目 Date 24 5.3.3 工具与技术-产品分析 适用于产品为主要交付成果的项目 q产品分解 q系统分析 q系统工程 q需求分析 q价值工程 q价值分析 Date 25 5.3.3 工具与技术-备选方案识别 制定尽可能多的潜在可选方案 头脑风暴 横向分析 备选方案 分析 Date 26 对可交付成果的内容提供一个结构化的视 图 5.4 创建工作分解结构（WBS） 5.4 创创建WBS 输输入工具与技术术输输出 范围管理计划分解范围基准 项目范围说

13、明 书 专家判断项目文件更新 需求文件 事业环境因素 组织过 程资产 Date 27 5.4.1 工作分解结构作用 面向可交付成果 如无法编出WBS， 一般不要开始计划工作， 决不能开始实施 将任务分解 为已知任务 为项目管理 提供框架 帮助建设项 目团队 考核项目完 成情况依据 方便项目干 系人沟通 实时的计划 和情况追踪 便于估算和 任务分配 Date 28 5.4.2 工作分解结构（WBS） 项目 1.11.2 1.2.11.2.2 规划包 1.2.1.11.2.1.2 控制账户 信息不足工作内 容已知但详细进 度活动未知 工作包 Date 29 5.4.3 WBS有效性标准 1、一个单

14、位工作任务只能在WBS中出现在一个地方 2、一个WBS中的每一项工作都只有一个人负责，即使这 项工作由多人来做，也是如此 3、WBS必须与工作任务的实际执行过程相一致 4、项目组成员必须参与WBS的制定，以确保一致性和全 员参与 5、每一个WBS都必须归档，以确保准确理解该项包括的 和不包括的工作范围 6、再对项目工作内容进行控制的同时，还必须让WBS具 有一定的灵活性以适应无法避免的变更需要 Date 30 5.4.4 工作包 1、WBS最低层的可交付成果 （包含计划的工作 ） 2、详细程度因项目大小与复杂程度而异 3、能够可靠地估算和管理工作成本和活动持续 时间的位置 4、80/40小时原

15、则 5、 1%-10%原则 6、由负责具体工作的人分解 Date 31 5.4.5 WBS词典 账户编码标识 工作描述 假设条件和制约因素 负责的组织 进度里程碑 相关的进度活动 所需资源 成本估算 质量要求 验收标准 技术参考文献 协议信息 WBS词典是针对每个WBS组件，详细描述 可交付成果、活动和进度信息的文件 Date 32 5.4.5 工具与技术分解 分解步骤 q核实分配程度是否恰当 q制定和分配标识编码 q自上而下的分解 q确定WBS结构和编排方法 q识别可交付成果及相关工作 Date 33 5.4.5 工具与技术分解 分解规则 可交付成果为导向 子要素等于母要素 100%原则 包

16、含所有项目工作 要素之间相互独立 独一无二的账户编码 有利制定责任人 4-6层 外包可作为工作包 WBS第二层： q 项目生命周期的各阶段 q 主要可交付成果 q 项目管理可独特分支存在 q 子项目 规则 Date 34 正式验收已完成的项目可交付成果的过程 5.5 确认范围 5.5 确认认范围围 输输入工具与技术术输输出 项目管理计划检查验收的可交付成果 需求文件群体决策技术变更请求 需求跟踪矩阵工作绩效信息 核实的可交付成果项目文件更新 工作绩效数据 Date 35 审查“核实的可交付成果” 确保已圆满完成 获得客户或发起人的正式验收 5.5.1 确认范围 确认范围关注可交付成果的验收 质量控制关注可交付成果是否正确及是否满足质量要求 质量控制通常先于确认范围进行，也可同时 Date 36 监督项目和产品的范围状态，管理范围基准变更的过程 5.6 控制范围 5.6 控制范围围 输输入工具与技术术输输出 项目管理计划偏差分析工作绩效信息 需求文件变更请求 需求跟踪矩阵项目管理计划更新 组织过 程资产项目文件更新 工作绩效数据组织过 程资产更新 保持对范围基准的维护 偏差分析 确定实际绩效与基准差异程度及原因的技术 评估偏离范围基准的程度 Date 37