PMBOK笔记: 第四章 项目综合管理

第四章 项目综合管理

【4项目综合管理重点】

★　假设、约束：（两者之间的定义与区别）

★　项目计划：（定义、作用、内容、制订人）

★　项目计划和绩效基线

★　工作授权体系 → 控制“镀金”

★　工作结果和可交付成果：（两者之间的定义与区别）

★　变更申请

★　综合变更控制

★　变更控制系统

★　配置管理：（配置管理与变更控制系统之间的定义与区别）

 

【电子笔记】

 

项目综合管理：为保证项目各组成部分恰当协调而必须进行的过程。

项目综合管理就是在各个相互冲突的目标与方案之间权衡取舍，以达到或超过项目干系人的要求与期望。项目经理对项目综合管理负责。

以下是项目综合管理的三个过程。

     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）

参与项目的组织都有正式或非正式的方针，其影响必须考虑。组织机构的几个主要方针：

n  质量管理方针：过程审计，连续的改进目标。

n  人事管理方针：雇佣和解雇原则，雇员表现评价。

n  财务控制方针：定期报告、要求进行的开支和支付审查、会计法规、标准合同条款。

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）：绩效量度基准是一项经过核准的计划，用以在管理控制中作为量度偏差的基准。它通常仅断断续续有所改变，其原因往往是对已批准的工作范围变更或可交付成果变更作出反应。

项目计划的结构与表达有多种方式，但是一般均包括以下内容：

n  项目章程。

n  项目管理方法或策略的说明。（其它知识领域各项管理计划的摘要）

n  范围说明书，包括项目各项目标和可交付成果。

n  作为基准范围文件的工作分解结构（WBS）。

n  成本估算，计划开始和完成日期（进度），以及工作分解结构（WBS），对每项可交付成果进行职责分派。

n  技术范围、进度和成本的绩效量度基准（进度基准、成本基准）。

n  主要的里程碑及其目标日期。

n  关键的或必需的人员，及其预期成本和/或人力投入。

n  风险管理计划，包括主要风险及其制约因素与假设，以及为其安排的应对与（必要的）应急措施。

n  各过程的从属管理计划。

上述每项计划必要时均可列入项目计划，其详细程度因每个具体项目的要求而异。

2. 详细辅助资料（Support detail）

项目计划详细辅助资料包括：

n 未纳入项目计划的其它计划过程产出。

n 项目计划制订期间产生的资料或文件（例如，过去不曾知道的制约因素和假设）。

n 技术文件：例如，对所有要求、规格和概念设计来龙去脉的记载。

n 相关标准的文件记载。

n 在项目早期制订过程中所提出的规格。

该项材料必要时需要加以整理，以便于在项目实施过程中使用。

 

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 )

配置管理：任何用来对以下过程实行技术和行政指导与监督的、文档化的程序：

n  识别工作项或系统的功能特性和物理特性，并形成文档。

n  控制上述特性的所有变更。

n  记录并报告上述变更及其实施状况。

n  审核上述对象与系统，核实是否符合要求。

★ 在许多应用领域，配置管理只是变更控制系统的一个子集。

★ 在其它一些应用领域，也可能指为管理项目变更而作出的任何系统管理。

★ 不能自动“批准”变更。

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）

偏差产生的原因、已采取的纠正行动的理由，以及所汲取的其它教训都应形成文件，记载在案，使其成为本项目和实施组织内其它项目历史数据库的组成部分。

数据库也是知识管理的基础。