范围管理和责任分配矩阵

（优选）范围管理和责任分配矩阵当前1页，总共29页。4.1项目范围管理概述4.2收集需求4.3定义范围4.4项目工作分解4.5核实范围和控制范围P-2当前2页，总共29页。4.1项目范围管理概述项目范围

项目范围是指项目团队为确保项目目标的完成而必须生成的项目的“产品范围”和为生成项目产品而必须开展的项目的“工作范围”。在项目范围管理领域，项目范围包括两个方面的含义：

项目产品范围，即项目所要生成的产品或服务的特征和功能。项目的产品范围有可能包括单一的产品，也可能包括多种项目产品。

项目工作范围，即项目团队为提交项目最终产品所进行的必需且仅需完成的各项工作。

必需的工作——指实现项目目标所进行的全部工作，任何必需的工作都不能遗漏，否则会导致项目范围的萎缩。

仅需的工作——指实现项目目标所规定的“必要的,最少的”的工作,不进行此项工作就无法完成项目,不做额外工作,否则会导致项目范围的蔓延.

工作范围以产品范围为基础，工作范围的确定是一个由一般到具体、层层深入的过程。

项目产品范围的完成情况是参照业主的要求来衡量的，而项目工作范围的完成情况是参照计划来衡量的。

P-3当前3页，总共29页。4.1项目范围管理概述项目范围管理

项目范围管理是明确界定项目范围包括什么与不包括什么，并确保项目范围所规定的工作得以顺利完成所需要的所有以分析、决策、组织、计划、控制为特征的管理活动。这些活动用于确保项目干系人对作为项目结果的项目产品以及生产这些产品所用到的过程有一个共同的理解。

作用：可提高项目费用、时间和资源估算的准确性。提供了项目进度衡量和控制的基准。有助于清楚地分派责任。项目评估的依据之一。

P-4当前4页，总共29页。4.1项目范围管理概述项目范围管理的内容收集需求——为实现项目目标而定义并记录干系人的需求的过程。定义范围——制定项目和产品详细描述的过程。包括制定详细的项目范围说明书。创建工作分解结构——将项目可交付成果和项目工作分解为较小的、更易于管理的组成部分的过程。核实范围——项目干系人（发起人、客户和顾客等）正式验收项目已完成的可交付成果的过程。控制范围——监督项目和产品的范围状态、管理范围基准变更的过程。在进行以上5个过程之前，项目管理团队应先进行规划工作，产生一份范围管理计划，范围管理计划可以是正式的或非正式的、非常详细或高度概括的。P-5当前5页，总共29页。4.2收集需求

需求是指发起人、客户和其他干系人的已量化且记录下来的需要与期望。

许多组织把需求分为项目需求和产品需求。项目需求包括商业需求、项目管理需求、交付需求等。产品需求则包括技术需求、安全需求、性能需求等。

输入工具与技术输出项目章程访谈需求文件干系人登记册焦点小组会议需求管理计划引导式研讨会需求跟踪矩阵群体创新技术群体决策技术问卷调查观察原型法当前6页，总共29页。4.2收集需求1.访谈访谈是一种通过与干系人直接交谈，来获得信息的正式与非正式方法参与者：有经验的项目参与者、干系人和主题专家方式：通常采取“一对一”的形式2.焦点小组会议焦点小组会议把预先选定的干系人和主题专家集中在一起，了解他们对所提议产品、服务或成果的期望和态度参与者：预先选定的干系人和主题专家方式：互动式讨论，往往比“一对一”的访谈更激烈3.引导式研讨会引导式研讨会通过邀请主要的跨职能干系人一起参加会议，对产品需求进行集中讨论与定义参与者：主要的跨职能干系人特点：建立信任、促进关系、改善沟通，有利于参加者达成一致意见比单项会议更快地发现和解决问题当前7页，总共29页。4.2收集需求4.问卷调查问卷调查通过设计书面问题，向众多的受访者快速收集信息适用情况：受众众多，需要快速完成调查，并想要使用统计分析法5.观察（也称工作跟踪）观察：直接观察个人在各自的环境中如何开展工作和实施流程适用情况：产品使用者难以或不愿说明他们的需求根据观察者是否执行工作，观察分为两种方式方式1：观察者从外部来观察使用者的工作方式2：由参与观察者实际执行一个流程或程序6.原型法在实际制造产品之前，先造出该产品的实用模型，并据此征求对需求的反馈意见。当前8页，总共29页。4.2收集需求7.群体创新技术头脑风暴法：通过专家们的相互交流，在头脑中进行智力碰撞，产生新的智力火花，使专家的讨论不断集中和精化。规则一：异想天开！——说出能想到的任何主意规则二：不许评价！——要到评估阶段才能进行评价规则三：见解无专利！——鼓励综合数种见解或在他人见解上进行发挥，并提供优先发言的权利。规则四：越多越好！——重数量而非质量名义小组技术：通过投票来排列最有用的创意，以便进行进一步的头脑风暴或优先排列，是头脑风暴的深化应用。德尔菲技术概念或思维导图：把从头脑风暴中获得的构思，用一张简单的图联系起来，以反映这些创意之间的共性和差异，从而引导出新的构思。8、群体决策技术群体决策技术是为达成某种期望结果而对多个未来行动方案进行评估一致同意/大多数原则/相对多数原则/独裁当前9页，总共29页。4.2收集需求需求文件

——一开始可能只有概括性的需求，然后随着信息的增加而逐步细化。只有明确的（可测量和可测试的）、可跟踪的、相互协调的、且主要干系人愿意认可的需求，才能作为基准。需求管理计划——描述在整个项目生命周期内如何分析、记录和管理需求需求跟踪矩阵——是一张连接需求与需求源的表格，以便在整个项目生命中对需求进行跟踪。需求跟踪矩阵把每一个需求与业务目标或项目目标联系起来，有助于确保每一个需求都具有商业价值，有助于确保需求文件所批准的每一项需求在项目结束时都得到实现。当前10页，总共29页。当前11页，总共29页。4.3定义范围定义范围过程

定义范围是指“制定详细的项目范围说明书作为未来项目决策的基准的过程”。主要包括三个部分的内容：第一，项目团队应该明确在项目结束时和为确保项目最终成功的过程中，他们应交付给项目干系人什么。例如，如果项目的最终可交付成果是一个新的电脑程序，那么在项目实施过程中的可交付成果应该包括一份项目内容设计的提纲和模型。第二，团队应该确定为了生产可交付成果所应实施的活动。第三，团队应明确能够限制和影响项目工作的因素——例如某些假设和约束。输入工具与技术输出项目章程专家判断项目范围说明书需求文件产品分析项目文件（更新）组织过程资产备选方案识别引导式研讨会当前12页，总共29页。4.3定义范围项目范围说明书——详细描述项目的可交付成果，以及为提交这些可交付成果而必须开展的工作。项目范围说明书也表明项目干系人之间就项目范围所达成的共识。它还为评价变更请求或额外工作是否超出项目边界提供基准。

P-13产品范围描述初步细化项目章程中所描述的项目产品、服务或成果，详细说明项目产品、服务或成果应具备的功能特性。产品验收准则说明项目产品、服务或成果的主要验收过程与验收标准项目工作范围确定项目需要完成的工作项目可交付成果可交付成果既包括组成项目产品或服务的各种结果，也包括各种辅助成果，如项目管理报告和文件。对可交付成果的描述可详细也可简要。项目除外责任明确指出那些不属于项目范围内但干系人可能误以为是项目的一部分的工作项目制约因素列出并说明与项目范围有关、且限制项目团队选择的具体项目制约因素。如事先确定的预算、强制性日期或强制性进度里程碑。项目假设条件列出并说明与项目范围有关的具体项目假设条件，以及万一不成立而可能造成的后果当前13页，总共29页。4.4创建工作分解结构什么是WBS？

WBS是英文Work

Breakdown

Structure（工作分解结构）的缩写。

Work

Breakdown

Structure（WBS）工作分解结构是把项目可交付成果和项目工作分解成较小的、更易于管理的组成部分的过程。工作分解结构每下降一个层次就意味着对项目工作更详尽的定义。WBS是项目的地图，它的使用有助于使项目经理明确所有产品和工作要素，使项目与当前组织结合起来，并建立控制的基础。本质上，WBS是项目在不同细节水平上的概述。

P-14输入工具与技术输出项目范围说明书分解工作分解结构需求文件工作分解结构词典组织过程资产范围基准项目文件（更新）当前14页，总共29页。WBS的构成

结构化编码

——编码是最显著和最关键的WBS构成因子，首先编码用于将WBS彻底的结构化。通过编码体系，我们可以很容易识别WBS元素的层级关系、分组类别和特性。

WBS元素——WBS元素实际上就是WBS结构上的一个个“节点”，通俗的理解就是“组织机构图”上的一个个“方框”，这些方框代表了独立的、具有隶属关系/汇总关系的“可交付成果”。

工作包——是WBS的最底层元素，一般的工作包是最小的“可交付成果”，是短时间的任务，有确定的起点和终点，这些可交付成果很容易识别出完成它的活动、成本和组织以及资源信息。每个工作包都是一个控制点。

a.工作包可以在制定项目进度计划时，进一步分解为活动。

b.工作包可以由惟一的一个部门或承包商负责。

c.工作包的定义应考虑80小时法则(80-HourRule)或两周法则(TwoWeekRule)，即任何工作包的完成时间应当不超过80小时。（可以在没有损失太多时间的情况下及时识别出问题）WBS字典——它用于描述和定义WBS元素中的工作的文档。字典相当于对某一WBS元素的规范，即WBS元素必须完成的工作以及对工作的详细描述；工作成果的描述和相应规范标准；元素上下级关系以及元素成果输入输出关系等。

P-15

4.4创建工作分解结构

当前15页，总共29页。WBS示例新设备安装运行1000设备调试1400设备安装1300布局设计1200总体设计1100厂址分析1110选择设计1120机器布局1210工艺流程设计1220加工1310装配1320安装设备1330测试设备1410试生产1420测试建筑物1323组装部件1322把零件运往工地13210级1级2级3级当前16页，总共29页。制定WBS的过程

a.得到范围说明书(ScopeStatement)或工作说明书(StatementofWork，承包子项目)。

b.召集有关人员，集体讨论所有主要项目工作，确定项目工作分解的方式。WBS较高层次上的一些工作可以定义为产品/服务或子生命周期阶段。

c.分解项目工作。如果有现成的模板，应该尽量利用。

《工作分解结构（WBS)实践标准》第二版

d.画出WBS的层次结构图。

e.验证上述分解的正确性。

f.建立一个编号系统。

g.随着其他计划活动的进行，不断地对WBS更新或修正，直到覆盖所有工作。

h.编写WBS字典

4.4创建工作分解结构当前17页，总共29页。4.4创建工作分解结构项目工作分解的组织方式

自上而下(top-down)的方法。从项目的目标开始，逐级分解项目工作，直到参与者满意地认为项目工作已经充分地得到定义。该方法由于可以将项目工作定义在适当的细节水平，对于项目工期、成本和资源需求的估计可以比较准确。自下而上（bottom-up）的方法。从详细的任务开始，将识别和认可的项目任务逐级归类到上一层次，直到达到项目的目标。这种方法存在的主要风险是可能不能完全地识别出所有任务或者识别出的任务过于粗略或过于琐碎。经常用于全新系统或方法的项目，以及促进全员参与。

P-18当前18页，总共29页。4.4创建工作分解结构项目工作分解的方法使用指导方针构建类比法构建按照产品、服务构成构建按照项目生命周期构建按照工作职能构建当前19页，总共29页。4.4创建工作分解结构产品项目分解：对可交付产品物理结构的细分是最通用和最容易开发的WBS，所有的这类项目都有一个有形的输出产品。服务项目分解：服务项目没有有形的、结构性的可交付成果，它的输出是一个为别人做的工作实体，如会议，宴会和婚礼等。项目的分解是基于一种对相似和相关的工作元素、职能或技术进行逻辑分组。结果项目分解：结果项目也没有有形的、结构性的可交付成果，它的输出是一个过程的结果，过程产生一个产品或一个结论：癌症研究、新药物开发等。该工作分解是一系列可接受的步骤。P-20当前20页，总共29页。4.4创建工作分解结构验证分解正确性“百分之百规则”：一个WBS元素的下一层分解必须百分之百地表示上一层元素.

WBS必须与工作任务的实际执行过程相一致，WBS首先应当服务于项目组，可能的话再考虑其他目的。一个工作包只能在WBS中出现一次每项工作由一个人负责能非常清楚要做什么么？能准确地估计实施这个行动所需要的资源吗？能准确地估计实施实施行动所需的时间么？每一个WBS项必须有准确描述工作包的80小时原则运用MECE法，检查是否有遗漏或重复的工作

MECE分析法，全称

MutuallyExclusiveCollectivelyExhaustive，中文意思是“相互独立，完全穷尽”。也就是对于一个重大的议题，能够做到不重叠、不遗漏的分类，而且能够借此有效把握问题的核心，并解决问题的方法。

P-21当前21页，总共29页。编码不仅把不同的项目单元区别开，而且要保留它所有特征，如所属的子项目，所属区域、专业功能、要素等。在项目实施过程中的网络分析，成本管理、数据的储存、分析、统计都靠编码识别。当前22页，总共29页。4.4创建工作分解结构责任矩阵

责任矩阵是以表格形式表示完成工作分解结构中工作细目的个人责任的方法。制定责任矩阵的主要作用是将工作分配给每一个成员后，通过责任矩阵可以清楚地看出每一个成员在项目执行过程中所承担的责任。责任矩阵表头部分填写项目需要的各种人员角色，而与活动交叉的部分则填写每个角色对每个活动的责任关系，从而建立“人”和“事”的关联。不同的责任可以用不同的符号表示。例如P（Principal）表示负责人；S（Support）表示支持者或参与者；R（Review）表示审核者。用责任矩阵可以非常方便地进行检查责任检查：横向检查可以确保每个活动有人负责，纵向检查可以确保每个人至少负责一件“事”。在完成后续讨论的估算工作后，还可以横向统计每个活动的总工作量，纵向统计每个角色的投入的总工作量。当前23页，总共29页。当前24页，总共29页。。当前25页，总共29页。4.5核实范围和控制范围核实范围

核实范围是项目干系人（发起人、客户和顾客）最终认可和接受项目范围的过程。项目干系人可以通过检查的方式（测量、检验和测试等）来核实项目工作的完成情况，从而决定是否接受项目。

输入工具与技术输出项目管理计划检查验收的可交付成果需求文件变更请求需求跟踪矩阵项目文件（更新）确认的可交付成果当前26页，总共29页。4.5核实范围和控制范围范围核实发生在项目的阶段点上（如果项目在合同的方式下进行，合同中一般会规定检查的时间和地点。），即每个项目