PMP系列笔记 项目范围管理

PMP笔记1：SOW：Statement of Work工作说明书

SOW：Statement of Work工作说明书
SOW通常作为合同的一部分，对提供的产品或服务进行表述。SOW在很高层次上说明项目的用途、范围与途径。实际上，SOW是客户与供应商之间的高层共识，将帮助沿着正确的方向安排策划工作，是WBS的基础。
SOW通常包括：对项目技术的目标与宗旨的描述，必须满足的成本和进度方面的约束，实际存在的资源约束，以及客户与供应商在开始时应该理解的有关假定。
1、范围陈述（系统的目的与范围陈述）
2、约束陈述（包括开发和实施知识管理体系的成本预算、完成的时间、具体质量陈述等）
3、责任陈述（包括知识获取和工具选择的责任问题）
4、要求陈述（比如客户要求）
5、交付使用陈述（比如陈列、培训、文件）；签名（包括项目经理、项目发起人、客户）等

SOW的三个特征：
1、SOW是一份简短的文档。它既不是一份设计文档，也不是一份完整的法律合同。它应该是在高层商抓住要点。SOW的作用是奠定工作范围、开始定义最终产品。
2、保证客户与高层管理者能充分评审并批准SOW，然后才有可能切实地着手进行项目的其他活动。
3、一份SOW获得批准、便应对这份文档进行版本控制，并将它作为项目计划的一部分。

作说明书（SOW）模板

 

工作说明书主要包括以下内容

 

前言、服务范围、方法、假定、服务期限和工作量估计、双方角色和责任、交付资料、完成标准、顾问组人员、收费和付款方式、变更管理等。

 

前言

 

对项目背景等信息作简单描述。

 

项目工作范围

 

详细描述项目的服务范围，包括业务领域、流程覆盖、系统范围及其他等。

 

项目工作方法

 

项目拟使用的主要方法。

 

假定

 

项目进行的假定条件，具体内容需双方达成。

 

工作期限和工作量估计

 

项目的时间跨度和服务期限，对于按人天计算费用的项目，需评估服务工作人天，并估算项目预算。

 

双方角色和责任

 

分为供应商的职责和公司的职责，并对关键角色的工作职责进行描述“如：项目经理”。

 

交付件

 

列出项目的主要交付资料，并对交付件的内容与质量要求进行描述。

 

完成以及验收标准

 

列出项目的完成标准和阶段完成标准，完成标准作为项目验收的依据内容。

 

服务人员

 

请列出供应商的人员名单，及顾问资格信息。供应商人员的变更：描述在什么情况下可进行供应商人员的变更。

 

聘用条款

 

对聘用供应商人员的级别要求、经验要求及其他相关条款。

 

收费和付款方式

 

项目的付款方式、费用范围、涉税条款等。

 

变更管理

 

项目变更的管理过程、相关规定与约束条件等。

 

承诺

 

双方承诺均已阅读，理解并同意遵行上述协议书及其条款的约束。而且双方同意，所提到的服务条款及其附件(包括工作说明书和变更授权以及任何为双方协议中独立完整的陈述)，取代所有的建议书或其它在此之前的书面或口头协议以及有关的其他交流。

 

保密

 

遵守保密协议（保密条款另行签署）

 

签署接受

 

XXXXXXXXXX公司（供应商） xxxxxxxxxxx公司（发包商）
授权签名：_______________ 授权签名：_________________
姓名：_________ 日期：______ 姓名：_________ 日期：______
职位：___________ 职位：___________

 

  回复 引用

订阅 TOP

    PMP笔记2：项目管理过程概述

项目管理是通过利用项目管理知识、技能、工具和技术将输入（资源等）创造出结果，以实现项目目标。
过程组：启动、规划、执行、监控、收尾，和戴明环PDCA类似。
大型项目可以分阶段或子项目进行，每个阶段/子项目都有自己的过程组。
应付PMP考试来说：精读术语表；以讲义为Index深化PMBOOK；精读标识、考前强化记忆、Review Error。
从过程分布可以看出PMP长于计划（IPMP长于流程），但考试却考虑均衡，这本身就意味着PMP考试与实践的脱节。



一、启动
1、项目章程：项目目标、初步的项目范围、资源投入、建设和制约因素；项目经理得以任命、权利得以保证；项目章程由Sponsor或PMO颁发。（INPUT：合同、项目工作说明书、事业环境、OPA）
2、项目初步范围说明书，这个主要是为验收提供依据，不是必须的；为项目提出粗略定义，包括可交付成果的要求、产品要求、项目边界、验收方法和高层范围控制。

二、规划
识别依赖关系、要求、风险、机会，明确范围、进度和费用（滚动规划）。项目团队应创造利于利害关系者做出贡献的环境。
项目管理计划（计划的计划）和沟通管理计划有自己明确的内容，其他“管理计划”基本为方法论。
项目规划从“制定项目管理计划”开始到出最后的“进度表制定”结束，中间可能涉及20个过程，下面分4大类展开：
1.1、范围规划：范围管理计划（方法论，如何确定、核实和控制项目范围）
1.2、范围定义：范围说明书（产品范围＋项目范围，跨知识域的更新需要走“变更”流程）
1.3、制作WBS：根据可交付成果进行分解
2.1、活动定义：可交付成果需要的具体活动
2.2、活动排序：识别活动间的逻辑关系
2.3、活动资源估算：活动需要的资源类型和数量（含设备、人力资源，不含费用）
2.4、活动持续时间估算：活动需要的单位工作时间
2.5、进度表制定：分析活动顺序、持续时间、资源要求及进度制约，形成进度表（甘特图）
3.1、费用估算：估算活动（工作包）所需各种资源的费用
3.2、费用预算：资金计划（汇总费用估算、储备资金、制定费用基准）、形成资金分配表
3.3、质量规划：质量管理计划（方法论：明确方针、设立过程，识别质量标准与项目关系）
3.4、人力资源规划：识别项目角色、责任、报告关系；制定人员配备管理计划
3.5、沟通规划：识别信息、传递信息（利害关系者）
3.6、采购规划：确定采购战略，形成采购管理计划
3.7、发包规划：具体采购战术，形成RFP
4.1、风险管理规划：风险管理计划（方法论、模板）－如何对待、规划和执行项目风险管理活动
4.2、风险识别：风险登记册－识别风险
4.3、定性风险分析：风险分级
4.4、定量风险分析：高优先级的进行货币损失评估
4.5、风险应对规划：增加机会、规避风险的行动方案

三、执行
按计划整合并实施项目活动、协调人与资源、处理项目范围说明书中明确的范围、实施经过批准的变更。
偏差来源：活动持续时间、资源生产率与余缺、未曾料到的风险
偏差影响：偏差分析－变更－项目管理计划－新基准
1、指导与管理项目执行：可交付成果、变更、工作绩效信息
2、实施质量保证：验证过程、树立信心
QA：Quality Assurance质量保证：对工序、工艺、方法进行验证，管理有效性的验证
QC：Quality Control质量控制：对成果进行检验、消除未达标原因
3、组建项目团队：将配置的人力资源组成工作团队
4、建设项目团队：改善能力和团队合作、提升绩效
5、信息发布：按流程向利害关系者广播信息
6、询价：价格、方案和供应商反馈
7、卖方选择：开标、商务谈判、合同

四、监控
Monitor：仪表盘，Control：油门＋刹车
观察项目执行、及时发现潜在问题并在必要时进行纠正。
1、监控项目工作：根据项目管理计划和实施基准，识别风险、绩效等
2、整体变更控制：变更、纠正/预防/补救措施
1、范围核实：验收可交付成果
2、范围控制：WBS、范围基准
3、进度控制：进度模型数据、进度基准、活动清单和属性
4、费用控制：对造成偏差的因素施加影响、控制项目预算变更（发现缺陷、消除成因）
5、质量控制
6、项目团队管理：跟踪绩效、解决问题
7、绩效考核：收集和发布绩效信息形成绩效报告，含状态、进展和预测（干的怎么样？花的代价？），是支持监控工作的一种手段
8、利害关系者管理：问题统一出口
9、风险监控：跟踪风险、评估资源、实施应对计划并评价其有效性
10、合同管理：管理合同内容和合作关系

五、收尾
正式结束项目/项目阶段的所有活动，交付完成的成果。
1、    项目收尾：乙方内部关闭项目的全部动作，总结、评估、释放人力资源、交付成果。
2、    合同收尾：关闭与甲方合同关系的动作。

 

    PMP笔记3：项目范围管理

项目范围管理
项目范围管理:确保包括了“项目成功”所需的全部工作（不多也不少）。
1、    范围规划：输出项目范围管理计划，记载如何确定、核实与控制项目范围和制定WBS。
2、    范围定义：输出详细的项目范围说明书，作为将来项目的决策依据。
3、    制作WBS：将项目中大的可交付成果和项目工作划分为较小易管理的组成部分，同时输出范围基准。
4、    范围核实：正式验收已经完成的项目可交付成果。
5、    范围控制：控制项目范围的变更。

对比：
产品范围：产品、服务和成果的功能和特征；是否完成以产品要求（需求）作为衡量标准（甲方思维的交付成果）
项目范围：为提供具有规定特征与功能的产品、服务或成果而需要完成的工作。是否完成以项目管理计划、项目范围说明书、WBS和WBS DICT作为衡量标准（乙方思维、做哪些工作，含业务工作和管理工作）。

下面重点是关于WBS：
对于大型项目来说化解风险最根本的一条是将大的项目分解成为很多个相对独立的部分，而后分别完成每一部分，将风险控制在一定范围内。WBS总是处于计划过程的中心，也是制定进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础。WBS同时也是控制项目变更的重要基础。项目范围是由WBS定义的，所以WBS也是一个项目的综合工具。

WBS具有4个主要用途：
    WBS是一个描述思路的规划和设计工具。它帮助项目经理和项目团队确定和有效地管理项目的工作。
    WBS是一个清晰地表示各项目工作之间的相互联系的结构设计工具。
    WBS是一个展现项目全貌，详细说明为完成项目所必须完成的各项工作的计划工具。
    WBS定义了里程碑事件，可以向高级管理层和客户报告项目完成情况，作为项目状况的报告工具。


WBS每下降一层就代表对项目工作更加详细的定义和描述。项目可交付成果之所以应在项目范围定义过程中进一步被分解为WBS，是因为较好的工作分解可以：
    防止遗漏项目的可交付成果。
    帮助项目经理关注项目目标和澄清职责。
    建立可视化的项目可交付成果，以便估算工作量和分配工作。
    帮助改进时间、成本和资源估计的准确度。
    帮助项目团队的建立和获得项目人员的承诺。
    为绩效测量和项目控制定义一个基准。
    辅助沟通清晰的工作责任。
    为其他项目计划的制定建立框架。
    帮助分析项目的最初风险。

WBS的最低层次的项目可交付成果称为工作包(WorkPackage)，具有以下特点：
    工作包可以分配给另一位项目经理进行计划和执行。
    工作包可以通过子项目的方式进一步分解为子项目的WBS。
    工作包可以在制定项目进度计划时，进一步分解为活动。
    工作包可以由惟一的一个部门或承包商负责。用于在组织之外分包时，称为委托包(CommitmentPackage)。
    工作包的定义应考虑80小时法则(80-HourRule)或两周法则(Two Week Rule)，即任何工作包的完成时间应当不超过80小时。在每个80小时或少于80小时结束时，只报告该工作包是否完成。通过这种定期检查的方法，可以控制项目的变化。

1.    创建WBS的方法
创建WBS是指将复杂的项目分解为一系列明确定义的项目工作并作为随后计划活动的指导文档。创建WBS的方法主要有以下几种：
a.使用指导方针。一些像美国国防部(DOD)的组织，提供MIL-STD之类的指导方针用于创建项目的WBS。
b.类比方法。参考类似项目的WBS创建新项目的WBS。
c.自上而下的方法。从项目的目标开始，逐级分解项目工作，直到参与者满意地认为项目工作已经充分地得到定义。该方法由于可以将项目工作定义在适当的细节水平，对于项目工期、成本和资源需求的估计可以比较准确。
d.自下而上的方法。从详细的任务开始，将识别和认可的项目任务逐级归类到上一层次，直到达到项目的目标。这种方法存在的主要风险是可能不能完全地识别出所有任务或者识别出的任务过于粗略或过于琐碎。

2．创建WBS的基本要求
a.某项任务应该在WBS中的一个地方且只应该在WBS中的一个地方出现。
b.WBS中某项任务的内容是其下所有WBS项的总和。
c.一个WBS项只能由一个人责任，即使许多人都可能在其上工作，也只能由一个人负责，其他人只能是参与者。
d.WBS必须与实际工作中的执行方式一致。
e.应让项目团队成员积极参与创建WBS，以确保WBS的一致性。
f.每个WBS项都必须文档化，以确保准确理解已包括和未包括的工作范围。
g.WBS必须在根据范围说明书正常地维护项目工作内容的同时，也能适应无法避免的变更。


3．WBS的表示方式
WBS可以由树形的层次结构图或者行首缩进的表格表示。
在实际应用中，表格形式的WBS应用比较普遍，特别是在项目管理软件中。


4．WBS的分解方式
WBS的分解可以采用多种方式进行，包括：
a.按产品的物理结构分解。
b.按产品或项目的功能分解。
c.按照实施过程分解。
d.按照项目的地域分布分解。
e.按照项目的各个目标分解。
f.按部门分解。
g.按职能分解。


5．创建WBS的过程
创建WBS的过程非常重要，因为在项目分解过程中，项目经理、项目成员和所有参与项目的职能经理都必须考虑该项目的所有方面。制定WBS的过程是：
a.得到范围说明书(ScopeStatement)或工作说明书(StatementofWok，承包子项目时)。
b.召集有关人员，集体讨论所有主要项目工作，确定项目工作分解的方式。
c.分解项目工作。如果有现成的模板，应该尽量利用。
d.画出WBS的层次结构图。WBS较高层次上的一些工作可以定义为子项目或子生命周期阶段。
e.将主要项目可交付成果细分为更小的、易于管理的组分或工作包。工作包必须详细到可以对该工作包进行估算(成本和历时)、安排进度、做出预算、分配负责人员或组织单位。
f.验证上述分解的正确性。如果发现较低层次的项没有必要，则修改组成成分。
g.如果有必要，建立一个编号系统。
h.随着其他计划活动的进行，不断地对WBS更新或修正，直到覆盖所有工作。
检验WBS是否定义完全、项目的所有任务是否都被完全分解可以参考以下标准：
i.每个任务的状态和完成情况是可以量化的。
j.明确定义了每个任务的开始和结束。
k.每个任务都有一个可交付成果。
l.工期易于估算且在可接受期限内。
m.容易估算成本。
n.各项任务是独立的。


6．WBS的使用
对WBS需要建立WBS词典(WBSDictionary)来描述各个工作部分。WBS词典通常包括工作包描．述、进度日期、成本预算和人员分配等信息。对于每个工作包，应尽可能地包括有关工作包的必要的、尽量多的信息。
当WBS与OBS综合使用时，要建立账目编码(Code ofAccount)。账目编码是用于惟一确定项目工作分解结构每一个单元的编码系统。成本和资源被分配到这一编码结构中。
WBS、OBS、RBS、职责分配矩阵比较：
WBS 是工作分解结构，下面都是工作包，都是成果，不包括具体人员、具体资源信息；
OBS 是组织分解结构，里面是部门、单位或团队, 不包括具体工作内容、工作职责，工作职责通常在职责说明书里面；
RBS 是资源分解结构，包括人的信息，因为人也是资源，不过不包括工作内容和所属部门。
职责分配矩阵，是把WBS和OBS结合起来，显示工作包和团队成员之间的关系。

7．WBS的实践经验
WBS字典：超大型项目需要，WBS字典有助于追踪所有的概要和详细的活动，包括一个简短的说明、WBS数字标识符（1.1、1.1.1、1.1.2等）和预计的努力。如果你把WBS字典输入到一个专门的工具中，这个工具还有助于追踪WBS的变化。
让最后的详细活动以行动为导向：WBS中的详细活动（不能进一步分解的活动）最终会转移到你的进度表中；因此，如果WBS中的详细活动以行动为导向会更加方便。

典型的WBS实践流程：
1、制定工作产品清单（PL）。工作产品（Working Product）是项目需要产出的工作结果，可以是项目最终交付成果的组成部分，也可以是项目中间过程的产出结果。以软件开发为例，软件中的用户管理模块是最中软件产品的一部分，软件的需求分析文档是软床过程中的文件，都是软件开发这个项目的工作产品。工作产品有大有小，有的相互关联，有隶属的关系。列出工作产品清单的过程，可以是头脑风暴的方法，项目组共同完成。
2、制定工作产品分解结构（PBS）。工作产品大大小小列出了很多，大型项目有几百项，几千项。工作这些工作产品的属性和关系，用结构化的方法组织这些工作产品，形成一个自顶向下的逐级细分的工作产品分解结构（PBS：Product Breakdown Structure）。这就是制造业内的产品物料表（BOM），说明一个产品有多少个零件组成。
3、制定工作任务分解结构（WBS）。有了PBS，只要把获得工作产品的任务明确，就可用根据PBS的结构，得到WBS了。注意同样的PBS，可用有不同的WBS，因为获得同样工作产品的任务可以是不同的。例如软件开发中的用户管理模块，是PBS中的工作产品，对于到WBS中，可以是不同的任务，一种是采购一个用户管理模块，另一种可以是项目小组开发一个用户管理模块。
4、制定组织分解结构（OBS）。WBS中的任务确定了，完成任务的责任人也就可以明确了。因此由WBS则可以形成整个项目的组织分解结构，由那些人来完成项目的任务，得到工作产品，并完成项目。
其中的关键是分解的结构，PBS、WBS和OBS是同一个结构，只是从不同的角度来阐述这个结构。关于这个结构的分解方法，常用的有组件分解方法和过程分解方法。典型的组件方法就是制造业中把一个完整的产品，逐级分解到零件。典型的过程分解方法可以是软件开发从需求到设计、编码、测试的一个过程。项目分解中，这两种方法往往交替使用，其最终是把项目分解到一个个具体和细小的工作任务。