郑重声明
此份资料仅作为网友参考、以及备考PMP之用，严禁用做商业用途！他人若被PMI发现用于商业用途，责任自负！
                                                               

第一章 项目管理框架部分
【本章知识重点】
★　项目及其特点；
★　项目和运营的相同点与不同点。
★　项目管理及其几个过程；
★　Program / project / subproject的区别与关系。

【电子笔记】

1.1 项目管理知识体系（PMBOK）
PMBOK是美国项目管理学会（PMI）提出的一个涵盖面很广的项目管理知识体系，内容包括项目管理（Project Management）这一职业的知识总和。PMBOK不是教科书，它并没有详细地解释知识体系中的那些术语，它只提供了项目管理的一种正确思路和管理技能与知识。
PMBOK是以西方人的思维方式，尤其是美国人的思维方式来看待项目管理问题的，所以我们在学习过程中要习惯他们考虑问题的思路。PMI一直不遗余力地促使为项目经理放权，期望创造一个良好的环境给项目团队。PMI很重视历史资料和检验教训，PMBOK知识体系将这些信息作为数据库的一部分，供项目以及执行组织的其它项目使用。数据库是知识管理的基础。
项目管理是管理偶然性的职业。我们成为PM（Project Manager）通常都是偶然的。组织任命某人为PM，有时只是对其技术绩效的嘉奖。

1.2 什么是项目？
项目 (Project)的定义：为创造某项独特产品、服务或结果所做的一次性努力。

 日常运作 项目
共同点 1. 由人来做； 2. 受制于有限的资源； 3.需要规划、执行和控制
区别 持续不断 (Repeat)
重复进行 (Ongoing) 独特性 (Unique)
一次性 (Temporary)

1.2.1 一次性( Temporary )
一次性是指每个项目都有确定的(Definite)开始和确定的结束。当项目目标达到时，项目也就结束了。如果项目目标明显无法完成时，一般来说项目会终止。一次性一般不适用于项目所产生的产品或服务。项目经常会产生比项目本身更久远的，事先想到或未曾料到的社会、经济和环境影响。

1.2.2   独特( Unique )
项目所进行的都是以前没有进行过的事情，因而是独特的。一项产品或服务尽管其所属的类别范围很大，依然会是独特的。例如办公楼已经建造了成千上万座，但其中每一座都是独特的：不同的业主、不同的设计、不同的地点、不同的承建人等等。

1.3 什么是项目管理( Project Management )？
项目管理：就是将各种知识、技能、工具和技术应用于项目之中，用来满足或超过项目干系人对项目的要求和期望。项目管理是通过诸如启动、规划、实施、控制、收尾5个过程进行的。
                       
1.5  Program / project / subproject的区别与关系
大型项目 ( programs )： 是以协同的方式获取单独管理所无法取得之效益的一组项目。许多计划还包括持续营运部分。
子项目 ( sub-programs )： 项目常常被划分为若干个较易管理的组成部分，称为子项目。子项目又常常分包给外部的承包商或内部的其它职能单位。子项目一般被视为项目，并按项目进行管理。
第二章 项目管理的环境
【本章知识重点】
★　项目生命周期及其特点；
★　项目生命周期和产品生命周期的定义与区别；
★　项目干系人的定义、冲突如何解决？
★　组织结构（每种组织的优缺点、项目经理的权限与称呼）。

【电子笔记】

2.1  项目阶段与项目生命周期
2.1.1  项目阶段 ( phase )
每个项目阶段都以一个或数个可交付成果的完成作为其标志。项目阶段的结束通常以对关键可交付成果和迄今为止的项目实施情况的审查( Review )作为其标志，目的是：
（1）确定项目是否应当继续实施，并进入下一阶段( Go / no go )；
（2）以最低的成本纠正错误与偏差( Corrective Action)；
（3）经验教训( Lessons Learned )。
阶段末审查往往称为：阶段放行口( Phase Exit )、阶段关卡( Stage Gates )、验收站( Kill Points )。

2.1.2  项目生命周期 ( Project Life Cycle )
定义：总体上连续的各个项目阶段的全体，项目阶段的数量和名称由参加项目的机构的控制需要所决定。或者说：一个项目按一定的逻辑与顺序方式连续地通过一系列时间期间的全集。
项目生命周期用于界定项目的开始和结束。它最简单的形式包括以下四个阶段：
1. 概念阶段 ( Concept ) ：     选择并定义需要解答的项目概念；
2. 开发阶段 ( Development )：  检验概念并由此开发出一个切实可行的实施计划；
3. 执行阶段 ( Implementation )：将实施计划付诸实施；
4. 结束阶段 ( Termination )：   项目过程完成并归档，最终产品交付业主管理、保管与控制。

 开始 继续 收尾

人力、成本投入 较低 逐渐升高 迅速下降
成功的完成项目的可能性 最低 逐渐升高 最高
风险、不确定性 最高 逐渐下降 最低
风险的影响 最小 逐渐升高 最大
干系人的影响 最大 逐渐下降 最小

项目生命周期的定义是项目成功的关键一步。项目所处的阶段越早，项目不确定性就越大，项目调整或变更的代价比较低。但随着项目的进行，不确定性逐渐减小，而变更的代价、付出的人力、资源逐渐增加，就会增加决策的困难度。

项目生命周期和产品生命周期的定义与区别
概念 开发 执行 结束  运营、维护 升级 …… ……. 报废
←-----项目生命周期-----→  ←------运营期 ( Operation Life Cycle )-----→
←------产品生命周期  ( Product Life Cycle ) ------→
2.2  项目干系人 ( Stakeholder )
定义：积极参与项目、或其利益因项目的实施或完成而受到积极或消极影响的个人和组织。项目干系人对项目及其结果也会施加影响。
项目团队必须弄清谁是干系人，确定他们的要求，然后对这些要求进行管理和施加影响，确保项目取得成功。每个项目都包括的关键项目干系人有：
★项目经理（PM）    ★顾客（Customer）    ★项目实施组织 (Organization)
★项目班子成员 (Project Team)     ★赞助人 (Sponsor)
管理项目干系人的期望是件困难的事，因为干系人的目标往往彼此相距甚远，甚至互相冲突。通常，解决干系人之间的不同意见应该服从客户的需求为主。但是这并不等于可以或者应该不考虑其它干系人的需求和期望。在这种分歧意见中找到恰当的解决办法是项目管理所面临的一项重要挑战。

2.3   组织的影响
实施项目组织的结构往往对能否获得项目所需资源和以何种条件获取资源起着制约作用，大多数现代组织在不同层次上要用到所有下列这些组织结构。
PMBOK定义了几种组织结构，分别是：职能型组织、矩阵型组织、项目型组织 ，矩阵型组织是PMP考试的一个重点，在美国，很多项目都是在矩阵型组织中进行的。

 优 点 缺 点
职能型
组织 
1. 每个雇员都有一个明确的上级

2. 雇员按专业划分，在组织内组成比较专业化的部门。

3. 项目成员可以得到部门的技术支持，成员的技能可以不断提高；

4. 项目成员有“家（稳定的工作位置）”，有安全感。 
1. 部门职能利益高于项目利益，部门更加强调技术的专业而不是项目目标；

2. 缺乏明确的责任人，客户可能找不到联络点，防碍客户参加进项目管理中；

3. 项目间的跨部门沟通比较困难，职能部门之间的利益冲突会防碍信息的流动；

矩阵型
组织 
1. 最大限度地使用公司资源，几个项目可以分享组织的稀有资源；

2. 利于横向、纵向沟通；

3. 改善了跨职能部门的协调

4. 项目经理责任制，项目目标非常明确。
 
1. 项目成员面对双重/多头领导；

2. 职能经理不太可能将最好的资源给项目。当多个项目一起争资源时，分享稀缺资源会造成较多的冲突；

3. 沟通途径比职能型组织顺畅，但对于涉及很多成员时，反应速度会慢；

4. 矩阵型组织的运营成本大，需要大量的程序。
项目型
组织 
1. 项目经理有相当大的独立性和权限，项目经理对项目尽心尽职；

2. 组织简单，项目内的人员职责清晰、沟通容易、反映速度快；

3. 熟练的人员可以派到类似的项目中。 
1. 组织结构缺乏稳定性，项目团队成员没有“家（稳定的工作位置）”的感觉；

2. 项目管理成本高，资源配置效率低；

3. 侧重面对项目的决策，而对技术执行情况考虑较少。

           组织形式
 项目特征 职能式 矩阵式（Matrix） 项目式
  弱矩阵 平衡矩阵 强矩阵 
项目经理权限 很少或没有 有限 少到中等 中等到大 很高，甚至全权
项目经理的角色 半职 半职 全职 全职 全职
项目管理人员的头衔 项目协调员
项目联络员 项目协调员 项目经理 项目经理 项目经理
项目管理的行政人员 半职 半职 半职 全职 全职

项目联络员（Expeditor）：在职能型组织中起沟通、联络作用，没有决策权。
    项目协调员（Coordinator）：在职能型组织中有一定的决策权，他可以接触项目成员的上级经理。
弱矩阵（Weak Matrix）、平衡矩阵（Balanced Matrix）、强矩阵（Strong Matrix）是矩阵型组织的三类细分，它们的区别主要是职能经理与项目经理之间的权力大小。职能经理与项目经理之间的权力基本相等时是平衡矩阵，两个极端分别是弱矩阵和强矩阵。
还要注意的一个术语是紧密矩阵（Tight Matrix），它是强矩阵一种名称，意味着项目小组成员的地理位置临近，对信息沟通和团队建设有利。

2.3.4   项目管理办公室
项目办公室有许多种用途。项目办公室的运作范围极其广泛，从为项目经理提供各种支持，包括培训、软件、模板，直到为项目的结果负责。

2.4 主要的通用管理技能

硬技巧（方法、过程、技能） 软技巧（人员管理）
计划、跟踪、控制、报告 领导、团队建设、冲突管理、激励、培训、协商、沟通、聆听

一些定义：
谈判 涉及到与他人协商以取得共识或达成协议。协议可以直接谈判,或在外界协助下谈判；调停和仲裁是两种借助外界的谈判形式。
解决问题 涉及到问题定义与相应对策两者的结合。
权力 对行为施加影响，改变事件进程，克服阻力让人们干他们本来不想干事情的潜力。
政治 争取各个利益迥异的群体采取集体行动的一门学问。
标准 公认的机构所批准的文件，它提出了通常的、反复使用的规则、准则或产品、过程或服务的特征，但并不要求强制遵循。
规章制度 规定产品，过程或服务特征的文件，包括相应的行政条款，其遵守具有强制性。
管理 始终如一地为项目干系人创造出他们期望的关键成果。
领导 1. 确定方向；2. 动员人员，统一意志；3. 调动与鼓舞
             

2.5  社会、经济及环境影响
2.5.2   国际化
越来越多的组织参与跨越国界的工作，因而项目也越来越多的跨越国界。除了关心传统的范围、成本、时间和质量之外，项目团队还必须考虑地域时区的差异、国家和地区节假日、面对面会谈在旅行出差上的要求、电话会议的后勤安排，以及敏感的政治分歧等因素的影响。

2.5.3   文化影响
影响的范围包括：政治、经济、人口、教育、伦理、种族、宗教和其它影响人际与组织间交往方式的做法、信念与态度。

目标管理（MBO）：通过设定具体的，可以计量的目标，从而定义个体的管理职责的方法。
目标管理是Peter Drucker在二十世纪五十年代初提出的，是一种技术用以在有规律的基础上建立清晰的、可达到的目标并且评估向着这些目标的进展情况。
需要得到管理层的支持，对一个项目进行目标管理才是可行的。
第三章 项目管理的过程
【本章知识重点】
★　项目管理生命周期及其特点；
★　项目管理的领域、过程；

【电子笔记】

项目管理：一项综合努力，在一个领域采取行动，或未能采取行动，通常会影响其它领域。
这些交互作用可能一目了然，易于理解，也可能极其微妙，难以捉摸。例如，项目范围的改变总要影响项目的成本，但并不一定影响到班子的士气或者产品的质量。
许多项目管理人员将项目的三重制约称为评估相互冲突需求的框架。PMBOK一般把项目的成本、进度、质量作为项目的三个目标，而三重制约指项目的范围、成本、进度。
满足或超过项目干系人的期望就是成功的项目。导致项目失败的几个主要原因：
1  项目范围或需求不清晰；
2  项目范围或需求波动过大；
3  项目实施者与客户之间缺乏沟通或存在误解，导致无法定位和解决潜在问题；
4  项目资源缺乏完成项目所必须的知识；
5  项目经理和投资方在管理项目时缺乏相关的经验；
6  不可实现的期望值；
7  对项目所依赖的外部因素无法控制；
8  对项目干系人的责任、参与和期望无法控制；

3.1  项目的诸过程
项目由过程组成。过程（Process）：就是“产生某种结果的一系列行动”

3.2  过程组
 项目管理诸过程可归纳为五个过程组，每组包含一个或多个过程。
   启动过程：授权批准项目或阶段。
 规划过程：定义与斟酌各项目标，并在多项可行的行动方案中选择实现项目目标的               最佳方案。
 执行过程：协调人力与其它资源，以便执行计划。
 控制过程：定期监测与量度进展情况，识别有否偏离计划之处，必要时采取纠正措 施，以确保实现项目目标。
 收尾过程：正式验收项目或阶段，并井井有条的结束项目。      
   

完成项目当前阶段所需完成的工作细节，而且要为后续阶段要完成的工作做出初步描述。对项目计划的这种逐步深入的描述方式通常称为滚动波式规划。
  让项目的干系人参与项目的各个阶段通常有助于提高满足客户要求的可能性，并实现干系人对项目的认同乃至同意提高分享项目的所有权，这点对于项目的成功往往至关紧要。

3.3  过程的交互作用 
3.3.2   规划过程
    对项目来说，规划过程是最重要的，因为项目的独特性决定了项目所从事的工作都是过去从未做过的事情。因此，项目管理的规划过程就要相对多一点。规划是贯穿于整个项目生命周期的持续努力。
核心规划过程：规划过程中的某些过程具有明显的依赖性，在大多数项目中都要求按基本相同的顺序进行。这些核心规划过程在项目的任何一个阶段需要反复重复。

辅助过程：其它规划过程间的交互作用更明显的取决于项目的性质。

项目经理是一个集成者（Integrator），需要对大多数项目决策负责。作为一个集成者，项目经理必须控制每一个计划编制、绩效监控和问题解决。至于适当的权衡决策，项目经理必须收集所有项目信息并能够应用专家判断。

项目管理过程与过程组知识领域的相互关系

 启动 计划编制 实施 控制 收尾
项目
综合管理  4.1项目编制 4.2项目计划实施 4.3整体变更控制 
项目
范围管理 5.1
启动 5.2范围计划
5.3范围定义  5.4 范围核实
5.5 范围变更控制 
项目
时间管理  6.1活动定义
6.2活动排序
6.3历时估算
6.4进度编制  6.5进度控制 
项目
成本管理  7.1资源编制
7.2成本估算
7.3成本预算  7.4成本控制 
项目
质量控制  8.1质量编制 8.2质量保证 8.3质量控制 
项目人力
资源管理  9.1组织编制
9.2人员获取 9.3团队发展  
项目
沟通管理  10.1沟通编制             10.2信息分发 10.3绩效报告 10.4行政收尾
项目
风险管理  11.1风险编制
11.2风险识别
11.3风险定性分析
11.4风险定量分析
11.5风险应对编制  11.6
风险监测与控制 
项目
采购管理  12.1采购编制
12.2询价编制 12.3询价
12.4供方选择
12.5合同管理  12.6合同收尾

项目各项活动的责任部门/人
谁负责制定项目计划？
由项目团队制定，项目经理进行综合集成。 谁是项目可交付成果的主要责任人？
项目团队成员（个人）
谁负责同意、拒绝变更请求，决定基准变更？
变更控制委员会（CCB） 谁负责项目章程的批准？
项目以外的，级别与项目需要相称的经理
谁负责核实项目范围？
所有关键的项目干系人（发起人、客户、顾客等） 谁负责确定项目成本偏差可接受的范围？
项目经理
谁负责将合同收尾的正式通知提供给卖方？
合同管理负责人 谁负责设计与规范的基本责任？
项目工程师
谁负责承担项目风险和风险管理中的主要风险？
项目发起人
 谁对项目的风险负责？
项目经理

谁对项目实施中各项活动的质量一致性负责？
质量经理
 谁对项目中部门的风险负责？
职能经理

第四章 项目综合管理
【本章知识重点】
★　假设、约束：（两者之间的定义与区别）
★　项目计划：（定义、作用、内容、制订人）
★　项目计划和绩效基线
★　工作授权体系 → 控制“镀金”
★　工作结果和可交付成果：（两者之间的定义与区别）
★　变更申请
★　综合变更控制
★　变更控制系统
★　配置管理：（配置管理与变更控制系统之间的定义与区别）

【电子笔记】

项目综合管理：为保证项目各组成部分恰当协调而必须进行的过程。
项目综合管理就是在各个相互冲突的目标与方案之间权衡取舍，以达到或超过项目干系人的要求与期望。项目经理对项目综合管理负责。
以下是项目综合管理的三个过程。
     4.1  项目计划制订：综合协调所有项目计划，形成一份前后一致的连贯文件。
     4.2  项目计划实施：通过实施列入计划的各项活动实施项目计划。
     4.3  综合变更控制：协调整个项目的变更。
                   
4.1 项目计划制订 ( Project Plan Development )
项目计划：是经批准的正式文件，用于管理项目的实施。
项目计划制订要动用包括战略计划在内的其它计划过程的产出，来制定一份可用以指导项目实施和项目控制的，前后一致、条理清晰的文件。此项过程几乎总是需要反复进行若干次。
所有已规定的工作都必须用EVM（挣值管理）过程中的详尽综合管理控制计划（有时称为控制帐目计划，简称CAP）进行计划、估算、安排进度、并送交审批。
所有综合管理控制计划的总合构成项目的总范围。
每个学科的专家、项目团队成员、职能经理或者项目办公室对项目做出计划，而作为综合集成者的项目经理，在必要时通过权衡，把组织的管理方针和约束条件考虑进去，将它们综合成为项目计划。

4.1.1  项目计划制订的投入
1. 其它计划的产出（Other planning outputs）
除项目综合管理过程外的其它知识领域计划过程的输出都是项目计划制订的投入。
2. 历史资料 （Historical information）
现有的历史资料（例如：估算数据库、过去项目绩效记录）应在其它项目计划过程中已经查阅过。这些资料在项目计划过程中也应准备就绪，以供核实假设以及评估项目计划制订过程中提出的其它可供选择方案之用。
3. 组织方针（Organizational policies）
参与项目的组织都有正式或非正式的方针，其影响必须考虑。组织机构的几个主要方针：
 质量管理方针：过程审计，连续的改进目标。
 人事管理方针：雇佣和解雇原则，雇员表现评价。
 财务控制方针：定期报告、要求进行的开支和支付审查、会计法规、标准合同条款。
4. 制约因素（Constraints）
制约因素指适用于项目，因而影响其绩效的某项限制。
例如，事先规定的预算就是一项制约因素，它可能影响项目团队在范围、人员配备和进度方面的选择。如果项目根据合同实施，则合同条款通常是制约因素。
5. 假设（Assumptions）
假设指就计划而言被视为正确、真实或肯定的因素。
假设影响到项目计划的所有方面，是项目逐步完善化的一个组成部分。项目班子经常地识别、记载和证实假设，作为其计划过程的一部分。假设通常涉及某种程度的风险。

4.1.2  项目计划制订的工具与技术
1．项目计划方法（Project planning methodology）
项目计划方法指制订项目计划期间指导项目班子的任何一种系统方法。它可以简单到只是一些基本表格与样板，也可以复杂到要求进行一系列模拟(例如进度、风险的蒙特卡洛分析)。
大多数项目计划方法都将项目管理软件这样的“硬”工具和由外界协助召开的动员会这样的“软”工具结合使用。
2. 干系人的技能与知识（Stakeholder skills and knowledge）
每个干系人都可能具备制订项目计划所需的技能与知识。项目团队必须创造一个环境，让各干系人能恰当的作出其贡献。
3. 项目管理信息系统（PMIS）（Project management information system）
项目管理信息系统是用于搜集、综合和分发各个项目管理过程产出的工具与技术的总和。它用于支持项目从启动到收尾的所有方面，可以包括人工系统和自动化系统。
4. 挣值管理（EVM）（Earned value management）
用于综合项目范围、进度和资源，并量度与报告项目从启动到收尾的绩效的一项技术。

4.1.3  项目计划制订的产出
1. 项目计划（Project Plan）
定义：项目计划是经批准的正式文件，用于管理项目的实施。
项目计划和进度应按沟通管理计划的规定进行分发。在某些应用领域，这个文件常常称为综合项目计划。
对项目计划与项目绩效量度基准两者，应该明确加以区分：
项目计划（Project Plan）：项目计划是一份或者一组内容随时间的推移与有关项目的信息不断增多而随时更新的文件。
绩效量度基准（Performance Measurement Baseline）：绩效量度基准是一项经过核准的计划，用以在管理控制中作为量度偏差的基准。它通常仅断断续续有所改变，其原因往往是对已批准的工作范围变更或可交付成果变更作出反应。
项目计划的结构与表达有多种方式，但是一般均包括以下内容：
 项目章程。
 项目管理方法或策略的说明。（其它知识领域各项管理计划的摘要）
 范围说明书，包括项目各项目标和可交付成果。
 作为基准范围文件的工作分解结构（WBS）。
 成本估算，计划开始和完成日期（进度），以及工作分解结构（WBS），对每项可交付成果进行职责分派。
 技术范围、进度和成本的绩效量度基准（进度基准、成本基准）。
 主要的里程碑及其目标日期。
 关键的或必需的人员，及其预期成本和/或人力投入。
 风险管理计划，包括主要风险及其制约因素与假设，以及为其安排的应对与（必要的）应急措施。
 各过程的从属管理计划。
上述每项计划必要时均可列入项目计划，其详细程度因每个具体项目的要求而异。
2. 详细辅助资料（Support detail）
项目计划详细辅助资料包括：
 未纳入项目计划的其它计划过程产出。
 项目计划制订期间产生的资料或文件（例如，过去不曾知道的制约因素和假设）。
 技术文件：例如，对所有要求、规格和概念设计来龙去脉的记载。
 相关标准的文件记载。
 在项目早期制订过程中所提出的规格。
该项材料必要时需要加以整理，以便于在项目实施过程中使用。

4.2  项目计划实施
项目计划实施是实施项目计划的主要过程，项目预算的绝大部分都将使用于这一过程。
在此过程中，项目经理和项目团队必须协调和指导项目中的各个技术与组织接口。最直接地受到项目应用领域影响的恰恰是这个过程，因为项目的产品实际产生于此。
在此过程中，必须随时根据项目基准对实施绩效保持监测，以便比较实际绩效与项目计划，并以此为依据采取纠正措施。要对最终成本与进度结果进行定期预测，以支持上述分析。
    项目控制的两个基本目标：1. 将活动转化为结果；2. 管理组织资产。

4.2.1  项目计划实施的投入
1. 项目计划（Project Plan）
各个从属的管理计划以及绩效量度基准是项目计划实施的主要投入。
2. 详细辅助资料（Support detail）
3. 组织方针（Organizational policies）
参与项目的任何与所有组织都具有可能影响项目计划实施的正式与非正式方针。
4. 预防行动（Preventive action）
预防行动指减少项目风险事件潜在后果发生概率的任何行动。
5. 纠正行动（Corrective action）
纠正行动指为使项目预期的未来绩效与项目计划重新恢复一致而采取的措施。
纠正行动是各项控制过程的产出，作为此处的投入，它完成了必需的反馈环路，保证了有效的项目管理。

4.2.2   项目计划实施的工具与技术
1. 通用管理技能（General management skills）
诸如领导、沟通和谈判等通用管理技能对于项目计划的有效实施是至关重要的。
2. 产品技能和知识（Product skills and knowledge）
项目班子在项目的产品方面必须掌握一套适当的技能与知识。这套必要的技能被规定为计划的组成部分并且由人员招募过程提供。
3. 工作授权系统（Work authorization system）
工作授权系统：为确保工作按规定时间与顺序进行而采取的一套项目工作正式审批程序。其主要机制通常是对一项具体活动或者一组工作的书面动工核准书。
工作授权系统的设计应当在提供控制的价值和为其所付出的代价两者之间权衡利弊。例如，对许多较小型项目而言，口头核准一般就已经足够了。
4. 状态碰头会（Status review meetings）
状态碰头会指为交换项目的有关信息而定期举行的会议。对多数项目来说，状态碰头会举行的频繁程度和级别各不相同（例如，项目团队自己可以每周碰头一次，而与顾客则每月碰头一次）。
在构思和计划阶段，需要召开更多的会议确定目标和方法。
在项目实施阶段，由于计划和客户需求都得到了明确，可以适当减少开会次数。
在项目收尾阶段，会议的频率将增加以协调各方工作。
5. 项目管理信息系统（Project management information system）
6. 组织程序（Organizational procedures）
参与项目的任何或所有组织都可能有在项目实施期间十分有用的正式或者非正式程序。

4.2.3   项目计划实施的产出
1. 工作结果（Work results）
工作结果：为完成项目而进行的各项活动的结果。
关于工作结果的信息：哪些可交付成果已经完成，哪些尚未完成，质量标准达到了何种程度，已经发生或者已经承诺的成本等等，要作为项目计划实施的组成部分加以搜集，并馈入绩效报告过程之中。
项目的活动也往往出现无形的工作成果，例如经过培训并能有效应用所学知识的人。
2. 变更请求（Change requests）
变更请求的必要（例如扩大或缩小项目范围、修改成本或进度估计）往往是在项目工作进行的过程中才被发现的。变更请求一定是正式的。

4.3  综合变更控制
综合变更控制关注 综合变更控制要求
1. 对变更的起因施加影响，保证各方均同意变更；
2. 确认变更已经发生；
3. 在实际变更出现时对其同步进行管理。 1. 维护绩效量度基准的健全性。
2. 确保产品范围变更反映在项目范围定义中。
3. 协调跨知识领域的变更。
必须不间断的按基准对变更进行管理，以保持原先规定的项目范围、综合绩效基准、管理方法以及否决或批准新的变更并将其纳入修正后的项目基准之中。

4.3.1  综合变更控制的投入
1. 项目计划（Project plan）
项目计划提供控制变更的基准。
2. 绩效报告（Performance reports）
绩效报告提供了项目绩效信息。绩效报告还可提醒项目团队注意将来可能造成麻烦的隐患。
3. 变更请求（Change requests）
变更请求可以用多种形式提出，包括口头或者书面、直接或者间接、外部或者内部、有法律强制性的或者有选择余地的请求。但是，变更请求一定是正式的。

4.3.2  综合变更控制的工具与技术
1. 变更控制系统 ( Change Control System )
变更控制系统的组成：
1. 一组正式的、文档化的程序；
2. 包括正式项目文件变更需要经过的步骤；
3. 规定如何对项目绩效进行监测与评估。
变更控制系统包括：
1.  文书化工作；
2.  核准变更所需要表格的填写、系统追踪过程；
3.  授权进行审批的级别。
如果项目中没有合适的现成变更控制系统，项目团队就需要建立一个经过所有关键的干系人认可和同意的控制小组来负责批准或否决所提出的变更。这些小组的常见名称：配置控制委员会（CCB）、工程审查委员会（ERB）、技术审查委员会（TRB）、技术评估委员会（TAB），等等。
变更控制系统还必须包括处理未经事前审查就已实施的变更程序，可以在紧急情况下“自动”批准变更，但这些变更仍然必须形成文件，纳入档案，以便记载基准的演变过程。
2. 配置管理 ( Configuration Management )
配置管理：任何用来对以下过程实行技术和行政指导与监督的、文档化的程序：
 识别工作项或系统的功能特性和物理特性，并形成文档。
 控制上述特性的所有变更。
 记录并报告上述变更及其实施状况。
 审核上述对象与系统，核实是否符合要求。
★ 在许多应用领域，配置管理只是变更控制系统的一个子集。
★ 在其它一些应用领域，也可能指为管理项目变更而作出的任何系统管理。
★ 不能自动“批准”变更。
3. 绩效量度（Performance measurement）
挣值（EV）等绩效量度技术可以帮助评估计划的偏差是否需要采取纠正措施。
4. 补充规划（Additional planning）
项目很难会丝毫不差的按照计划实施。未来所出现的变更，可能需要重新编制或者修改成本估算、调整活动顺序与进度、调整资源需求、分析风险应对方案选择，或者对项目计划进行其它调整。
5. 项目管理信息系统（Project management information system）

4.3.3  综合变更控制的产出
1. 项目计划的更新（Project plan updates）
项目计划的更新指对项目计划或者详细辅助资料的内容所做的任何修改。必要时必须将这些修改通知有关的干系人。
2. 纠正行动（Correction action）
3. 汲取的教训（Lessons learned）
偏差产生的原因、已采取的纠正行动的理由，以及所汲取的其它教训都应形成文件，记载在案，使其成为本项目和实施组织内其它项目历史数据库的组成部分。
数据库也是知识管理的基础。

第五章 项目范围管理
【本章知识重点】
★　项目范围和产品范围：（两者之间的定义与区别）；
★　产品描述
★　项目选择方法
★　项目章程：（它的作用、内容、指派项目经理的时机和批准人）
★　范围说明、范围管理计划
★　WBS：（PMP考试的重点之一，需要理解它的各种用途）
★　帐目编码Code of accounts / 会计科目表Chart of accounts（两者间的定义与区别）
★　工作包 / WBS字典
★　WBS与其他分解结构的区别
★　范围核实 / 质量控制：（两者之间的定义与区别）
★　范围变更的原因

【电子笔记】

项目范围管理：确保项目包括成功完成项目所需的全部工作，但又只包括成功完成项目所必需的工作过程。它主要关心的是确定与控制哪些应该与哪些不应该包括在项目之内。
上述定义表明了PMI的政策，PMI提倡：“不做额外的工作（no extra），不要镀金（no gold-plating）”。
          5.1   启动：批准项目或阶段的开始。
          5.2   范围规划：制订书面范围说明，作为今后项目决策的基础。
          5.3   范围定义：将主要的项目可交付成果划分为较小，更易管理的组成部分。
          5.4   范围核实：正式认可项目的范围。
          5.5   范围变更控制：控制项目范围的变更。
    就项目而言，范围（Scope）：“项目所提供的产品或服务的总和”。这个术语可指：
 产品范围（Product Scope）：产品或服务的典型特征与功能。
 项目范围（Project Scope）：为提供具有典型特征与功能的产品或服务所需完成的工作。
项目所产生的通常是单项产品，单该项产品却可包括若干个从属部分，每个部分都具备其单独，却又相互依存的产品范围。例如一个新电话系统通常包括四个从属部门：硬件、软件、培训和实施。
项目范围是否完成以项目计划作为衡量标准；产品范围是否完成以产品要求作为衡量标准。
两种范围的管理必须良好的结合，以确保项目工作所交付的是规定的产品。

5.1 启动
启动：1. 正式批准新项目；2. 批准现有项目进入下一阶段的过程。
在有些组织中，项目需要先完成需求评估、可行性研究、计划草案拟订或其它本身也需要启动的相似分析评估之后才能正式启动。有些类型的项目，特别是内部服务项目和新产品开发项目，则先非正式启动，做一些有限的工作，以便取得正式启动所需要的赞同。
以下的一项或者多项理由，是项目批准的典型依据：
 市场需求 （例如，由于汽油短缺，某汽车公司批准制造低油耗汽车项目）。
 营运需要 （例如，某培训公司批准新设课程项目，以增加收入）。
 客户要求 （例如，电业局批准新建变电站项目，为新工业园区供电）。
 技术进步 （例如，电子公司在电脑内存改进后批准研制新视频游戏机项目）。
 法律要求 （例如，油漆厂批准制订有毒材料使用须知项目）。
 社会需要 （例如，某发展中国家的非政府组织批准向霍乱高发病率低收入社区提供饮用水系统、厕所与卫生保健教育项目）。
上述激励因素又称问题、机会、或营运要求。这些名称的中心主题是：管理部门通常必须作出如何应对的决策。

5.1.1  启动的投入
1. 产品描述（Product description）
产品描述：对项目拟创造的产品或服务的特征进行文字记载。
在早期阶段，产品描述通常比较笼统，在以后的阶段中，随着产品特征的逐步阐明，其描述也就逐渐具体化。产品描述还应该记载拟创造产品或服务与营运需要或其它促成项目的激励因素之间的关系。产品描述的形式与内容虽各不相同，但其内容永远必须充实到足以满足日后项目规划的需要。
许多项目都涉及到一方（卖方）按合同向另一方（买方）完成工作的问题。在这种情况下，一般由买方提供初步产品描述。
2. 战略规划（Strategic plan）
所有项目都应支持实施组织的战略目标，应当把实施组织的战略规划视为项目选择决策中的一个因素。
3. 项目选择的标准（Project selection criteria）
项目选择的标准通常以项目产品的价值定义，可能涉及到管理部门关心的各个方面（财务收益、市场份额、公众看法等等）。
4. 历史资料（Historical information）
只要能获得既往项目选择决策的结果与既往项目绩效的历史资料，都应加以考虑。如果启动所涉及的是项目下一阶段的批准，则上一阶段的结果与有关资料往往起着关键作用。

5.1.2  启动的工具与技术
1. 项目选择方法（Project selection methods）
项目选择方法：量度对项目所有者的价值与吸引力。
项目选择方法包括考虑决策标准（如果使用多重标准，应将其综合成单一的价值函数），以及在不确定情况下计算价值的手段。这称为决策模型 或计算方法 。项目选择也适用于项目不同方案选择。优化工具可用于寻求决策变量的最优组合。
项目选择方法通常分为以下两大类：
 效益的测算方法 (Benefit measurement methods)：
比较方法、评分模型、效益贡献或经济学模型。
 有约束的优化方法 (Constrained optimization methods)：
采用线性、非线性、动态、整数和多目标规划算法的数学模型。
以上方法往往称为决策模型。决策模型不但包括通用技术（如决策树、强制选择等），也包括专门技术（如层次分析法、逻辑框架分析等）。在较先进的模型里应用复杂的项目选择标准往往单独被视为一个项目阶段。
2. 专家判断（Expert judgement）
评估此项过程投入时，往往要求动用专家判断。具有专门知识或经过特殊培训的任何集体或个人均可提供此种专业知识，其来源包括：
◆实施组织内部的其它单位   ◆咨询人员     ◆包括客户在内的干系人。
◆专业和技术协会           ◆行业集团。

5.1.3   启动的产出
1. 项目章程（Project charter）
项目章程是项目的正式审批文件，它授权项目经理在项目活动中动用组织资源。
项目章程应由一位置身于项目之外，级别与项目需要相称的管理人员签发。在项目按照合同执行时，经签字的合同通常即作为卖方的项目章程。
项目章程包含：1. 本项目应满足的营运需要；2. 产品描述。
2. 明确/指定项目经理（Project manager identified/assigned）
1. 如可行的话，明确与指定项目经理越快越好；（最好）
2. 最好在项目规划大部分工作完成之前；（其次）
3. 无论如何应当在项目计划开始实施之前指定。（下限）
3. 制约因素（Constraints）
制约因素指限制项目团队选择范围的因素。例如事先确定的预算就是很可能限制项目团队在范围、人员配备、以及进度方面选择的一项制约因素。
在项目按合同执行时，合同条款通常就是制约因素。另一个例子是要求项目在社会、经济与环保上具有可持续性，此项要求也将影响项目的范围、人员配备与进度。
4. 假设（Assumptions）

5.2  范围规划
范围规划：逐步详细阐述产生项目产品的项目工作（项目范围），并将其形成文字的过程。
项目范围规划从产品描述的初步投入、项目章程，以及制约因素和假设的初步定义开始。注意产品描述中应包括反映所商定客户需要的产品要求，以及满足产品要求的产品设计。范围规划的产出是范围说明书、范围管理计划及相关的详细资料。
范围说明书明确了项目目标与项目可交付成果，形成了项目与项目客户之间协议的基础。项目团队制订适合项目工作分解结构层次的多项范围说明书。

5.2.1  范围规划的投入
1. 产品描述（Product description）
2. 项目章程（Project charter）
3. 制约因素（Constraints）
4. 假设（Assumptions）

5.2.2  范围规划的工具与技术
1. 产品分析（Product alalysis）
产品分析涉及到对项目产品的进一步理解。它包括有产品分解分析、系统工程、价值工程、价值分析、功能分析和质量功能部署等项技术。
2. 成本/效益分析（Benefit/cost analysis）
成本/效益分析指估算各种项目与产品方案的有形和无形成本（开支）和效益（回报），然后运用财务指标，例如投资回报率，或回收期，来评估各项已知方案的相对优劣。
投资回报率 (ROI )：Operating income / Investment（运营收入 / 投资）；
内部收益率 (IRR )：使投资现值之和=收入现值之和的折现率；
回收期(Payback period)：收益=投资所花费的时间
3. 其它方案识别（Alternatives identification）
这是用于提出各种项目方案的诸项技术的统称。各种通用管理技术都可在此应用，其中最常用的是集思广益会与横向思维。
4. 专家判断（Expert judgement）

5.2.3  范围规划的产出
1. 范围说明书（Scope statement）
范围说明书为今后的项目决策以及在干系人中确认或建立对项目范围的共识提供了一份有案可查的依据。
随着项目的进展，范围说明书可能需要修改或完善，以反映项目范围已批准的更改。范围说明书应当包括以下内容（直接列入或者援引其它文件）：
 项目论证：论证项目所要满足的营运需要。项目论证为今后的利弊权衡提供了基础。
 项目产品：对产品描述的简要概括。
 项目可交付成果 ( Deliverable )：为了完成项目或其中一部分，而必须做出的可测量的、有形的及可以验证的任何成果、结果或事项。可交付成果应当是有形和可测量的。
 项目目标：要让项目被视为取得成功所必须满足的可量化标准。项目目标至少必须包括成本、进度和质量的量度标准。 项目目标应该具有属性（如成本）、计量单位（如美元）、以及一个绝对或相对值（如小于150万）。未量化的目标（如“客户满意”）的成功实现与否，则涉及甚大风险。
2. 辅助细节（Support detail）
范围说明书的辅助细节应根据需要形成文字并进行编排，以便于其它项目管理过程使用。 辅助细节无论何时都必须包括所有已确定的假设与制约因素的文字记载。额外细节的详略因应用领域而异。
3. 范围管理计划（Scope management plan）
范围管理计划：说明项目范围如何管理以及范围变更如何纳入项目之中。
它包括对项目范围的期望稳定性进行评估（即改变的可能性、频度与程度）。还应包括对范围变化如何识别与分类的清晰描述（当产品特征正处于推敲形成过程中时，这一点具有特殊难度，因此也就格外重要）。

5.3   范围定义
范围定义：把项目的主要可交付成果进一步分解为较小、较易管理的组成部分，其目的是：
 提高成本、工时与资源估算的准确性。
 确定绩效量度与控制的基准。
 便于提出明确的职责分派。
范围定义确定了项目工作分解结构（WBS），范围定义是否恰当，关系到项目的成败。在整个项目生命周期内，都要用到工作分解结构。工作分解结构是制定进度计划、成本预算、人员需求计划、质量计划编制等的基础。
WBS
作为输入项 5.4 范围核实
5.5 范围变更 6.1 活动定义 7.1 资源计划编制
7.2 成本估算
7.3 成本预算 11.1 风险计划编制
WBS
作为输出项 5.3 范围定义
（输出WBS） 6.1 活动定义
（WBS更新）  

5.3.1  范围定义的投入
1. 范围说明书（Scope statement）
2. 制约因素（Constraints）
在项目按合同执行时，合同条款中规定的约束因素往往是范围定义的重要考虑因素。
3. 假设（Assumptions）
4. 其它规划产出（Other planning outputs）
应该评审其它知识领域各过程的产出，判断它们对项目范围定义是否可能产生影响。
5. 历史资料（Historical information）
范围定义过程中应考虑既往项目的历史资料。既往项目的失误与疏忽尤其有用。

5.3.2  范围定义的工具与技术
1. 工作分解结构样板（WBS templates）
既往项目的工作分解结构（WBS）往往可用为新项目的样板使用。虽然每个项目都有独特性，工作分解结构却往往可以“重复使用”，因为多数项目与另一项目总有某种程度的相似之处。例如，一个组织中大部分项目的生命期往往相同或者相似，因此每个阶段的可交付成果往往相同或者相似。
2. 分解（Decomposition）
分解指把主要可交付成果或子可交付成果分成较小的，便于管理的组成部分，直到可交付成果定义明晰到足以支持各项项目活动（规划、实施、控制和收尾）的制订。
分解包括下列主要步骤：
（1）确定包括项目管理在内的项目主要可交付成果。
（2）判断在此种细节的明晰度上是否能为每项可交付成果制订合乎要求 的成本与工期估算。“合乎要求”一词的含义可随着项目的进展而有所变化。对每个可交付成果，如果有合乎要求的细节，则进行第四步，否则进行第三步。
（3）找出可交付成果的组成部分。
（4）校验分解是否正确：
 低层次项对被分解项的完成是否必要与充分？若答案为否，则必须修改该构成部分。
 每个项是否已清晰与完整的定义？若尚未做到，则必须对描述进行修改或补充。
 每个项的进度能否恰当安排？做了预算吗？是否分配到了组织中能满意完成该项工作的单位？若未曾做到，应进行修改，以提供合乎要求的管理控制。

5.3.3   范围定义的产出
1. 工作分解结构（WBS）
定义：把安排与定义项目范围的各组成部分按可交付成果进行的组合。
不在工作分解结构内的工作不属项目范围之列。如同范围说明书一样，工作分解结构往往被用来形成或确定对项目范围的共识，每下降一个层次意味着对项目可交付成果的更详尽描述。
▲帐目编码（Code of Accounts）
用于唯一确定工作分解结构每一的单元的编码系统；成本与资源被分配到这一系统。
▲会计科目表（Chart of Accounts）
对项目成本进行分类（人工、日常用品、材料）监控的任何编码系统，项目会计科目表基于主执行机构的公司会计科目表。
▲工作包（work package）：
1. 处于工作分解结构最低层次的可交付成果；
2. 工作包又可在子项目工作分解结构中进一步分解；
3. 一般说来，工作包可以使用于项目经理将工作范围指派给另一个组织；
4. 工作包可进一步分解为项目计划与进度。
5. 80小时法则：建立WBS时要注意：完成工作包的时间不要超过80小时，即两周原则。
▲工作分解结构词典（WBS Dictionary）：
1. 工作组成部分的描述通常被收集起来。
2. 工作分解结构词典通常包括工作包描述，以及进度日期、成本预算、人员配置等其它规划信息。
▲某些应用领域常用的其它结构
 合同工作分解结构（CWBS），其用途是规定卖方将向买方提供的报告层次。CWBS通常不象卖方管理自身工作所用的WBS（工作分解结构）那样详细。
 组织分解结构（OBS），其用途是显示哪项工作组成部分已经指派给组织中的哪个单位。
 资源分解结构（RBS），是组织分解结构的变体，通常用于工作组成部分指派给个人时。
 材料清单（BOM），材料清单。是制作某项工业产品所需零部件的分级层次。
 项目分解结构（PBS），基本上相当于一个十分粗糙的WBS。它广泛地应用于因WBS不能妥善表达BOM使用的应用领域。
2. 范围说明书更新（Scope statement updates）
包括对范围说明书的内容的任何修订，应根据情况通知有关的干系人。

5.4 范围核实
范围核实：取得干系人（赞助人、客户、顾客等）对项目范围正式认可的过程。
它要求审查可交付成果和工作结果，以保证一切均已正确无误与令人满意的完成。如果项目提前终止，则范围核实过程应确认与记载已完成的水平与程度。
范围核实与质量控制两者的不同，在于此过程主要关心的是工作结果的认可，而质量控制主要关心的是工作结果的正确性。这两个过程一般平行进行，以保证正确并获得认可。

5.4.1   范围核实的投入
1. 工作结果（Work results）
工作结果是指哪些可交付成果已完成或部分地完成，它是项目计划实施的一种成果。
2. 产品文字记载（Product documentation）
必须准备好描述项目产品的文件，以供审查。
此类文字记载（计划、规格、技术文件、图纸等）的名称因应用领域而异。
3. 工作分解结构（WBS）
工作分解结构是范围定义的辅助手段，故应当用于项目工作的核实。
4. 范围说明书（Scope statement）
范围说明书稍详细地定义了项目范围，应当加以核实。
5. 项目计划（Project plan）

5.4.2    范围核实的工具与技术
1. 检查（Inspection, reviews, product reviews, audits, walk-through）
检查包括通过测量、检查与测试等手段判断结果是否符合要求的活动。
检查有评审（Reviews）、产品评审（Product reviews）、审计（Audits）与演练（Walk-through）等各种名称；在某些应用领域中，这些不同名称具有较狭窄较具体的含义。

5.4.3   范围核实的产出
2. 正式验收（Formal acceptance）
表明客户或赞助者已经接受项目阶段产品或者主要可交付成果的验收文件必须准备就绪并加以分发。此种验收可以是有条件的，尤其是在项目阶段结束时。
5.5    范围变更控制
    范围变更控制关心：
a）对造成范围变更的因素施加影响，以保证变更得到各方的同意；
b) 判断范围变更确已发生；
c) 在实际变更发生时对其进行管理。

5.5.1  范围变更控制的投入
1. 工作分解结构（WBS）
工作分解结构定义项目范围的基准。
2. 绩效报告（Performance reports）
绩效报告提供范围绩效的有关信息，例如哪些中间可交付成果业已完成，哪些尚未完成。绩效报告亦可提醒项目班子将来可能引起麻烦的问题。
3. 变更请求（Change request）
变更可以要求扩大或缩小项目范围。大多数变更请求提出的原因是：
 某个外部事件：（政府条例的变更）。
 产品范围定义时的错误或疏漏：（在设计电信系统时未包括一项规定的性能）。
 项目范围定义时的错误或疏漏：（用了材料清单，而不是工作分解结构）。
 增值变更：（用原先定义范围时尚未出现的技术来降低成本）。
 为对某项风险作出应对而实施的应急计划或回避计划。
4. 范围管理计划（Scope management plan）
 
5.5.2  范围变更控制的工具与技术
1. 范围变更控制系统（Scope change control）
范围变更控制规定了项目范围变更所应遵循的程序，包括文书工作、系统追踪、以及核准变更所需通过的审批层次。
范围变更控制应该与综合变更控制结合起来，尤其应该与控制产品范围的一个或多个系统结合起来。在项目按合同实施时，范围变更控制还必须符合所有相关合同条款的规定。
2. 绩效量度（Performance measurement）
绩效量度技术有助于评估任何变更的大小，判断是什么造成了偏离基准以及决定是否应对偏离采取纠正措施都是范围变更控制的重要组成部分。
3. 补充规划（Additional planning）
项目很少会按计划原封不动的实施。预期的范围变更可能会要求对工作分解结构进行修改，或者分析其它替代方案。

5.5３  范围变更控制的产出
1. 范围变更（Scope changes）
范围变更：对经批准的工作分解结构所定义的已商定的项目范围所做的任何修改。
范围变更经常要求对成本、时间、质量或其它项目目标进行调整。项目范围变更通过规划过程进行回馈，在必要时更新技术与规划文件，并根据情况通知干系人。
2. 纠正行动（Corrective action）
纠正行动指为了将预期的未来项目绩效控制到与项目计划相符而采取的任何措施。
3. 汲取的教训（Lessons learned）
出现偏差的原因、选择纠正行动的依据，以及从范围变更控制所汲取的其它教训，都应形成文字，使此项信息成为本项目和实施组织其它项目历史资料库的组成部分。
4. 经调整的基准（Adjusted baseline）
根据变更的性质，相应的基准文件有可能需要修改并重新分发，以反映已批准的变更，并作为今后变更的新基准。
第六章 项目时间管理
【本章知识重点】
★　依赖关系；
★　网络图及其绘制：（PDM, ADM, GERT）
★　估算方法
★　日历
★　约束条件：（强制日期/关键事件/里程碑）
★　提前/滞后
★　PERT /CPM /GERT
★　赶工/快速跟进：（两者之间的定义与区别）
★　资源平衡
★　更新/修订/重定基线

【电子笔记】

项目时间管理：为确保项目按时完成所要求的各项过程。
6.1  活动定义：确定产生各个项目可交付成果所必须进行的具体活动。
6.2  活动排序：确定各活动之间的依存关系，并形成文字记载。
6.3  活动所需时间估算：估算完成各项活动所需工时单位数。
6.4  进度制订：分析活动顺序、 活动所需时间与资源要求 ，以制订项目进度。
6.5  进度控制：控制项目进度变化。
在某些项目中，特别是小项目中，活动排序，活动所需时间估算以及进度制订之间关系往往密切到被视为一个单一过程（例如它们可以由一个个人在一段较短时间内完成）。但在本章中仍按不同过程进行介绍，因为每个过程所用的工具和技术各不相同。
作为项目计划人员，我们不仅仅要知道项目时间管理的术语和简单知识，更要学会做项目进度计划的方法，学会作为项目团队成员，如何将所有约束和选择方案考虑到进度计划中并指定进度计划。

6.1  活动定义
活动定义涉及到确定为完成工作分解结构（WBS）规定的可交付成果与子可交付成果所必须进行的具体活动，并将其形成文字记载。此项过程暗含着所定义活动应保证实现项目目标的要求。

6.1.1   活动定义的投入
1. 工作分解结构（WBS）
工作分解结构是活动定义的主要投入。
2. 范围说明书（Scope statement）
范围说明书中的项目论证和项目目标部分在活动定义中应坦率与直截了当的加以考虑。
3. 历史资料（Historical information）
项目活动定义时应当考虑历史资料（过去的类似项目实际要求哪些活动）。
4. 制约因素（Constraints）
指限制项目团队选择余地的因素，使用所要求的最长的活动所需时间就是一例。
5. 假设（Assumptions）
6. 专家判断（Expert judgement）

6.1.2  活动定义的工具与技术
1. 分解（Decomposition）
就活动定义过程而言，分解指把项目工作包进一步分解成更小的，更易于管理的部分，以提供更良好的管理控制。和范围定义中所述的分解之间的主要区别是：这里的最终产出是活动，而不是可交付成果。
工作分解结构和活动清单通常按先后顺序制订，工作分解结构是最终活动清单制订的基础。在某些应用领域，工作分解结构和活动清单同时制订。
6. 样板（Templates）
以前项目的活动清单或其一部分，往往可用作新项目的样板。样板所列的活动还可包含技能资源以及所需时间的清单、风险的识别、预期的可交付成果、以及其它描述性资料。

6.1.3  活动定义的产出
1. 活动清单（Activity list）
活动清单必须包括项目将要进行的所有活动。活动清单应安排成工作分解结构的延伸，以便既保证其内容完整，又不包括任何不必成为项目范围一部分的活动。与工作分解结构一样，活动清单应当包括每项活动的描述，以保证项目班子成员能理解该项工作应如何完成。
2. 辅助细节（Supporting detail）
活动清单的辅助细节应记载在案并整理妥当，以便于其它项目管理过程使用。
辅助细节包括所有已确认假设与制约因素的文字记载。额外细节的数量因应用领域而异。
3. 工作分解结构更新（WBS updates）
 以工作分解结构来确定需要进行哪些活动时，项目班子可能会发现某些可交付成果有所疏漏，或者发现可交付成果的描述有需要澄清或纠正之处。
所有此类更新都必须反映在工作分解结构以及其它相关的文字记载，例如成本估算之中。这些更新往往称为细化，当项目采用新的或未经考验的技术时，最容易出现此种情况。

6.2   活动排序
    活动排序指识别与记载活动之间的逻辑关系。活动必须准确排序，只有这样才能在以后制订出符合实际、可以实现的进度。排序可以用电脑进行，也可以手工操作。手工和自动操作还可以结合使用。对于较小项目，以及大项目早期阶段详细资料尚不具备时，手工操作往往更为有效。

6.2.1  活动排序的投入
1. 活动清单（Activity list）
2. 产品描述（Product description）
产品特征往往会影响活动排序（例如一个拟建厂区的平面布置，一个软件项目的子系统接口）。虽然这些影响常常明显的反映在活动清单上，但一般仍应对产品描述进行审核，以确保其准确无误。
3. 强制性依存关系（Mandatory dependencies）
强制性依存关系指所从事工作性质中固有的依存关系。
它们往往涉及到一些实际的限制（例如：在施工项目中，在基础完成之前，不可能进行上层建筑的施工；在电子项目中，必须先制作原型机，然后才能进行测试）。
强制性依存关系又称硬逻辑关系（Hard logic）。
4. 可斟酌处理的依存关系（Discretionary dependencies）
可斟酌处理的依存关系指由项目团队所确定的依存关系。其使用宜谨慎从事（并要有完整的文字记载），因为它们可能会限制今后进度安排方案的选择。可斟酌处理的依存关系通常根据以下方面的知识来定义：
 某个具体应用领域内的“最佳方法”。
 虽然也可采用其它可接受的排序方式，但希望采用某种具体排序的项目中的某些不寻常的方面。
可斟酌处理的依存关系也可称为优先选用逻辑关系（Preferred logic）、 优选逻辑关系（Preferrential logic）或者软逻辑关系（Soft logic）。
5. 外部依存关系（External dependencies）
 外部依存关系指涉及项目活动和非项目活动之间关系的依存关系。
例如软件项目测试活动的进行，可能取决于由外部提供的硬件是否到位；施工项目的场地平整，可能要在环境听证会之后才能动工。
6. 里程碑（Milestones）
里程碑事件应成为活动排序的一部分，以保证满足里程碑事件按期完成的要求。

6.2.2  活动排序的工具与技术
1. 优先顺序图法 （单代号网络图）（PDM，precedence diagramming method）
这是一种（用方格或矩形）节点表示活动，并用表示依存关系的箭线将节点连接起来的一种项目网络图的绘制法。
这种技术又称活动的节点表示法（AON，activity-on-node），是大多数项目管理软件包使用的方法。PDM可用手工或电脑完成。
PDM包括四种依存关系或先后关系：
 完成对开始：后一活动的开始要等到前一活动的完成。
 完成对完成：后一活动的完成要等到前一活动的完成。
 开始对开始：后一活动的开始要等到前一活动的开始。
 开始对完成：后一活动的完成要等到前一活动的开始。
在PDM中，完成对开始是最常用的逻辑关系类型。开始对完成关系很少用，通常仅有专门制订进度的工程师才使用。在项目管理软件使用开始对开始、完成对完成、和开始对完成关系，可以产生意想不到的结果，因为关于这些类型的关系如何应用，目前尚未取得一致看法。
2. 箭线图法（双代号网络图）（ADM，arrow diagramming method）
这是一种利用箭线表示活动，并在节点处将其连接起来，用节点表示其依存关系的一种项目网络图的绘制法。
这种技术也叫活动箭线表示法（AOA，activity-on-arrow ） , 虽然其使用不如PDM那样普遍，但仍然是某些应用领域所选用的技术。
ADM只使用完成对开始依存关系，因此可能要使用虚工序才能正确地定义所有的逻辑关系。虚拟活动没有历时，不需要花费资源。
3. 条件绘图法（Conditional diagramming methods）
有些绘图技术，例如图形评审技术（GERT）和系统动力学模型允许使用诸如回路（例如，必须重复多次的试验）或者有条件分枝（例如：只有检查发现错误时才需要修改设计）这样的非时序活动。PDM 和ADM都不允许回路或有条件分枝存在。
4. 网络样板（Netowrk templates）
可以利用标准化的网络加快项目网络图的绘制。这些标准网络可以包括整个项目或其一部分。网络的一部分往往称为子网络 或者网络片段。
在项目包括若干相同或者几乎相同的特征时 （例如，高层办公楼的楼层、药品研制项目的临床试验、软件开发项目的程序模块、或者开发项目的启动阶段），子网络就特别有用。

6.2.3  活动排序的产出
1. 项目网络图（Project network diagrams）
项目网络图就是以图的形式展示项目各活动（工序）之间的逻辑关系（依赖关系）。
1． PERT：计划评审技术（Program Evaluation and Review Technique）；
2． CPM：关键路径法（Critical patch method）
3． PDM：前导图法 （precedence diagramming method）
2. 活动清单更新（Activity list updates）
如同活动定义过程可以造成工作分解结构更新一样，绘制项目网络图时也会发现一项活动需要分解或者重新定义才能画成其正确的逻辑关系的情况。

6.3  活动所需时间估算
活动所需时间估算就是根据关于项目范围与资源的信息估算所需时间 ，将其作为制订进度所需投入的过程。
活动所需时间估算的投入一般来自项目班子中最熟悉某项具体活动性质的个人或集体。这项估算通常都是逐步细化与完善的，估算过程要考虑投入数据是否存在及其质量。因此，估算结果可以假定是逐步趋于准确，其质量优劣是已知的。项目班子中最熟悉某项具体活动性质的个人或集体应当亲自完成活动所需时间估计，或者至少对其进行审核。
估算完成某项活动所需工时单位数时，往往还要求考虑过程时间。大多数电脑日程安排软件均以若干种不同的工时单位日历来解决这个问题。
项目所需总时间也可用以下介绍的工具和技术进行估算，但以应用进度制订的产出进行计算最为妥善。项目班子可将项目所需时间视为一个概率分布（应用概率分析技术），或者视为一个单点估计（应用确定性算法技术）。

6.3.1  活动所需时间估算的投入
1. 活动清单（Activity list）
2. 制约因素（Constraints）
3. 假设（Assumptions）
例如项目进行期间的各报告间隔，项目可规定最长的报告间隔，即两个报告期。
4. 资源要求（Resource requirements）
大多数活动的所需时间在很大程度上受到所分配资源的重大影响。例如，两个人共同工作时，完成一项设计活动所需时间估算可能只是单独工作时所需时间的一半；而一个半职工作的人完成一项活动所需时间通常至少是全职工作人员所需工时的两倍。然而，随着额外资源的增多，项目会出现沟通过载，从而降低劳动生产率，使生产所获得的改进随资源的增加而递减。
5. 资源能力（Resource capabilities）
大多数活动的所需时间都受到所分配的人力与物质 资源能力的重大影响，例如， 如果两人都分配全职工作，则通常可指望资深人员完成指定活动所用时间要比初级人员少。
6. 历史资料（Historical information）
从以下的一个或多个来源往往可以获得许多类型活动所需时间的历史资料：
 项目档案：参与项目的一个或多个组织可能会保留过去项目结果的记录，其详细程度足以帮助作出活动所需时间的估算。在某些应用领域中，个别队伍成员也可能会保留此种记录。
 市场出售的所需时间估算数据库软件——历史资料常常可以在市场上买到。这些数据库在活动时间不受实际工作内容影响时往往特别有用（例如，混凝土养护需要的时间，政府机构对于某类申请一般要多长时间给予回答）。
 项目班子知识。 项目班子个别成员可能记得过去所用的实际时间或时间估计。这些回忆虽很有用，但一般不如有案可查的结果可靠。（PMI的重要观点）
7. 已识别风险（Identified risks）
风险（无论是威胁还是机会）对活动所需时间有重大影响。项目班子要考虑风险影响在每项活动基准所需时间估算中的列入程度，包括概率高或者后果严重的风险。

6.3.2  活动所需时间估算的工具与技术
1. 专家判断（Expert judgement）
因为影响活动所需时间的因素太多，所以一般很难对其长短进行估计（例如资源水平，资源能力）。只要有可能时，应当利用专家根据历史资料进行判断。如果找不到这样的专家，那活动所需时间估算就有其内在的不确定性以及风险。
2. 类比估算（Analogous estimating）
类比估算也叫自上而下估算，指利用过去类似活动的实际所需时间作为基础，估算将来活动的所需时间。 当对项目的详细情况所知及其有限时（例如在项目的早期阶段），往往采用这种方法估算项目的所需时间。类比估算是专家判断的一种形式。
         CPM：对活动用一个时间估计值，即最可能时间估计值；
         PERT：对活动用三个时间估计值，使用分布均值，即：（悲观值+4*最可能值+乐观值）/6；
3. 根据工作量估算（Quantitatively based duration）
由工程或设计部门确定的每项具体工作种类所需完成的数量（即图纸张数、电缆米数、钢材吨数，等等），乘上单位生产率（即每张图纸用多少小时、每小时铺多少米电缆，等等）后，就可用来估算活动所需时间。
4. 后备时间（应急时间）（Reserve time (contingency)）
项目班子可决定增加一个额外时间量，称为后备时间、应急时间或缓冲时间，它可以加在活动持续时间之中，也可加在进度表的其它部分，作为对进度风险的一种承认。后备时间可取为活动所需时间的某个百分比，或者某个固定的工时单位数。待日后有了关于项目的更确切信息时，后备时间可以减少或者取消。上述后备时间应与其它数据和假设一起形成书面文字记载。

6.3.2  活动所需时间估算的产出
1. 活动所需时间估算（Activity duration estimates）
活动所需时间估算是完成某项活动所需工时单位数的定量估算。活动所需时间估算永远应包括结果变动范围的某种表示，例如：
 两周±2天，表明该活动至少需要八天，最多不超过12天（假设是五天工作制）。
 超过三周的概率为15%，表明该活动在三周或少于三周时间内完成的概率高达85%。
2. 估计的基础（Basis of estimates）
进行估算所依据的假设必须记录在案。
3. 活动清单更新（Activity list updates）
        
6.4  进度制订
进度制订指明确项目活动的开始与完成时间。如果开始与完成日期不现实，则项目就不可能按规定进度完成。在项目进度定夺之前，进度制订过程往往需要反复进行（连同提供投入的过程，特别是所需时间估算和成本估算）。

6.4.1   进度制订的投入
1. 项目网络图（Project network diagrams）
2. 活动所需时间估算（Activity duration estimates）
3. 资源要求（Resource requirements）
4. 储备资源库描述（Resource pool description）
制订进度需要了解在何时能以何种方式取得何种资源。
例如，共享资源或关键资源的进度安排特别困难，因为其在是否可供项目使用上的变化颇大。在储备资源库描述中，细节数量的多寡与具体化的程度是各不相同的。例如，制订某咨询项目的初步进度时可能只需要知道在某个具体时间范围内有两个咨询工程师可供调用，然而制订同一项目的最终进度时却必须具体规定哪两个咨询工程师可供调用。
5. 日历（Calendars）
项目日历与资源日历确认可安排工作的时段。项目日历 影响所有的资源。五天工作周就是日历使用的一个例子。一般来说，项目中有会有多种日历存在。
资源日历：影响某项或者某类具体资源（例如，某位项目班子成员可能在休假或在参加培训；劳务合同可能限制某些工人在一周的某几天工作）。
6. 制约因素（Constraints）
制约因素指对项目团队的选择加以限制的那些因素。在制订进度时，有两大类时间制约因素需要考虑：
 强制性日期
关于活动开始或完成的强制性日期规定其开始或完成不得早于某个规定日期，或者不得迟于某个规定日期。在项目管理软件中虽然通常包括所用四项日期制约因素，但最常用的制约因素是“开始不得早于”和“完成不得迟于”这两项制约因素。时间制约因素的典型使用场合包括：技术项目的市场销售窗口、户外活动的天气限制、政府颁布的的强制性环境治理条理的执行、项目进度中未列入的各方的材料递交，等等。
 关键事件和主要里程碑
项目发起、赞助人、项目客户或其它干系人可能要求在某个规定日期之前完成某些可交付成果。一旦列入进度，这些日期就成了人们所期望的东西，再要改动就有很大的难度。里程碑还可用于指明同项目以外工作之间的接口。此类工作通常不在项目数据库中，而带有制约日期的里程碑则可提供适当的进度接口。
7. 假设（Assumptions）
8. 提前量和滞后量（Leads and lags）
任何依存关系都可能要求规定提前量或滞后量，以便对关系准确地定义。举一个滞后量的例子：人们可能希望在某项设备的订购与安装或使用之间在时间上安排两周的延迟（滞后量）。再举一个提前量的例子：在一个有十天提前量的“完成对开始”依存关系中，后继工序在先行工序完成之前十天开始。
9. 风险管理计划（Risk management plan）
10. 活动属性（Activity attributes）
活动的属性：包括职责（即谁来完成此项工作）、地理位置或建筑物（即工作在何处完成）及活动类型（即简略的还是详尽的），对为使用者选择与安排列入计划的活动提供方便至关重要。WBS（工作分解结构）分类也是重要的属性，对活动的排序与分类十分有用。

6.4.2  进度制订的工具与技术
1. 数学分析（Mathematical analysis）
数学分析指在不考虑任何储备资源库局限性的情况下，从理论上计算所有项目活动最早和最迟的开始和完成日期。计算所得日期并非进度，而只是表明在得知资源的局限以及其它已知制约条件下，该活动可以进行安排的时段。
最常用的数学分析技术有：
 关键路径法（CPM）： 根据指定的时序网络逻辑和单一的持续时间估算，计算各项活动的单一、确定性的最早与最迟的开始与完成日期。
        正推法计算：得出活动的ES、EF
最早完成时间（EF）=最早开始时间（ES）＋工期－1
        正推法计算：得出活动的ES、EF
最晚开始时间（LS）=最晚完成时间（LF）－工期＋1
CPM的焦点是计算浮动时间，以确定哪些活动在日程安排上的灵活性最小。作为其基础的CPM算法在其它类型的数学分析中经常使用。
 图形评审技术（GERT）：可对网络逻辑和活动所需时间估算进行概率处理（即，某些活动可能根本不进行，某些活动可能只部分进行，而其它活动则可能多次进行）。
 计划评审技术（PERT）：利用经加权平均的所需时间估算，计算各项活动所需时间。 虽然在表面上有些差别，PERT同CPM的主要差别在于PERT使用概率分布的平均值（期望值），而不使用CPM所用的最大可能估计。PERT本身现在已很少使用。
2. 缩短所需时间（Duration compression）
缩短所需时间是数学分析的一个特例，其目的是在不改变项目范围的前提下寻找加快项目进度的种种方法（例如，达到强制性日期或其它进度目标要求）。缩短所需时间的技术有：
 赶进度：对成本和进度进行权衡，确定如何在尽量少增加成本的前提下最大限度的缩短项目所需时间。赶进度并非总能产生可行的方案，反而常常增加直接成本。
 快速跟进：同时进行通常按先后顺序进行的活动。快速跟进往往造成返工，并通常会增加风险。
3. 模拟（Simulation）
模拟指以不同的活动假设为前提，计算多种项目所需时间。最常用的技术是蒙特卡洛分析，该种分析对每项活动都定义一个结果概率分布，以此为基础计算整个项目的结果概率分布。此外，还可以用逻辑网络进行“如果…怎么办”分析，以模拟各种不同的情况组合，例如推迟某重要配件的交付、延迟具体工程所需时间、或者把外部因素（例如罢工、或政府批准过程发生变化）考虑进来。“如果…怎么办”分析的结果可用于评估进度在恶劣条件下的可行性，并可用于制订应急/应对计划，克服或减轻意外情况所造成的影响。
4. 资源平衡直观推断法（Resource Leveling heuristics）
数学分析所得的“及早开始”的初步进度常常造成某些时段所需资源数量超过实际可用资源，或者对资源水平改变的要求超出了项目班子的管理能力。
此时，可以采用诸如“把稀缺资源首先分配到关键路径的活动之上”之类的直观推断思路来制订一个反映此类制约因素的进度。资源平衡的结果常常是制订一个时间长于初步进度的进度。这种技术有时称为资源重新分配：
1． 对资源进行重新调度，从非关键活动转移到关键活动上去，是通常用来把进度尽可能恢复到原来规定的所需总工期的一种方法。
2． 同时也应考虑采用延长工作时间、周末加班或者增加班次等措施缩短关键活动所需的工期。通过采用不同的技术与机器提高劳动生产率是另一种缩短那些超出初步进度预计工期的措施。
某些项目可能具有既数量有限，而又极其关键的项目资源，要求从项目的完成日期开始倒排资源；这种做法称为按资源分配倒排进度法。
关键链是根据有限资源修订项目进度的一种技术。
5. 项目管理软件（Project management software）
项目管理软件已被广泛用作进度制订的辅助手段。其它软件或许能在内部直接或间接交互作用，或者通过与其它软件连接，实现其它知识领域的要求。这些产品数学分析和资源平衡中的计算进行自动化，从而使我们有可能迅速考虑众多的进度选择方案。它们还广泛的应用于打印或显示进度制订的结果。
6. 编码结构（Coding structure）
各项活动的编码结构应允许按活动的不同指定属性排序与搜寻，包括职责、地理位置或建筑物名称、项目阶段、进度级别、活动类型和工作分解结构分类等。

6.4.3  进度制订的产出
1. 项目进度（Project schedule）
项目进度至少应包括每项活动的计划开始日期与预期完成日期（注：项目进度保持其初步进度地位，直到资源分配得到确认之后。后者的确认通常应发生在项目计划制订完成之前）。
项目进度可以用简要的形式（总进度计划 ）表示，也可以详细列出。虽然可以用表格形式表达，但更常见的做法是用以下一种或多种格式的图形表示：
 项目网络图 +日期资料：此图一般既表示项目逻辑，又表示项目关键路径上的活动。
 横道图 (甘特图) ：此图同时显示出活动的开始与终止日期和预期持续时间，有时也表示依存关系。甘特图较容易看懂，常常在向管理层介绍情况时使用。
 里程碑图：与甘特图相似，但仅标示出主要可交付成果的规定开始与完成日期以及关键的外部接口。
2. 辅助细节（Support detail）
额外辅助细节至少应包括所有已认定假设与制约因素的文字记载。
额外辅助细节的多寡因应用领域而异。
 在施工项目上最可能包括：资源直方图、现金流预测、订货与交货时间表等等。
 在电子项目上，最可能包括的只有资源直方图。
作为辅助细节提供的信息常常包括，但不限于以下信息：
 按时段提出的资源要求，往往以资源直方图的形式显示；
 其它可供选择的进度（例如最好和最坏的情况，资源平衡或不平衡，有或无强制性日期）。
 进度应急储备。
3. 进度管理计划（Schedule management plan）
进度管理计划规定对进度变更如何进行管理。
规划可以是正式的或非正式的，十分详尽的或极其简略的，视项目需要而定。它是项目总体计划的组成部分。
4. 资源要求更新（Resource requirement updates）
资源平衡的更新对资源要求的初步估算有可能有重大影响。

6.5  进度控制
进度控制关注：
a）对造成进度变化的因素施加影响，确保变化得到各方认可；
b）查明进度是否已经改变；
c）在实际变化出现时对其进行管理。

6.5.1  进度控制的投入
1. 项目进度（Project schedule）
经批准的项目进度称为进度基准（Schedule Baseline）（它在技术上和从资源角度看必须是可行的，是项目计划的组成部分）。它是进度绩效量度与报告的依据。
2. 绩效报告（Performance reports）
绩效报告提供有关进度绩效的信息，例如哪些计划日期按期完成，哪些未按期实现。绩效报告还提醒项目班子注意将来有可能出现麻烦的问题
3. 变更请求（Change requests）
变更可能是要求推迟进度或加快进度。
4. 进度管理规划（Schedule management plan）

6.5.2  进度控制的工具与技术
1. 进度变更控制系统（Schedule change control system）
进度变更控制系统规定项目进度所应遵循的手段。
进度变更控制系统包括：书面申请、追踪系统、核准变更的审批级别。
2. 绩效量度（Performance measurement）
绩效量度技术有助于评估已出现偏离的程度大小。
进度控制的一个重要部分是进度所出现的偏离是否需要采取纠正措施。例如非关键路径活动的重大延误对项目总体影响甚微，而关键路径或接近关键路径上一个短得多的延误却有可能要立即采取行动。
3. 补充规划（Additional planning）
几乎没有一个项目能原封不动的按照规划执行。预期的变更可能会要求重新制订或者修改活动所需时间估算、修改活动排序或者对可选择进度进行分析。
4. 项目管理软件（Poject management software）
项目管理软件能够追踪与比较计划日期与实际日期，预测实际或潜在的进度变更所带来的后果，是进度控制的有用工具。
5. 偏差分析（Variance analysis）
在进度监视过程中，偏差分析的绩效是时间控制的一个关键因素。将目标日期同实际或预测的开始与终止日期进行比较，可以获得发现偏差以及在出现延误时采取纠正措施所需的信息。在评价项目进度实施情况时，浮动偏差也是分析项目时间绩效的一项必不可少的规划手段。
必须特别注意关键路径和亚关键路径的活动（如按浮动的上升顺序分析10个亚关键路径）。

6.5.3  进度控制的产出
1. 进度更新（Schedule updates）
进度更新指对用于项目管理的进度资料所做的任何修改。必要时，要通知给有关的干系人。进度更新即可要求，也可不要求对项目计划的其它方面进行调整。
修改：进度更新的一项特殊范畴，指变更经批准项目进度的开始与完成日期。这些变更通常是对范围变更或估算变更的所做出的反应。
在某些情况下，进度推延的幅度可能大到需要重新调整基准才能提供量度绩效所需要的现实数据。(当项目进度已经修整了几次，但在一些问题中，进度的拖延还是很严重的时候，为了确保准确的绩效考核信息，就应该重新调整基准)
重新调整基准一事要三思而后行，因为项目进度的历史数据会因此而丢失。重新调整基准只能用作进度控制中万不得已的最后一招，新的目标进度应该是进度修改的正常方式。
2. 纠正措施（Corrective action）
纠正措施指为使未来进度的期望绩效达到项目计划规定而采取的任何行动。
时间管理领域的纠正措施通常涉及到赶进度：即采取特殊行动保证活动按时完成，或者至少把延误降低到最低限度。纠正措施往往要求进行根本原因分析，查明造成偏差的原因，以便对进度规定的今后活动中规划与实施旨在恢复进度的努力，而不必仅仅拘泥于处理造成偏离的行动。
3. 汲取的教训（Lessons learned）
偏差的原因，选取纠正行动时所依据的论据以及从进度控制中汲取的其它教训均应形成文字记载，作为本项目和实施组织其它项目历史数据库的组成部分。

第七章 项目成本管理
【本章知识重点】
★　成本估算
★　估算的精度
★　预算
★　挣值
★　预测
★　时间价值：（PV、FV、NPV、IRR）
★　生命周期成本
★　成本分类：（沉淀、机会成本；固定、变动成本；可控、不可控成本；直接、间接成本）
★　折旧方法

【电子笔记】

项目成本管理：保证项目在已批准预算之内完成所必需的诸过程。
      7.1   资源规划：确定完成项目活动要动用的资源（人、设备、材料）种类和需要量。
      7.2   成本估算：估算完成项目各项活动所需资源的大致成本（估算值）。
      7.3   成本预算：将总成本估算分摊到各项个别工作活动上去。
      7.4   成本控制：控制项目预算的变更。
成本管理关心：
1. 完成项目活动所需资源的成本；
2. 但也必须考虑项目决策对项目产品使用成本的影响。这种广视角的项目成本管理通常称为“生命期成本估算”、“价值工程技术”。
3. 项目产品未来的财务绩效的预测与分析：投资回报率、现金流量贴现、投资回收分析。
项目成本管理应当考虑项目干系人的信息需要：不同的干系人可能在不同的时间，以不同的方式测算项目的成本。在项目成本用作奖励和表彰制度的一部分时，可控与不可控成本应分别估算和编制预算，以确保奖励反映实际绩效。在项目早期阶段，影响成本的力量最大，尽早完成范围定义、彻底明确要求并实施可靠计划之所以具有关键意义，原因即在于此。
PMI指出，各类项目计划（范围、进度、成本、风险等）是紧密相连的，它们最好的基础就是良好定义的工作分解结构（WBS）。

7.1  资源规划
资源规划：判断完成各项项目活动需要动用何种有形资源（人力、设备、材料）、各动用多少数量，以及何时动用。

7.1.1   资源规划的投入
1. 工作分解结构（WBS）
工作分解结构确定需要资源的项目可交付成果和过程，因此是资源规划的基本投入。其它规划过程的所有相关产出都要通过WBS提供，以保证得当的控制。
2. 历史资料（Historical information）
以往项目中的相似工作需要何种资源的历史资料，凡有可能取得者应当加以运用。
3. 范围说明书（Scope statement）
范围说明书包括项目论证和项目目标，两者在资源规划中均应明确给予考虑。
4. 储备资源库描述（Resource pool description）
资源规划需要了解有哪些资源（人力、设备、材料 ）可资动用。储备资源库描述中的细节的详略多寡及具体化的程度是各不相同的。例如，在某工程设计项目的早期阶段，资源库描述中可以包括大量的“初级和高级工程师”。然而在同一项目的后期阶段，储备资源库就只能包括那些参与了早期阶段工作，因而熟悉项目本身的个人。
5. 组织方针（Organizationl policies）
资源规划中要考虑实施组织有关人员招募、物资、设备租赁或采购的方针。
6. 活动所需时间估算（Activity duration estimates）

7.1.2   资源规划的工具与技术
1. 专家判断（Expert judgement）
评价过程投入时，往往需要专家判断。任何具有专门知识或训练的集体或个人都可提供此种专门知识，并可从多种渠道获取，包括：
◆实施组织内部其它单位   ◆咨询人员   ◆专业和技术协会  ◆行业集团。
2. 其它方案识别（Alternatives identification）
3. 项目管理软件（Project management software）
项目管理软件具有帮助整理储备资源库的能力。视软件本身档次的高低，可提供关于资源有无、价格、以及资源日历等方面的信息。

7.1.3   资源规划的产出
1. 资源要求（Resource requirements）
资源规划过程的产出是关于工作分解结构最低层次上每项要素需要何种资源以及需要多少数量的描述。
工作分解结构较高层次上的资源要求可根据较低层次上的需求推算出来。这些资源将通过人员招募和采购获取。

7.2  成本估算
成本估算指求出完成项目活动所需资源成本的近似值（估算值）。在估算成本近似值时，估算人员把造成最终估算差异的原因列入考虑之内，以便更好的管理项目。
成本估算包括识别和考虑各种成本计算方案。例如，在多数应用领域，普遍认为设计阶段多做些工作有可能节省生产阶段的成本。成本估算过程必须考虑设计工作所额外付出的成本，是否能为所期望的节省补偿而有余。

7.2.1  成本估算的投入
1. 工作分解结构（WBS）
工作分解结构用于成本估算的组织安排，并确保所有已识别工作均已得到估算。
2. 资源要求（Resource requirements）
3. 资源价格（Resource rates）
进行资源估算的人员或单位必须知道每项资源的单价（例如，每小时人工成本，每立方码散装材料成本），才能计算项目成本。如果不知道资源实际价格，则价格本身也需要进行估算。
4. 活动所需时间估算（Activity duration estimates）
项目预算包括融资成本（即利息）时， 活动所需时间估算将会影响项目成本预算。
5. 出版的估算资料（Estimating publications）
市场上可以买到的成本估算的数据。
6. 历史资料（Historical information）
许多类型资源成本的相关资料往往可从以下一个或多个来源得到：
 项目档案：参与项目的一个或多个组织可能保留有以往项目结果的记录，其详细程度可能有助于成本估算。在某些应用领域，个别班子成员也可能保留有此类记录。
 市面出售的成本估算数据库：历史资料往往可以在市面买到。
 项目班子知识：项目班子个别成员可能记得以前的实际或估计数据。这些记忆虽然有用，但一般远不如有案可稽的结果可靠。(这点证实了PMI非常重视历史资料。)
7. 会计科目表（Chart of accounts）
会计科目标描述了实施组织用于将财务信息记入总分类帐中时的科目代号结构。项目成本估算必须纳入正确的会计科目范畴。
三种会计体系：1. 财务会计； 2. 管理会计； 3. 项目会计。
8. 风险（Risks）
项目班子在进行成本估算时考虑有关风险的资料，因为风险（包括威胁或者机会）对成本能产生可观的影响。项目班子应考虑每项活动的成本估算中风险影响的列入程度。

7.2.2  成本估算的工具和技术
估算工具比较
类比估算 参数模型 自下而上估算
用过去类似项目实际成本作为当前项目成本估算的基础。 在数学模型中运用项目特点（参数）来预测项目成本。 先估算个别活动或工作包的成本，然后将个别估算汇总，算出项目成本总和。
通常在项目早期进行，因为那时候的信息还不足以进行准确估算。 参数模型无论在成本还是在准确性上，彼此相差都很悬殊。 项目团队必须在提高准确性和增加成本两者之间权衡利弊决定取舍。
估算准确度
量级估算
Order-of-Magnitude estimates 预算估算
Budget estimates 确定性估算
Definitive estimates
-25% ～ +75% -10% ～ +25% -5% ～ +10%
通常发生在概念形成与启动阶段。 通常发生在计划编制阶段。 通常发生在计划编制阶段。
  基于具有比例因子的某一工作范围。 也是一种自上而下估算 最准确的估算
用于可行性研究决策。   用工作分解结构进行的自下而上估算
其它名称：
可行性估算、SWAG估算 其它名称：
自上而下估算、类比估算 其它名称：
详细估算、工作分解结构估算

1. 类比估算（Analogous estimating）
类比估算又称自上而下估算（Up-Bottom estimating），类比估算是一种专家判断。类比估算的成本通常低于其它方法，但精确度也较差。此方法在以下情况下最为可靠：
a) 以往的项目实际上，而不只是在表面上相似；
b) 进行估算的个人或集体具有所需的专门知识。
2. 参数模型（Parametric modeling）
在下述情况下，参数模型有可能比较可靠：
a）用以建立参数模型的历史资料准确；
b）模型中使用的参数容易量化；
c）模型具有可缩放性（即它既适用于规模甚大的项目，也适用于规模很小的项目）。
3. 自下而上估算（Bottom-Up estimating）
自下而上估算的成本与准确性取决于个别活动或工作包的规模和复杂程度；较小的活动规模增加了估算过程成本，但也提高了估算的准确性。
4. 电脑化工具（Computerized tools）
项目管理软件、棋盘式电子表格程序、模拟统计工具等电脑化工具被广泛用作成本估算的辅助手段。此类产品可以简化上面提到的各种工具的使用，从而便于我们迅速考虑多项成本估算方案。
5. 其它成本估算方法（Other cost estimating methods）
例如，供应商报价分析。

7.2.1   成本估算的产出
1. 成本估算（Cost estimates）
成本估算指：完成项目活动所需资源可能成本的定量估计。
所有项目计价资源的成本均应列入估算范围，其中包括，但不限于人工、材料、物资、以及诸如通货膨胀津贴或成本储备等特殊范畴。
成本估算一般用货币单位表示（美元、欧元、日元等），以便于项目内部与项目之间的比较。在有些情况下，估算人员可采用计量单位估算成本，例如，工时，或工作日及其成本估算，以促进适当的管理控制。成本估算通常考虑适当的风险应对规划，例如应急计划。
通过在项目进行过程中逐步细化，成本估算得以反映新增加的各项细节。在有些应用领域，已经具备了此种细化应在何时进行以及细化到何种精确度的指导准则。例如成本工程促进国际协会（AACE）已经确定了设计期间施工成本估算上循序渐进的五类估算，即：量级估算、概念估算、初步估算、界定估算和控制估算。
2. 辅助细节（Support detail）
成本估算的辅助细节应包括：
 所估算工作的范围描述。通常以援引工作分解结构方式提供。
 估算根据的文字记载，即估算如何进行的说明。
 所作假设的文字记载。
 关于可能结果变化范围的记载。
附加细节的形式与数量因应用领域而异。保留下来的笔记，即便十分粗糙，可能也十分有用，有助于更透彻理解估算是如何进行的。
3. 成本管理计划（Cost management plan）
成本管理计划描述成本偏差（CV）应如何管理（例如，大问题与小问题应区别对待）。

7.3  成本预算
成本预算指将总成本分派到各项活动或工作包上，以确立量度项目绩效的成本基准。
现实生活往往迫使我们在预算批准之后才进行估算，但只要有可能，估算应在预算申请之前完成。

7.3.1  成本预算的投入
1. 成本估算（Cost estimates）
2. 工作分解结构（WBS）
工作分解结构确定需要分派成本的项目要素。
3. 项目进度（Project schedule）
项目进度包括需要分派成本的各项目组成部分的计划开始日期和预期完成日期。 将成本分派到动用成本的相应时段上去需要此项信息。
4. 风险管理计划（Cost management plan）
风险管理计划常常包括成本应急储备，所需数量根据估算的期望精确度加以确定。

7.3.2  成本预算的工具与技术
1. 成本估算的工具与技术
项目成本估算的工具与技术也可用来制订活动或工作包预算。

7.3.3  成本预算的产出
1. 成本基准（Cost baseline）
成本基准是按时间安排的预算，用于测量和监控项目中成本的执行情况。
成本预算将总成本估算分配到具体的活动或工作包，从而建立出成本基准，通常以S曲线形式显示。许多项目（特别是大项目），可能有多个成本基准，以便量度项目成本绩效的各方面。

7.4  成本控制
成本控制关注：a）对造成成本基准变更的因素施加影响，保证所有变更均经过各方面的认可；
b) 确定成本基准是否发生变更；
c）实际变更发生时对其实行管理。
成本控制包括：
 监督成本绩效，找出与计划的偏差，并弄清原因。
 确保所有恰当的变更都准确的记载于成本基准之中。
 阻止不正确、不恰当或未经批准的变更纳入成本基准中。
 将经核准的变更通知干系人。
 采取措施将预期成本限制在可接受的范围之内。
成本控制包括查找正、负偏差的原因。例如，若对成本偏差采取不恰当的应对措施，就可能造成质量或进度问题，或在项目的今后阶段产生无法接受的巨大风险。

7.4.1   成本控制的投入
1. 成本基准（Cost baseline）
2. 绩效报告（Performance reports）
绩效报告提供有关项目范围与成本绩效的情况，例如哪些预算达到要求，哪些还没有。绩效报告还提醒项目班子注意将来可能出现麻烦的问题。
3. 变更申请（Change requests）
变更可能要求增加预算，也可能允许将其削减。
4. 成本管理计划（Cost management plan）

7.4.2   成本控制的工具与技术
1. 成本变更控制系统（Cost change control system）
成本变更控制系统规定成本基准变更所应遵循的程序，包括书面申请、追踪系统以及核准变更的审批级别。
2. 绩效量度（Performance measurement）
绩效量度技术有助于评估已出现偏差的大小。
挣值管理（EVM）则对成本控制极其有用。成本控制的一个重要部分，是确定何种原因造成了偏差，并决定偏差是否需要采取纠正行动。
3. 挣值管理（EVM：Earned value management）
所有挣值管理（EVM）控制帐目计划（CAPs），均应以下列三个独立变量的相互关系为手段，来连续的量度项目的绩效：
1） 计划价值（PV（BCWS））：已安排要完成的实际工作；
2） 挣值（EV（BCWP））：已完成的实际工作；
3） 实际成本（AC（ACWP））：已用去的实际成本。
术语 解释/ 计算公式
PV  计划值 Planned Value 应该完成多少工作？（96版的名称：BCWS）
EV  挣值 Earned Value 完成了多少预算工作？（96版的名称：BCWP）
AC  实际成本 Actual Cost 完成工作的实际成本是多少？（96版的名称：ACWP）
BAC  完工预算 全部工作的预算是多少？不改变成本基准，BAC就不会变。
EAC  完工估算
(全部工作的成本是多少？)
它是根据项目的绩效和风险量化对项目最可能的总成本所做的一种预测。 EAC = BAC + AC–EV= BAC- CV
(当前出现的偏差被视为非典型特例，而且项目团队预计将来不至于出现类似偏差时。)
EAC = BAC / CPI
(当项目完成15%～20%时，CPI相对稳定，可以用来估算EAC)
EAC = ETC + AC
(以往绩效表明原有估算假设有重大缺陷，或者由于情况改变，原有假设不再适用时。)
ETC  完工尚需估算 剩余工作在当前的估算是多少？
CV  成本差异 CV = EV–AC   CV>0代表成本节约，好！
 成本差异比例 % =  CV/EV = （EV-AC）/EV = 1- 1/CPI
SV  进度差异 SV = EV–PV   SV>0代表进度提前，好！
 进度差异比例 % =  SV/PV = （EV-PV）/PV= SPI-1
CPI  成本绩效指数 CPI = EV/AC   CPI>1代表工作价值高，好！
SPI  进度绩效指数 SPI = EV/PV   SPI>1代表实际进度快，好！
PC  任务完成指数 PC = EV/BAC   表示已经完成总工作的比例
PS  成本消耗指数 PC = AC/BAC   表示已经消耗总预算的比例
TCPI  到完成时的绩效指数 PC = (BAC-EV)/(BAC-AC) 
表示剩余要完成的工作的成本业绩表现
记忆小窍门（Tips）：EV在大多数公式的前面，与成本有关用AC，与进度有关用PC；
EV可以用50-50法则、20-80法则、0-100法则（最保守）来计算，A-B法则的含义是：当一项任务开始的时候，我们用EV的A%来计算，当任务完成后，再计算剩余的B%。如果采用0-100法则，就表示任务完成前，该项任务的EV值都为零。
4. 补充规划（Additional planning）
很少有项目能一丝不苟的按计划执行。预期的变更或可能要求制订新成本估算、修改现有成本估算、或者分析替代方案。
5. 电脑化工具（Computerized tools）
电脑化工具常被用来对计划成本与实际成本进行跟踪，并预报成本变更的后果。

7.4.3   成本控制的产出
1. 经修改的成本估算（Revised cost estimates）
经修改的成本估算指对用于管理项目的成本资料所做的修改。必要时，必须通知有关的干系人。经修改的成本估算可能要求，也可能不要求对项目计划的其它方面进行调整。
2. 预算更新（Budget updates）
预算更新是一种特殊类型的经修改的成本估算。预算更新是对经批准成本基准所做的变更。这些数字一般只在范围变更之后才作修改。在某些情况下，成本偏差有可能极其严重，需要重新调整基准，才能对绩效进行现实的量度。
3. 纠正措施（Corrective action）
纠正措施指为把项目未来期望绩效达到项目计划规定而采取的任何行动。
4. 竣工估算（EAC ：Estimate At Completion）
竣工估算（EAC）是根据项目的绩效和风险量化对项目最可能的总成本所做的一种预测。
5. 项目收尾（Project closeout）
应当制订结束或取消项目的过程和程序。
6. 汲取的教训（Lessons learned）
造成偏差的原因、所采取纠正措施的依据、从成本控制中汲取的教训都应形成文字记载。

【经济术语】：
可变成本：随生产量和工作量而变的成本，比如：物料、工资、供应品等；
固定成本：不随生产量和工作量而变的非重复成本，比如：设置费、租赁费等；
直接成本：直接可以归属到项目工作的成本，比如：项目成员工资、差旅费、项目用物料等；
    间接成本：一般管理费用，或几个项目的公摊费用成本，比如：税金、保安费等；
    沉淀成本：已经花费的成本，对项目下一阶段的活动估算时不用考虑的成本；
    机会成本：选择一个项目后，所放弃的最佳收益项目的成本；
   
直线折旧法：资产在其寿命期内等额，周期地支出；
加速折旧法：资产在其寿命期内不等额，递减地支出；分为双倍余额递减法、年数总额法。
 5年折旧 第1年 第2年 第3年 第4年 第5年
直线折旧法 1000 -1000*
(1/5) -1000*
(1/5) -1000*
(1/5) -1000*
(1/5) -1000*
(1/5)
双倍余额递减法 1000 -400 -240 -144 -108 -108
年数总额法 1000 -1000*
(5/15) -1000*
(4/15) -1000*
(3/15) -1000*
(2/15) -1000*
(1/15)

应急储备（contingency reserve）：为将来碰到的“已知的未知情形”做准备的储备；
管理储备（management reserve）：为预先考虑的那些“未知的未知情形”做准备的储备；通常拨出项目资金的一定百分比（10%）作为管理储备。

成本帐户（Cost accounts）：它提供了在WBS中的具体的工作组，一般通过一个时间卡片来进行每日的或每星期的追踪。这种时间卡片构成成本帐户系统的一部分。
成本帐户目的：调整和报告项目业绩。
成本帐户目标：准时地收集每个工作组在不同时间点上的结果（成本、进度、资源的使用）。

第八章 项目质量管理
【本章知识重点】
★　项目质量管理的3个过程；
★　质量定义、目标：（要按照PMI的定义，尽量不要用其它的定义）
★　质量与等级：（两者之间的定义与区别）
★　质量与镀金
★　实验设计
★　质量成本
★　工作定义（操作定义）
★　质量保证/质量控制
★　质量控制的工具：（因果图 / 帕雷托图 / 控制图）
★　质量管理大师的观点
★　预防重于检查
★　持续改进（Kaizen）

【电子笔记】

项目质量管理：保证项目能满足原先规定的各项要求所需要的过程。即“总体管理功能中决定质量方针、目标与责任的所有活动，并通过诸如质量规划、质量保证、质量控制、质量改进等手段在质量体系内加以实施”。
8.1   质量规划：判断哪些质量标准与本项目相关，并决定应如何达到这些质量标准。
8.2   质量保证：定期评估项目总体绩效，建立项目能达到相关质量标准的信心。
8.3   质量控制：监测项目的总体结果，判断它们是否符合相关质量标准，并找出如何消除不合格绩效的方法。
质量（Quality）：是“使实体具备满足明确或隐含需求能力的各项特征之总和”。
等级（Grade）：是“对具体相同功能特征，但技术特征各异的实体所规定的范畴或者级别”
质量的目标：1. 符合要求/规范（conformance to requirements/specifications）；
2. 适用性（fitness of use）,不要镀金(no Gold-Plating)。
质量明确或隐含的需求是项目要求制订的投入。质量偏低永远是个问题，而等级较低则不见得是个问题。项目团队还应当明白，现代的质量管理与项目管理是相辅相成的。
质量管理和项目管理这