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

2019/7/28,1,经过自己多年的努力，在市区的繁华地段购买了一套不错的三居室房子；为了尽快入住，你准备将房子的装修工程包给一家朋友们都特别推荐的一家装修公司。当你和装修公司的业务（项目）经理进行沟通时，你发现这个业务经理总是不停的说。 请记录下，这个业务经理都主要在说哪些事： 1.哪些方面工作给我们做； 2.工期多少； 3.效果如何的好； 4.多少钱；,【导入案例】,多,快,好,省,范围,时间,质量,成本,2019/7/28,2,概述,项目范围管理 确保项目做且只做成功完成项目所需的全部工作的各过程 既不多做 也不少做,2019/7/28,3,产品范围 (Product Scope）： 是指客户对项目最终产品或服务所期望包含的特征和功能的总和； 项目范围（Project Scope ）： 是为了交付满足产品范围要求的产品或服务所必须完成的全部工作的总和。,概述,2019/7/28,4,2019/7/28,5,在整个项目中，对如何管理范围提供指南和方向。,5.1 规划范围管理,范围管理计划,如何定义、制定、监控、控制和 确认项目范围,需求管理计划,如何分析、记录和管理需求,2019/7/28,6,为定义和管理项目范围（包括产品范围）奠定基础,5.2 收集需求,2019/7/28,7,指发起人、客户和其它干系人的已量化且记录下来的需要和期望，是WBS的基础,5.2.1 需求,需求,业务需求,干系人需求,解决方案需求,过渡需求,项目需求,质量需求,功能需求 非功能需求,2019/7/28,8,5.2.2 输出,需求文件,记录干系人的需求 单一需求如何满足业务需求,需求跟踪矩阵,链接需求与需求源的表格 对需求进行跟踪 需求与业务目标或项目目标相联系 确保需求都具有商业价值 产品范围变更的框架,2019/7/28,9,5.2.3 工具与技术访谈,通常“一对一”访谈 预设或即兴问题 愿意且能说清楚 也可用于获取机密信息,目的：识别和定义可交付成果的特征和功能,2019/7/28,10,5.2.3 工具与技术焦点小组会议,群体访谈 互动式讨论，求得更有 价值的意见 寻求集体而非个人意见,预先选定的干系人和主题专家集中在一起， 了解其对产品、服务或成果期望和态度,2019/7/28,11,5.2.3 工具与技术引导式研讨会,快速定义跨职能需求 协调干系人差异 有助于建立信任，促进关系，改善沟通，达成一致意见 比单项会议更快的发现和解决问题 软件行业：联合应用开发JAD 把用户和开发团队集中在一起，改进软件开发流程 制造行业：质量功能开发QFD 从收集客户需求开始，客观的对需求分类和排序，设置目标,主要干系人参加会议，对产品需求进行集中讨论定义,2019/7/28,12,5.2.3 工具与技术群体创新技术,通过群体的集思广益活动，来识别产品和项目需求的技术,多标准决策分析 头脑风暴 名义小组技术 概念/思维导图 亲和图,2019/7/28,13,群体创新技术（多标准决策分析）,指做决策时必须考虑多重相互矛盾的标准,价格 安全性能 节能环保 性能 舒适 外观,借助决策矩阵，多重标准，作出决策,2019/7/28,14,群体创新技术（头脑风暴）,避免权威人士在场，时间30-45分钟,自由畅谈、禁止批评 所有的观点被记录下 延迟评判 首要任务追求数量,2019/7/28,15,群体创新技术（名义小组技术）,头脑风暴法的深化应用,名 义 小 组 1,名 义 小 组 2,全体投票排列最有用创意 独立思考，写下方案并陈述 主管有权决定接受或拒绝方案,2019/7/28,16,群体创新技术（思维导图）,从头脑风暴法 获得创意，用 思维导图联系 起来，反应创 意之间共性和 差异，从而引 导出新的创意,2019/7/28,17,群体创新技术（亲和图）,对头脑风暴中的主意进行分类（注意的相似性）,目的：以便审查和分析，综合求创新。,2019/7/28,18,5.2.3 工具与技术群体决策,为达成某种期望结果，而对多个方案进行评估,一致同意（可用德尔菲技术） 大多数原则：群体中超过50%支持，即作出决策 相对多数原则：群体里相对多数意见作出决策 独裁：某一个人对群体作出决策,目的：,生产产品需求，并对其进行归类和优先级排序,2019/7/28,19,群体决策（德尔菲技术）,获得专家意见的常用方法，减少偏见 问卷收集匿名专家的意见 基本规则： 一人一票 专家之间背靠背 专家以匿名提出意见 旨在取得一致意见,2019/7/28,20,5.2.3 工具与技术问卷调查 原型法 观察,问卷调查,预先设计调查表 干系人数量多 想快速完成 相对结果统计分析,原 型 法,用产品使用模型征求需求意见 不是只讨论抽象的需求 渐进明细,观 察,工作跟踪 旁站式、体验式 干系人数量少 不愿或说不清楚需求,2019/7/28,21,5.2.3 工具与技术杠杆对照 系统交互图,杠杆对照,与可比项目的实践进行对照,系统交互图,可内部，也可外部,识别最佳实践 形成改善意见 绩效考核提供基础,对产品范围的可视化描绘，图形直观地展现 业务系统与其它系统之间的接口关系,2019/7/28,22,明确收集的需求，哪些在范围内，明确边界,5.3 定义范围,2019/7/28,23,5.3.1 输出-范围说明书,提供基准 评价变更请求 衡量是否超过项目边界 干系人共识,包含内容： 产品范围描述 验收标准 可交付成果 项目的除外责任 制约因素 假设条件,2019/7/28,24,5.3.2 蔓延 镀金,范围蔓延,镀 金,未得到控制的变更 可交付物和范围定义不一致,为讨好客户，做了不该做的事情等行为称为镀金,项目角度：都是失败的项目,2019/7/28,25,5.3.3 工具与技术-产品分析,适用于产品为主要交付成果的项目,产品分解 系统分析 系统工程 需求分析 价值工程 价值分析,2019/7/28,26,5.3.3 工具与技术-备选方案识别,制定尽可能多的潜在可选方案,头脑风暴,横向分析,备选方案分析,2019/7/28,27,对可交付成果的内容提供一个结构化的视图,5.4 创建工作分解结构（WBS）,2019/7/28,28,5.4.1 工作分解结构作用,面向可交付成果,如无法编出WBS， 一般不要开始计划工作， 决不能开始实施,将任务分解 为已知任务,为项目管理提供框架,帮助建设项目团队,考核项目完 成情况依据,方便项目干系人沟通,实时的计划 和情况追踪,便于估算和任务分配,2019/7/28,29,5.4.2 工作分解结构（WBS）,控制账户,信息不足工作内 容已知但详细进 度活动未知,工作包,2019/7/28,30,5.4.3 WBS有效性标准,1、一个单位工作任务只能在WBS中出现在一个地方 2、一个WBS中的每一项工作都只有一个人负责，即使这项工作由多人来做，也是如此 3、WBS必须与工作任务的实际执行过程相一致 4、项目组成员必须参与WBS的制定，以确保一致性和全员参与 5、每一个WBS都必须归档，以确保准确理解该项包括的和不包括的工作范围 6、再对项目工作内容进行控制的同时，还必须让WBS具有一定的灵活性以适应无法避免的变更需要,2019/7/28,31,5.4.4 工作包,1、WBS最低层的可交付成果 （包含计划的工作） 2、详细程度因项目大小与复杂程度而异 3、能够可靠地估算和管理工作成本和活动持续时间的位置 4、80/40小时原则 5、 1%-10%原则 6、由负责具体工作的人分解,2019/7/28,32,5.4.5 WBS词典,账户编码标识 工作描述 假设条件和制约因素 负责的组织 进度里程碑 相关的进度活动 所需资源 成本估算 质量要求 验收标准 技术参考文献 协议信息,WBS词典是针对每个WBS组件，详细描述 可交付成果、活动和进度信息的文件,2019/7/28,33,5.4.5 工具与技术分解,分解步骤,核实分配程度是否恰当 制定和分配标识编码 自上而下的分解 确定WBS结构和编排方法 识别可交付成果及相关工作,2019/7/28,34,5.4.5 工具与技术分解,分解规则,可交付成果为导向,子要素等于母要素,100%原则,包含所有项目工作,要素之间相互独立,独一无二的账户编码,有利制定责任人,4-6层,外包可作为工作包,WBS第二层：,项目生命周期的各阶段 主要可交付成果 项目管理可独特分支存在 子项目,规则,2019/7/28,35,正式验收已完成的项目可交付成果的过程,5.5 确认范围,2019/7/28,36,审查“核实的可交付成果” 确