范围管理(WBS和责任分配矩阵)演示课件.ppt

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,管理学,2004,级,*,P-,*,项目范围管理,1,4.,1项目范围管理概述,4,.2收集需求,4,.3定义范围,4.,4项目工作分解,4.,5核实范围和控制范围,P-,2,2,4,.1项目范围管理概述,项目范围,项目范围是指项目团队为确保项目目标的完成而必须生成的项目的,“产品范围”,和为生成项目产品而必须开展的项目的,“工作范围”,。在项目范围管理领域，项目范围包括两个方面的含义：,项目产品范围,，即项目所要生成的产品或服务的特征和功能。项目的产品范围有可能包括单一的产品，也可能包括多种项目产品。,项目工作范围,，即项目团队为提交项目最终产品所进行的必需且仅需完成的各项工作。,必需的工作,指实现项目目标所进行的全部工作，任何必需的工作都不能遗漏，否则会导致,项目范围的萎缩,。,仅需的工作,指实现项目目标所规定的,“,必要的,最少的,”,的工作,不进行此项工作就无法完成项目,不做额外工作,否则会导致,项目范围的蔓延,.,工作范围以产品范围为基础，,工作范围的确定是一个由一般到具体、层层深入的过程。,项目产品范围的完成情况是参照业主的要求来衡量的，而项目工作范围的完成情况是参照计划来衡量的。,P-,3,3,4,.1项目范围管理概述,项目范围管理,项目范围管理是明确界定项目范围包括什么与不包括什么并确保项目范围所规定的工作得以顺利完成所需要的所有以分析、决策、组织、计划、控制为特征的管理活动。,这些活动用于确保项目干系人对作为项目结果的项目产品以及生产这些产品所用到的过程有一个共同的理解。,作用：可提高项目费用、时间和资源估算的准确性。,提供了项目进度衡量和控制的基准。,有助于清楚地分派责任。,项目评估的依据之一。,P-,4,4,4,.1项目范围管理概述,项目范围管理的内容,收集需求,为实现项目目标而定义并记录干系人的需求的过程。,定义范围,制定项目和产品详细描述的过程。包括制定详细的项目范围说明书。,创建工作分解结构,将项目可交付成果和项目工作分解为较小的、更易于管理的组成部分的过程。,核实范围,项目干系人（发起人、客户和顾客等）正式验收项目已完成的可交付成果的过程。,控制范围,监督项目和产品的范围状态、管理范围基准变更的过程。,在进行以上,5,个过程之前，项目管理团队应先进行规划工作，产生一份范围管理计划，范围管理计划可以是正式的或非正式的、非常详细或高度概括的。,P-,5,5,4,.2 收集需求,需求是指发起人、客户和其他干系人的,已量化且记录下来,的需要与期望。,许多组织把需求分为项目需求和产品需求。项目需求包括商业需求、项目管理需求、交付需求等。产品需求则包括技术需求、安全需求、性能需求等。,输入,工具与技术,输出,项目章程,访谈,需求文件,干系人登记册,焦点小组会议,需求管理计划,引导式研讨会,需求跟踪矩阵,群体创新技术,群体决策技术,问卷调查,观察,原型法,6,4,.2 收集需求,1.,访谈,访谈是一种通过与干系人直接交谈，来获得信息的正式与非正式方法,参与者：有经验的项目参与者、干系人和主题专家,方式：通常采取“一对一”的形式,2.,焦点小组会议,焦点小组会议把预先选定的干系人和主题专家集中在一起，了解他们对所提议产品、服务或成果的期望和态度,参与者：预先选定的干系人和主题专家,方式：互动式讨论，往往比“一对一”的访谈更激烈,3.,引导式研讨会,引导式研讨会通过邀请主要的跨职能干系人一起参加会议，对产品需求进行集中讨论与定义,参与者：主要的跨职能干系人,特点：建立信任、促进关系、改善沟通，有利于参加者达成一致意见,比单项会议更快地发现和解决问题,7,4,.2 收集需求,4.,问卷调查,问卷调查通过设计书面问题，向众多的受访者快速收集信息,适用情况：受众众多，需要快速完成调查，并想要使用统计分析法,5.,观察（也称工作跟踪）,观察：直接观察个人在各自的环境中如何开展工作和实施流程,适用情况：产品使用者难以或不愿说明他们的需求,根据观察者是否执行工作，观察分为两种方式,方式,1,：观察者从外部来观察使用者的工作,方式,2,：由参与观察者实际执行一个流程或程序,6.,原型法,在实际制造产品之前，先造出该产品的实用模型，并据此征求对需求的反馈意见。,8,4,.2 收集需求,7.,群体创新技术,头脑风暴法：通过专家们的相互交流，在头脑中进行智力碰撞，产生新的智力火花，使专家的讨论不断集中和精化。,规则一：异想天开！,说出能想到的任何主意,规则二：不许评价！,要到评估阶段才能进行评价,规则三：见解无专利！,鼓励综合数种见解或在他人见解上进行发挥，并提供优先发言的权利。,规则四：越多越好！,重数量而非质量,名义小组技术：通过投票来排列最有用的创意，以便进行进一步的头脑风暴或优先排列，是头脑风暴的深化应用。,德尔菲技术,概念或思维导图：把从头脑风暴中获得的构思，用一张简单的图联系起来，以反映这些创意之间的共性和差异，从而引导出新的构思。8,、群体决策技术,群体决策技术是为达成某种期望结果而对多个未来行动方案进行评估,一致同意,/,大多数原则,/,相对多数原则,/,独裁,9,4,.2收集需求,需求文件,一开始可能只有概括性的需求，然后随着信息的增加而逐步细化。只有明确的（可测量和可测试的）、可跟踪的、相互协调的、且主要干系人愿意认可的需求，才能作为基准。,需求管理计划,描述在整个项目生命周期内如何分析、记录和管理需求,需求跟踪矩阵,是一张连接需求与需求源的表格，以便在整个项目生命中对需求进行跟踪。需求跟踪矩阵把每一个需求与业务目标或项目目标联系起来，有助于确保每一个需求都具有商业价值，有助于确保需求文件所批准的每一项需求在项目结束时都得到实现。,10,11,4,.3 定义范围,定义范围过程,定义范围是指“制定详细的,项目范围说明书,作为未来项目决策的基准的过程”。主要包括三个部分的内容：第一，项目团队应该明确在项目结束时和为确保项目最终成功的过程中，他们应交付给项目干系人什么。例如，如果项目的最终可交付成果是一个新的电脑程序，那么在项目实施过程中的可交付成果应该包括一份项目内容设计的提纲和模型。第二，团队应该确定为了生产可交付成果所应实施的活动。第三，团队应明确能够限制和影响项目工作的因素例如某些假设和约束。,输入,工具与技术,输出,项目章程,专家判断,项目范围说明书,需求文件,产品分析,项目文件（更新）,组织过程资产,备选方案识别,引导式研讨会,12,4,.3 定义范围,项目范围说明书,详细描述项目的可交付成果，以及为提交这些可交付成果而必须开展的工作。,项目范围说明书也表明项目干系人之间就项目范围所达成的共识。它还为评价变更请求或额外工作是否超出项目边界提供基准。,P-,13,产品范围描述,初步细化项目章程中所描述的项目产品、服务或成果，详细说明项目产品、服务或成果应具备的功能特性。,产品验收准则,说明项目产品、服务或成果的主要验收过程与验收标准,项目工作范围,确定项目需要完成的工作,项目可交付成果,可交付成果既包括组成项目产品或服务的各种结果，也包括各种辅助成果，如项目管理报告和文件。对可交付成果的描述可详细也可简要。,项目除外责任,明确指出那些不属于项目范围内但干系人可能误以为是项目的一部分的工作,项目制约因素,列出并说明与项目范围有关、且限制项目团队选择的具体项目制约因素。如事先确定的预算、强制性日期或强制性进度里程碑。,项目假设条件,列出并说明与项目范围有关的具体项目假设条件，以及万一不成立而可能造成的后果,13,4,.4 创建工作分解结构,什么是,WBS,？,WBS,是英文,WorkBreakdownStructure,（工作分解结构）的缩写。,WorkBreakdownStructure,（,WBS,）工作分解结构是把项目可交付成果和项目工作分解成较小的、更易于管理的组成部分的过程。工作分解结构每下降一个层次就意味着对项目工作更详尽的定义。WBS是项目的地图，它的使用有助于使项目经理明确所有产品和工作要素，使项目与当前组织结合起来，并建立控制的基础。本质上，WBS是项目在不同细节水平上的概述。,P-,14,输入,工具与技术,输出,项目范围说明书,分解,工作分解结构,需求文件,工作分解结构词典,组织过程资产,范围基准,项目文件（更新）,14,WBS,的构成,结构化编码,编码是最显著和最关键的,WBS,构成因子，首先编码用于将,WBS,彻底的结构化。通过编码体系，我们可以很容易识别,WBS,元素的层级关系、分组类别和特性。,WBS,元素,WBS,元素实际上就是,WBS,结构上的一个个“节点”，通俗的理解就是“组织机构图”上的一个个“方框”，这些方框代表了独立的、具有隶属关系,/,汇总关系的“可交付成果”。,工作包,是,WBS,的最底层元素，一般的工作包是最小的“可交付成果”，是短时间的任务，有确定的起点和终点，,这些可交付成果很容易识别出完成它的活动、成本和组织以及资源信息。,每个工作包都是一个控制点。,a.,工作包可以在制定项目进度计划时，进一步分解为活动。,b.,工作包可以由惟一的一个部门或承包商负责。,c.,工作包的定义应考虑,80,小时法则,(80-HourRule),或两周法则,(Two Week Rule),，即任何工作包的完成时间应当不超过80,小时。（可以在没有损失太多时间的情况下及时识别出问题）,WBS,字典,它用于描述和定义,WBS,元素中的工作的文档。字典相当于对某一,WBS,元素的规范，即,WBS,元素必须完成的工作以及对工作的详细描述；工作成果的描述和相应规范标准；元素上下级关系以及元素成果输入输出关系等。,P-,15,4,.4 创建工作分解结构,15,WBS示例,新设备安装运行,1000,设备调试,1400,设备安装,1300,布局设计,1200,总体设计,1100,厂址,分析,1110,选择,设计,1120,机器,布局,121,0,工艺流,程设计,1220,加工,1310,装配,1320,安装,设备,1330,测试,设备,1410,试生产,1420,测试,建筑,物,1323,组装,部件,1322,把零件,运往工,地,1321,0,级,1,级,2,级,3,级,16,制定,WBS,的过程,a.,得到范围说明书,(Scope Statement),或工作说明书,(Statement of Work,，承包子项目,),。,b.,召集有关人员，集体讨论所有主要项目工作，,确定项目工作分解的方式。,WBS,较高层次上的一些工作可以定义为,产品,/,服务或子生命周期阶段。,c.,分解项目工作。如果有现成的模板，应该尽量利用。,工作分解结构（,WBS),实践标准,第二版,d.,画出,WBS,的层次结构图。,e.,验证上述分解的正确性。,f.,建立一个,编号系统。,g.,随着其他计划活动的进行，不断地对,WBS,更新或修正，直到覆盖所有工作。,h.,编写,WBS,字典,4,.4 创建工作分解结构,17,4,.4 创建工作分解结构,项目工作分解的组织方式,自上而下,(top-down),的方法。,从项目的目标开始，逐级分解项目工作，直到参与者满意地认为项目工作已经充分地得到定义。该方法由于可以将项目工作定义在适当的细节水平，对于项目工期、成本和资源需求的估计可以比较准确。,自下而上（,bottom-up,）的方法。,从详细的任务开始，将识别和认可的项目任务逐级归类到上一层次，直到达到项目的目标。这种方法存在的主要风险是可能不能完全地识别出所有任务或者识别出的任务过于粗略或过于琐碎。经常用于全新系统或方法的项目，以及促进全员参与。,P-,18,18,4,.4 创建工作分解结构,项目工作分解的方法,使用指导方针构建,类比法构建,按照产品、服务构成构建,按照项目生命周期构建,按照工作职能构建,19,4,.4 创建工作分解结构,产品项目分解：,对可交付产品物理结构的细分是最通用和最容易开发的,WBS,，,所有的这类项目都有一个有形的输出产品。,服务项目分解：,服务项目没有有形的、结构性的可交付成果，它的输出是一个为别人做的工作实体，如会议，宴会和婚礼等。,项目的分解是基于一种对相似和相关的工作元素、职能或技术进行逻辑分组。,结果项目分解：,结果项目也没有有形的、结构性的可交付成果，它的输出是一个过程的结果，过程产生一个产品或一个结论：癌症研究、新药物开发等。,该工作分解是一系列可接受的步骤。,P-,20,20,4,.4 创建工作分解结构,验证分解正确性,“百分之百规则”：一个,WBS,元素的下一层分解必须百分之百地表示上一层元素,.,WBS,必须与工作任务的实际执行过程相一致，,WBS,首先应当服务于项目组，可能的话再考虑其他目的。,一个工作包只能在,WBS,中出现一次,每项工作由一个人负责,能非常清楚要做什么么？,能准确地估计实施这个行动所需要的资源吗？,能准确地估计实施实施行动所需的时间么？,每一个,WBS,项必须有准确描述,工作包的,80,小时原则,运用,MECE,法，检查是否有遗漏或重复的工作,MECE,分析法，全称,Mutually Exclusive Collectively Exhaustive,，,中文意思是“相互独立，完全穷尽”。也就是对于一个重大的议题，能够做到不重叠、不遗漏的分类，而且能够借此有效把握问题的核心，并解决问题的方法。,P-,21,21,编码不仅把不同的项目单元区别开，而且要保留它所有特征，如所属的子项目，所属区域、专业功能、要素等。在项目实施过程中的网络分析，成本管理、数据的储存、分析、统计都靠编码识别。,22,4,.4 创建工作分解结构,责任矩阵,责任矩阵是以表格形式表示完成工作分解结构中工作细目的个人责任的方法。制定责任矩阵的主要作用是将工作分配给每一个成员后，通过责任矩阵可以清楚地看出每一个成员在项目执行过程中所承担的责任。,责任矩阵表头部分填写项目需要的各种人员角色，而与活动交叉的部分则填写每个角色对每个活动的责任关系，从而建立“人”和“事”的关联。不同的责任可以用不同的符号表示。例如P（Principal）表示负责人；S（Support）表示支持者或参与者；R（Review）表示审核者。,用责任矩阵可以非常方便地进行检查责任检查：横向检查可以确保每个活动有人负责，纵向检查可以确保每个人至少负责一件“事”。在完成后续讨论的估算工作后，还可以横向统计每个活动的总工作量，纵向统计每个角色的投入的总工作量。,23,24,。,25,4,.5 核实范围和控制范围,核实范围,核实范围是项目干系人（发起人、客户和顾客）最终认可和接受项目范围的过程。项目干系人可以通过检查的方式（测量、检验和测试等）来核实项目工作的完成情况，从而决定是否接受项目。,输入,工具与技术,输出,项目管理计划,检查,验收的可交付成果,需求文件,变更请求,需求跟踪矩阵,项目文件（更新）,确认的可交付成果,26,4,.5 核实范围和控制范围,范围核实,发生在项目的阶段点上（,如果项目在合同的方式下进行，合同中一般会规定检查的时间和地点。），即每个项目阶段收尾的时候，范围核实的最终结果就是客户或项目发起人对项目可交付成果和工作结果的正式接受。,客户或项目发起人应签署接受文件，,接受文件一经签署，应及时发给相关的项目干系人。,检查的结果可能是接受，也可能是拒绝。如果检查的结果符合项目规范的规定，检查结果为接受；否则为拒绝，这时，客户,/,项目发起人应说明拒绝的原因，执行组织根据检查的结果采取纠偏措施，之后，重新对项目的执行情况和执行结果进行检查。,如果执行组织和客户,/,项目发起人不能就检查结果形成一致意见，则可以将检查委托给一个各方一致认可的第三方进行“独立检查”。,27,4,.5核实范围和控制范围,控制范围,控制范围是监督项目和产品的范围状态、管理范围基准变更的过程。对项目范围进行控制，就必须确保所有请求的变更、推荐的纠正措施或预防措施都经过实施整体变更控制过程的处理。,输入,工具与技术,输出,项目管理计划,偏差分析,工作绩效测量结果,工作绩效信息,组织过程资产（更新）,需求文件,变更请求,需求跟踪矩阵,项目管理计划（更新）,组织过程资产,项目文件（更新）,28,4,.5 核实范围和控制范围,项目范围变更的原因,项目干系人常常由于各种原因要对项目范围进行修改，引起范围变更原因很多，主要有：,项目外部环境发生变化，如政府的有关规定发生变化，竞争对手生产出了新产品，本国货币贬值等。,在项目范围计划和定义时出现了错误的遗漏，如在设计企业信息系统时未考虑到移动互联网的广泛使用。,项目团队提出了新技术、手段或方案。,项目实施组织本身发生了变化，如项目所在单位同其他单位合并，项目团队人事发生变化。,客户对项目或项目产品提出的要求发生变化，如高校教务管理系统软件开发项目，考虑到在学分制条件下的应用。,29,4,.5 核实范围和控制范围,项目管理多级控制系统中的职责,控制对象,项目小组成员,项目经理,CCB,项目范围,范围漏洞,按项目计划要求执行,范围变更,进度计划,提高效率,不影响项目可交付成果的内部里程碑的调整,导致项目工期延长,成本预算,无,按项目预算计划执行,任何项目费用的增加,30,