项目规划和管理

1. 项目的定义和组织
1.1 确定项目组织
对于任何一个项目而言，知道谁将做些什么事是非常关键的。确定项目组织这一步骤的目的就是保证清楚地了解所有的角色和职责，对项目组的所有成员加以确认并使之忠于项目工作。尤其是，该步骤保证确立了领导者（项目经理），并明确他或者她的权威和职责。
确定项目组织的关键问题
 谁是项目经理？
 项目经理的职责是什么？
 在哪些领域项目经理有决策权？
 是否就项目经理的职责和权威达成一致意见？是否已记录下来并且发放给了项目组？
 项目组成员有谁？
 每名项目组成员的专长是什么？
 是否已认同了所有为项目工作的人？
 项目组的职责是什么？
 项目组的花名册是否已完成？
 谁为该项目组筹集资金？向谁汇报？
确定项目经理传统上是大多数项目的第一步。最佳的项目经理应具备下列条件：
 优秀的激励者和领导者，指导并教授项目组的其他成员。
 “全局导向的”
 有效的沟通者。
 优秀的组织者
 以目标为导向的。
 懂得项目管理的步骤，并且坚定地使用项目管理的步骤。
有效的项目经理不一定是技术上的专家：事实上，如果技术上的专家主要涉及的是项目的内容而忽视了对项目管理过程的管理，专业性经常有可能成为项目管理成功的一个阻碍。有效的项目管理发动团队来实施项目的内容。
尤为突出的是，项目经理负责保证图1中所示的项目管理过程得到有效的执行。因此，项目经理：
 保证项目组成员理解项目管理并进行实践。
 保证所有的项目组成员理解并接受他们的职责。
 集中项目组资源用于计划的制订和实施。
 对计划用出及时的调整。
 维护项目文件。
 仲裁并解决冲突。
 向项目组成员和其他人汇报项目的状态。
 记录问题的日志。
项目经理的任命应该以书面的形式正式宣布，并完整地描述其承担的角色和职责。比如说，高层管理人员在宣布时应表明：如果团队成员之间有争端，项目经理是否有权做出决定，或者宣布“破裂来寻求其他权威人士的帮助。
例：一家财富500强公司的电视机生产设备分部的一个“关键任务（mission critical）”项目出了差错，可能会错过需要的市场机会。公司的高层管理人员已经告诉过部门管理人员：如果项目不能在某一特定的日期前完成，分部将被关闭，并且所有人员的都被解雇。
对项目所做的分析表明团队由项目“主解”构成（即：代表诸多不同职能的人员，如营销/工程和制造等），但却没有一个项目经理。每个项目主角向不同的职能部经理汇报，每名经理对项目的优先权和期限望的结果都有不同的观点。项目主角非常难以就目标、解决问题/确定进度达成一致的意见，并且也很难作到在管理上不插手不同职能部门。项目完全是一团混乱，没有一个人负责。
一旦高层管理人员意识到问题所在，分部的副总裁正式地任命了一名威信高的管理者作为项目经理，并且明确地给予了这名经理解决差异的权力。项目经理积极地告知所有的重要人员任何冲突是不可接受的，然后举行了一次为期两天的计划方面的讲习班。在讲习班上，经理和团队明确修正了项目的目标，修订了项目的进度表并达成了一致的意见，制订并批准了争论管理过程。通过力推项目管理，经理和团队比最后期限提前完成了项目。
同时，我们还应清楚地确认项目组，并配以明确的角色和职责。这样可以保证所有的工作都由某人“所有”，多余的工作最少，并且减少了角色的冲突。为项目工作的所有的人都应该包括项目组中，当然，有些人要完成的工作会比其它人多许多。项目组的主要职责包括：
 了解项目管理的过程和工具。
 帮助创建项目计划。
 致力于项目的成功。
 汇报项目的进展、风险、争论和问题。
 针对项目的变化作出有效的调整。
每个项目都应完成项目给花名册（图2）。这个强有力的工具确定了团队的成员和他们的角色以及职责。同时也是保存项目组后勤方面信息的一种方便和有效的方法。通常情况是，当首次完成项目组花名册时，团队会非常吃惊地发现：项目涉及到那么多不同的人员和角色，人员之间的冗余那么大以及有那么多关键的职责被忽略了。完成花名册迫使成员更全面地定义他们的团队。每个项目都应有花名册。
图2-----项目组花名册
姓名和职位 角色 组织 电话和传真 电子邮件地址 地址/邮箱
     
     
     
     
例：一个大型的复杂软件开发项目的项目经理对于他所面对的工作量感到无所适从。他经常奔忙于会议之间以及与不同小组交流。然而，他仍然不断地被指责为没有与关键人员和关键部门沟通。对他所处的情景进行的分析表明他不清楚究竟有谁在参与该项目。
因此，他作为一份项目给的花名册，发现他在处理64个不同的部门、200多名人员，实际上，他一直在努力用“原始的力量”来管理项目，很少地制定项目组的职责。一旦完成了项目组的花名册，他就能够让项目有更多的结构，能够明确界定由12个人组成的核心团队，来代表其它的职能部门和员工。团队的有效性提高，并且项迅速地产生了巨大的、及时的重新调整。
确定项目组织的关键行动
 以书面形式任命项目经理。
 书面描述项目经理的角色、权力和职责。
 确认项目组角色和职责。
 创建并公布项目给花名册。
1．2 定义项目参数
也许任何一个项目计划的最重要的因素是知道项目的目标和交付物。项目参数定义这一步骤的意图是保证完成的是“正确”的项目。所谓“正确”的项目是指按期望的结果或者范围、进度、和花费的资源来规定的。这些数据记载在项目目标书（Project Objective Statement: POS）和主要交付物中，包括强有力“是/否”的过程。
这些数据的第一关是确定项目的目标。但是，具有在完整的详细计划（包括风险管理计划）完成以后，才能最终确定这些目标，因为详细的计划就目标可行性方面提供了大量信息。
定义参数时的主要问题
 项目范围是什么？
 项目什么时候完成？
 给项目分配什么资源？
 是否有一份清晰的、简明的、字数少于25的项目目标书？
 项目的主要交付物或者后果是什么？
是否很好地定义了主要的交付物？
 每个主要交付物是否都有书面的是/否清单？
 主要的交付物是否设定了目标完成的时间？
项目目标书（POS）描述了项目应完成什么，应在什么时候完成以及需要花费多少来完成。这些方面分别被称为项目的范围、进度和资源。所有的POS都应有这三个参数。
POS中范围这一部分描述的是预期结果的精髓。因此，美国国家航空及太空总署的月球火箭发射项目的范围是：“将一个人送到月球上，并让他安全返回。”如果其中某一部分被省略，比台有关安全返回这一部分，项目可以达到规定的结果：将一个人放到月球上，但项目却很难被认为是成功的。有效的范围陈述必须捕捉到成功结果的精髓。
POS中进度这部分应抓住项目的完成时间（记住，在完整的进度表编制好之前，这仅仅是一个目标）。因此，月球火箭发射项目的POS中进度部分是：“在十年之前”。虽然这引起了人们的想象，但作为进度目标，却有点过于模糊。“在十年之前”可意味着提前一年，提前进6个月或者在十年的最后一天。同样，象“在职998年二季度之前”这类的进度目标也许对某些人意味着第二季度的开始，有些人认为是季度末。作为POS中的进度，应是项目的一个确切的日期，如“1998年6月30日前”。
POS的资源部分描述了项目的资源配置，可以用某笔金额（如“成本为了百万美元”）、人月数或者相当于全日专职数（如“使用32个人月数）来表示，或者综合这些表示法。比如，月球火箭发射项目的资源部分，1961年是5.31亿美元,十年期间是70-90亿美元.保证所使用的尺度在相关环境中被普启蒙接受是非常重要的.当心用这类的语言”用现存的资源”.该句话假设这些资源可供该项目使用,但实际上可能不是那样.同时,这样的陈述为以后作权衡性的决策无法提供有用的信息.POS中的资源部分应该反映项目所需资源的目标总量.
除了这三个参数（范围，进度，资源）以外，一份好的POS还包括几项其他重要性：
 单词数不超过25（该限制迫使POS精确）
 使用普通的语言，避免行话和首字母缩合词。
 清楚，简洁。
 理想的POS应是一种愿景，形成了挑战和一定程度的兴奋。
再以月球火箭发射为例，一个好的、完整的POS应是这样的：
将一个人放到月球上，并让他在1969年12月31日前安全返回，预算为9亿美元。
这个POS清楚、简洁并且很有效。
例：在一家大型医疗产品公司，负责一个关键项目的高层经理让项目组精心制订一份POS来保证他们对目标达成共识。项目组首先写了一65个单词的目标书，其中包括多个日期和几种资源变更。经过很大的努力，小组将POS缩减为25个单词，并拿给高层经理看。
她惊呆了。小组把项目弄错了！刚开始的65个单词 中至少隐藏着三个可能的项目。项目组重点放在了错误的项目上。高层经理和项目组迅速地重新调整其重点，项目很早就完成，并月认为是非常成功的。高层经理估计通过使用POS她的部门节省了40个人的团队三个月的工作，或者按每个人工满负荷工作一天是750美元计算，每月节省了180万美元。一份好的POS能够直接影响底线利润。
主要交付特是提炼完善了POS中对范围的定义。主要交付物是管理人员注意力焦点所在的主要项目的后果或者结果。比如说，并购项目的主要交付物可以是财务分析的第一稿：医学项目的主要交付物是临床实验：或者营的调研项目的最终交付物是市场战略的定义。这些交付物通常是判断项目成功的基础。
因为主要交付物是作为一种让管理人员将注意力集中在关键项目结果上的一种工具，有关这些交付物应该是什么以及多长时间应交付这些方面具体的指导方针很少。基本的“经验之谈”是：项目经理和团队应提前决定他们致力于哪些关键的有形结果。比如说，在创建复杂的新产品线的项目中，车间的“第一关”设计也许是一个好的主要交付物。但是，如果生产线很简单，完整的设计也许是一个更好的主要交付物。团队应该选择那些方便他们规划和管理项目的结果。
既然主要交付物对于项目的成功那第重要，那就有必要系统地保证很好地定义并且明确主要交付物。定义主要交付物的一种简单，但却是非常有力的方法是是/否方法。
考虑这么一个常见情景。你打开了电视机，收到了图象却没有声音。你随之调大音量。如果你仍然无法收到声音，你就可能换频道。如果你收到了声音，你则了解边界状况的某些信息，既然在第二个频道你收到了声音，问题不是电视机；问题是发送。想似地，是/否的过程通过明确地定义边界状况阐明了交付物。与更正式的规范过程相比或者与完全无规范相比，是/否过程是一种异常有效地定义主要交付物的方法。
使用是/否过程时，项目组列出所有的包括在项目中的事项（是）或者所有的被项目排除在外的事项（否）（通常是在活动挂图上，有一栏为是，一栏为否）。通过快速的头脑风暴法产生出上述清单。“是项”是指当你思考“该交付物是什么时？”闯入你脑海的所有事项。比如，交付物是一份咨询报告，则“是项”清单中可能包括诸如篇幅（是5页）、装订（是螺旋装订）、内容（有关营销和财务的两节）以及其他帮助阐明期望结果的任何项目。
“否项”是指有些人认为将某些项目包含在交付物里是合理的、但却不应该包括的项目。因此，在咨询报告的例子里，“否项”可能是这样的：不包括正式的演讲，或者不进行某些统计分析。“否项”限制了主要交付物，因此更好地定义了项目的工作。
是/否清单显示出一些造成管理上挑战的一致模式。典型的模式是，“是项”清单很长，令人立即意识到得从该清单上去除某些项目才能保证羡慕是可行的。另一种情况是，总有些“否项”清单上的某些项目让一名或者多名项目组成员受到困扰。他们强烈地指出该项目非常重要，不应该排除在外。将一些项目在“是项”和“否项”之间移动正是管理权衡的精髓，因为每一次变动都会同时改变项目的重点或者扩大了项目、触犯某些人或者令某些人激动，并最终直接影响进度和资源上的需求。是/否过程给项目组、项目经理和高层管理人员提供了一种制订非连续决策的工具。
例：一家财富500强公司的人力资源部开始进行一个主要的流程再造项目。人力资源部的团队召开了为期两天的研讨班，用是/否方法来确认和定义再造工程的主要交付物。主要交付物包括：
 分析公司当前的所有关键流程。
 重新定义这些流程。
 一份正式的实施计划。
 一份独立的人员配备计划。
当团队谈到第一个主要交付物（分析公司当前的所有流程）的是/否（见下表）时，他们迅速地发现高层管理人员真的是同时指公司“所有的”流程。
是  否
产品开发
定单的履行
营销
顾客服务 战略计划
计算机模拟
“是项”清单中需处理的流程非常的广泛，而“否项”却非常的少。因此，他们广泛地讨论怎样才是可能的，最终决定优先将“定单的履行”作为项目的首要重点。他们还修改了主要交付物来反映以定单的履行为重点。“是项”清单按某种方式定义了“所有的”含义，导致了项目范围上的决定更加有效。
定义项目参数的关键行动
 书写项目任务书。
 列出主要交付物。
 对每个主要交付物都创建一份是/否清单。
1.3  计划项目框架
许多项目的项目组成员通常都会抱怨两件事情：一是会议太多，二是很难制订决策。这两者都表明操作程序定义得不好。相反，有效定义了操作程序的项目通常效率很高、人员士气也更高——人们常将它们描述为“运转良好”。计划项目框架这一步骤的目的是定义项目组应该如何操作。对该问题达成一致意见对项目的成功有直接的影响。
计划项目框架的关键问题
 项目组是否明确指出什么时候开会？在什么地方开会？哪些人会参加？将讨论哪些问题？
 是否已确立出席准则？
 是否已确立参与标准？
 项目组是否定期地记录所有的问题？
 是否定期地更新并且回顾问题日志？
 项目组将如何解决意见上的分歧或者冲突？
 对未解决的问题是否有自动升级的路径？
 谁负责并且维护项目文件？
 文件的存储地点是什么？
 项目组如何沟通（电子邮件、电话等）？
 这些已达成一致意见的事宜是否已经书面记录并且存储在项目文件中？
虽然有多种可能的操作程序，有些方面对于大多数项目而言是尤其重要的。
包括：
 会议以及会议管理。
 问题管理（包括“自动升级”）
 项目文件的维护和储存。
 沟通过程。
对于大多数项目组而言，会议 既是主要的沟通方式又是一种工作。不幸的是，会议也是很多人存在的祸根。规定会议的某些简单的方面，可以使会议更有实效。比如，去顶一个标准的项目开会时间、会议议程和参会政策是非常有价值的。同时，在会议中积极地并且有意识地管理问题，将问题记录到日志中，但当时尽量不去解决，以及解决决策制订的程序（例：制订决策需全体同意、或多数投票、或项目经理独自决定），都是影响项目成功的重要因素。
正式的问题管理也是相似的影响。在问题日志中系统地记录所有的问题会简化问题的决策制订，因为记录这一过程就使得重点在问题本身。通常问题日志是由项目经理提议并维护的。它是用来确认那些不能立即解决的问题。提出一名该问题的“责任人（所有者）”以及需解决问题的日期。项目组所有的成员都可以接触该日志，并且在状况会议上回顾以保证所有的人都能了解。
另外，这么一个给问题分派“责任人”、指定解决的时间、记录解决问题的过程造成了压力来以他人可以接受的方式快速地终止问题。如果对于尚未解决的问题有自动升级的路径，这一点尤其正确。自动升级路线是在项目刚开始时就由项目组规定的，它确定了什么时候未决问题可以升级，并且升级给谁来解决。
将未决问题升级给当权人士去解决，会激励人们解决他们的分歧。项目组成员经常不愿意解决某个问题，因为与他们所在的职能职责的潜在的冲突。他们也许不愿意冒险出错，或者担心某件事情真的是高层经理的职责。
图3——问题/行动项跟踪表格
问题跟踪表
事情 日期 提出者 描述及影响 所有者 到期日 状态或者解决
      
      
若采取更标准方式操作的话，姓名局组应该指定一个人在某一特定场所来维护项目文件。项目文件是所有项目文档的贮藏室，对解决在项目工作的白热阶段形成的争端，是非常有用的。可以将项目文件保存在活页夹中或者作为在线文件来保存，但对所有权、存放地点和取用等必须正式指定。
所有的项目都产生了大量的交流。前瞻性地确定项目组成员如何彼此沟通、使用什么类型的媒介以及沟通的频率都会很好地节约时间。因此，有些项目组同意使用电子邮件来交流对时间不敏感的正式的状况报告和留言，而使用声音邮件来满足短期的需要。其他的项目组从以下方面来讨论该问题：谁应该将什么信息传递给高层经理，频率如何等。每个项目组都应该确定自己的沟通战略。
例：一家有1 4家公司的集团的某一个项目组处于困境之中。因为该项目组综合了所有公司的人员，每个公司都有自己的决策制定方法，可以很快地提出项目上的问题，但解决起来却很慢。项目组成员真的不知道如何相互交流，很多项目上的问题将会升级到首席运营长官的参谋人员那，但部门的需要总是优先考虑。
面对这些解决问题上的困难，项目组制订了正式的问题管理过程，其中包括跟踪问题未决的时间，以及自动升级过程，如果一个问题在提出两周后仍然未解决的话，自动升级过程将运转。该升级的第一步是项目经理，第二步是首席运营官。两个琐碎的问题几乎很迅速地就升级到了首席运营官那儿—他明确地表明他希望在升级以前项目组更加合作地解决问题。
不久，解决问题的时间急剧地下降。由于该过程以及其他的管理过程，该项目原本以为会延误三个月的，实际上却提前6周完成了。有效的框架过程能很好地提高项目工作的速度，改善项目组的工作。
计划项目框架的关键行动
 同意并撰写会议管理程序。
 积极地管理问题，包括利用正式的问题日志。
 制订项目文件的负责人和地点。
 确定并撰写交流沟通战略。
1.4 汇集项目定义文挡
一旦组织好了项目、确定了参数并且确定了框架，这些步骤的信息将一起综合成项目定义文档（ P D D ）。项目定义文档称为定义和组织信息的手册，在整个项目期间，作为促进理解和帮助制订决策的参考工具。项目定义文档的例子见附录。
2. 项目计划
2.1编制工作任务分析表
导致项目延迟的最主要的原因是那些偶然遗忘或者忽视的工作。为了使项目计划更可靠，一份项目计划书中必须说明达到目标所需要完成的所有任务，而不仅仅是其中的一部分。工作任务分析表的主要目标是系统化地识别项目所需要的所有工作。反过来，明确识别所有任务能使人们负责所分派的工作，这些“责任人”能定义完成特定任务的各项标准。
工作任务分析表是对完成某一部分目标所需要的所有工作的层次化分解（见图 4）。要产生各个层次，我们可以从最大的项目工作集开始，即从最大组成部分或第 1 层开始，将其逐步分解成更小的任务；也可以从最小的任务出发，通过头脑风暴法，组合成更大的集合。这两种方法分别被称为自上而下和自下而上。两种方法都能很好地工作。项目组决定哪种方法更合适。

图4- 一个软件应用驱动程序项目的工作任务分析表

如何定义任务识别的层次？这里有一些共同的规则。“最底层次的”任务（即处于每个分支最底层的任务）必须是：
 对于一般性的项目，该任务需要花费大约2天至2周的时间（对于学生项目则要花费1小时至半天）。
 只有一个责任人。
一种有效的编制工作任务分析表的方法是将整个项目组成员集合在一起，向每个人发一张报事巾，然后向他们提出如下问题：“为了完成交付物需要做哪些工作？”，当项目的主要组成部分和任务识别出来之后，把它们写在报事贴上，不同的分组贴在墙上。这个过程能进行生动活泼的决策，最终，整个项目组成员对达成目标所需要的工作都有一个更加深入的理解。

“那是谁的工作？”是项目经理最常问的一个问题。没有责任人的任务是无法完成的。项目给必须有一个正式的过程，（由整个项目组或者由项目经理）来指派任务责任人。指派任务责任人不仅能消除项目中存在的混淆因素，明显减少以后可能出现的一引起相互指责和推委的现象。而且，指派任务责任人还能增强责任感，因此有时会遭到反对。
一旦任务被识别出来，就要对每一个最底层的任务指派一个单一的任务责任人。因此任务责任人要完成任务，他们必须是最有资格执行这项任务的人。任务责任人要定义项目输出结果、负责执行任和汇报工作进展情况，这些者是十分关键的。将现任人的名字记录在报事贴上，在项目开发过程中，将这一信息始终与任务保存在一起。

2．2 编制进度表
大多数项目的核心问题是“它什么时候完成？”编制进度表这一步骤的目的是通过一个系统化方法来建立项目进度表。因为采用系统化方法编制的进度表更可靠、也更具有预见性。它们阐述了与达成项目目标所需要的任务、顺序和时间相关的、具体的战术决策，能进一步进有效的项目管理。

进度表的编制主要依赖于两个要素：任务之间的逻辑关系（被称之为依赖关系）以及每项任务的时间估计。将这两类数据组合到一个时间表中，就形成了实际项目进度表。
逻辑关系（比如计划评审图、，网络图、依赖关系和逻辑图）是项目所包括的工作顺序或者流程。它们通常在“依赖关系图”（图5）中显示。一个说明逻辑关系的经典案例是在穿鞋之前要穿袜子。这里存在一个逻辑过程：穿鞋之前穿袜子。（当然，要在穿袜子之前穿鞋，这也是可行的，但这会公共场合下带来尴尬，因此袜子露在了鞋子外面，这种改变逻辑关系的风险是一项关键的折衷性决策，本文稍后会加以说明）。对最底层的任务进行排序是编制项目进度表的关键的步骤。此外，任务排序工作还经常能发现一引起被遗忘的工作，从而会使人们回到工作任务分析表步骤。
虽然在任务之间存在着多种逻辑关系，一些比较有用的、普遍的关系是：
 终点到起点。
 起点到起点。
 滞后的起点到起点。
依赖关系
任务A

前导 后续
任务B
任务A
任务B

终点到起点（FS） 起点到起点（SS）

任务A

任务B

滞后SS

最通用和最容易使用的逻辑关系是“终点到起点（FS）”关系。在FS关系中，只有当后续任务（任务A）安然无恙成之后才能开始后续任任务（任务B）。例如，学生必须在接受课程指导之后才能做作业，在接受指导（前导任务）和开始做作业（后续任务）之间存在着终点到起点的关系。在一项任务结束之前，另一项任务不能开始。FS关系是非常线性的关系，因此容易管理。当然，并不是所有的工作都是纯线性的，因此在对于工作流建模时，还需要考虑其他的逻辑关系。
比较难使用的一种逻辑关系是“起点到起点（SS）”关系。它主要用来对那些可拆羇并联行处理、但在活动的起点之间存在关系的一件作进行建模。搭S-S关系中，一项工作不能从一个任务开始，而必须等到另一个任务开始之后才能开始。当然，一旦工作开始，则两项任务可以同时进行。例如，在一些合并和收购项目中，一份主要收购目标的清单已经形成草案但没有最终定稿，但是，一旦某一些名单已经进入了清单之上，那么对这些收购目标的财务分析工作就可以开始了。在这里，财务分析工作（后续任务）的开始要依赖于列入清单（前导任务）的开始而不是结束。但一旦两项任务都开始了，只要资源允许，它们就可以同步进行。因此，进度表显示了这引起任务之间的S-S的关系。
S-S关系的一个变异类型是”滞后的S-S关系”。滞后是任务之间的延迟，这里是指任务起点之间的滞后（也存在其他类型的延迟，但不经常使用）。例如，在开发新型计算机时，软件开发与硬件开发之间通常就存在这种”滞后的S-S关系”；软件小组在开始工作时至少需要硬件的设计说明，但一旦它们存在，它就可以和硬件开发一起同步进行。因此，”延迟”是对任务之间滞后进行建模。
尽管”滞后的S-S关系”具有允许并行工作和滞后的优点，它同样也存在着缺点，即后续任务何时开始是比较模糊的。因此，较好的做法通常是将”滞后的S-S关系”转化成FS关系，将较大的并行任务分解成可以建立FS关系的较小任务。
编制一份依赖关系图（图6）的实际过程是要显示出逻辑关系，使项目组成员移动写有工作任务分析表最底层任务的报事贴，直到将它们按一定的顺序连接起来。在项目组就是最终流程达成一致之前，预计要移动多次。

图6-计划评审图（“PERT”图）
草案 “PERT”图
软件驱动程序项目
项目经理：Jim Remick

初度进度表 

编制人：K.Hansen 第一页 评审日期：1/14/9x
里程碑的概念与逻辑关系的概念紧密相关。里程碑是指一个时间点，它通常用来表示出项目中的重大事件，并且使管理人员对它予以重视。因此，”完成引导测试”是许多制造型公司普遍的里程碑，”完成报告初稿”则是许多咨询公司的里程碑。里程碑之所以重要是因为它们通常表明了许多依赖关系的顶点。
里程碑有许多不同的类型，包括：
 项目的开始和结束。
 主要交付物的完工。
 正式的评审。
 关键事件，比如讲座或者商业演示。
 对项目环境以外的组织的依赖关系或者交付物。

尽管研究（和经验）表明项目中出现最多的问题是”遗漏某些任务”，但对任务时间长度的估计通常也是项目中的关键点和争论最激烈的地方。因此，进行有效的任务估计的最佳程序是：
 完成工作任务分析表。
 快速估计最底层次任务的大致持续时间。
持续时间不同于”工作”或者”进度表”，它是完成任务所需要的工作周期（小时、天、周等）的数量。一份好的工作任务分析表通常会给出关于任务长度足够的初步的持续时间的信，在项目进度的这一阶段对持续时间所作出的”快速和粗略”估计能够满足大多数项目的需要。任务责任人必须马上在该任务的报事贴上写下任务所需时间的最佳估计。
现在我们手已经有了依赖关系图以及快速估计的任务，就可以开始建立一份可靠的进度表了。进度表几乎是前面的项目计划过程产生的微不足道的最终产品。即,如果很好地定义了工作任务分析表、很仔细地构造依赖关系图，我们是非常容易建议一份可靠的进度表的。当然，如果这些前期步骤中任何一个被忽略，进度表的可靠性和可预见性将大幅度降低。
编制进度表时要将时间长度估计和依赖关系图填加到一份日历或者时间表上。最通常的方法是建立甘特图（图7）。甘特图按时间显示任务。它之所以流行是因为它容易使用，而且直观清晰、容易阅读和理解。甘特图可以手要编制，在时间表上按预计的时间和顺序画出所有任务，用直线表示其依赖关系。甘特图也可以使用项目关系软件包来完成。

图7-甘特图
草案 甘特图
软件驱动程序项目
项目经理：Jim Remick
工作任务分析表 任务名称 1月 2月 3月 4月 5月 6月 7月
1
1.1 项目计划
项目开始 
     
1.2
1.3 确定项目目标
规划项目框架 
     
1.4

1.5  编制工作任务分析表、进度表和资源计划
审核并批准项目计划 

    
1.6
2 计划完成（里程碑）
编制规格说明书和设计报告 
     
2.1
2.2 编制外部规格说明书
编制内部规格说明书 

    
2.3
2.4 编制财务分析报告
编制内部规格说明书  
    
2.5
3 设计完成（里程碑）
开发及测试驱动程序   
   
3.1
3.2 开发驱动程序
确定BETA测试地点   

  
3.3
3.4 编制质量计划
发送程序之前的质量检验   

  
3.5
3.6 发送程序进行BETA测试
进行BETA测试     
 
3.7
3.8 根据测试结果修改程序
开发完成（里程碑）      

4
4.1 商业发布的准备
编制技术支持计划 
  
 

4.2  编制最终财务分析报告       
初步进度表
 汇总 推迟的进度
关键任务 里程碑
非关键任务

编制人：k.Hansen 第1页 评审日期：1/14/9x
尽管甘特图本身是被广泛接受的工具，但作为一个系统化计划过程的结果，一份超过了预期进度的表总是不能被很好的接受。对于采用系统方法构造的进度表。人们通常的反应是”这术长了”（也被称为”进度表的震惊”）。但是，因为该进度表是经过慎重考虑才松造 出来的，对预计的完成日期的反对意见不久就会消失，从而集中支持一些权衡决策。

2.3. 资源分析
“如果我有更多的资源！”失败的项目经理总是这样喊着。尽管拥有额外的资源，资源问题总是存在的。仅仅只是增加更多的资源是很难提高项目绩效的。相反，项目经理要更系统地分析他们的资源需求。资源分析步骤的目的是向项目经理提供更多的关于实际状况的信息，使之能对三个参数进行更有效的决策。

典型的项目决策是在三个参数之间进行权衡：项目范围、项目进度以及项目可用资源。有效的资源管理基于一种有效的资源分析方法，是项目成功的关键要求。
尽管存在着许多用于分析和管理资源的工具，但对于较小的项目而言，它们大多数都是不太划算。许多非正式和分析方法也能起到同样的作用，其成本要明显低得多。
在甘特图上加上所指派的任务责任人，就构成非正式资源分析的基础。项目经理和项目组成员浏览甘特图，找到任务分派模式，例如：
 同一个人是大多数任务的责任人。
 同一个人是许多并行任务的责任人。
 某些人是极少数任务的责任人。
 许多任务以并行方式堆在一起。
 某些任务没有责任人。
既然可以存在许多不同的模式，在诠释这些模式时就没有一种通用的指南。但是，每一种模式都自然而然地提出一个问题，即项目组必须进行管理。资源运用模式将和项目范围、项目进度等数据一起用于权衡决策。

资源分析的关键行动
● 分析甘特图，得到资源运用模式
2．4．优化权衡
实施项目管理的主要理由是为决策产生更好的数据。这些数据通常代表着不同的选择，需要一次困难的决策。在好的项目管理中，为了得到最佳的整体结果，几乎总是需要舍弃一些期望的东西。权衡优化步骤的目的是使决策过程正式化和合法化。

权衡优化的关键问题：

● 是否在POS限度以内？
● 你是否能缩小项目范围？
● 你是否能改变项目任务的执行顺序？
● 你是否能重新分配或获取更多的资源？
● 是否存在着更好更灵活的工作方式来达到同样的结果？

有效优化的关键是检查整个项目计划，并且开发出创造性的方式使项目计划更有效。事实上与计划有关的任何事情都可能被改变，但这些变化必须以系统化的方式完成、并且所有项目参与者都知道这些变化。一些比较常见的变化是：
● 将项目从“是”项列表中移到“否”项列表中。
● 取消一个或多个主要交付物。
● 开发出不同的执行任务的工作方式。
● 改变依赖关系。
● 改变资源。
● 接受新的参数。
也许我们显然无法简单地描述优化过程。该过程既包括了明智的分析和合理的判断。从这个角度来讲，优化实际上是项目管理的精髓，因为它意味着真的要作出困难的决策。

例：一个项目要开发一种新型的、具有特殊用途的并行处理计算机，它们将计算机包含8个微处理器列为“是”项。尽管这是一个非常强大的设计方案，但也需要技术革新和开发。这是一个伟大的设想，但风险极大。项目组编制了项目计划，不久就发现项目在一年之内会失去市场机会。

项目组成员尝试了许多不同的“假设分析”策略来优化项目计划，包括将某些工作以并行方式处理、加入新的人员。不幸的是，所有这些策略都不能满足进度的需求，而且它们的代价都非常大。

经过慎重的争论之后，他们重新检查了关于8个处理器的需求。如果将数量降低到2人处理器，他们认为这种计算机可以按时完成，2个处理器尽管不如理想的数量多，但也足够在细分市场中建立他们的地位。他们做出了一项困难决策，减少项目的范围，从而能抓住市场机遇。

权衡优化的的关键行动：
● 分析整个项目计划。
● 建立一些“假设分析”。
● 作出权衡决策。

2.5.编制风险管理计划
所有项目都存在风险，这确实是一个真理，然而令人惊讶的是，项目人员忽略了风险。编制风险管理计划步骤的目的是使项目组注意到项目风险并对其进行管理。
编制风险管理计划的关键问题：
● 项目的风险是否已经明确？
● 是否定义了它们的优先顺序？
● 是否采取了行动来降低这些风险发生的可能性？
● 当风险发生了，是否存在应急计划？
● 你将如何知道风险是否发生？
● 谁负责管理项目风险？

如果在项目开始时询问项目组成员，事实上每个人都能够描述出项目成功的关键风险。同样，在失败的项目中，人们几乎总是说失败的原因其实事先就已经知道了，但没有采取相应的措施加以防范。人们往往知道存在项目风险但很少主动地去管理它们。
这种自相矛盾的现象是由许多原因造成的：
● 人们不相信风险会发生在他们身上。
● 没有时间去考虑和管理风险。
● 人们过于自信，认为风险发生时他们也可以克服。
● 人们不喜欢管理风险。
因此，风险管理方案必须同时与上述原因中所隐含的乐观主义和管理风险能用的时间相一致。在此我们提出这样的方案，它包括两个组成部分：
● 风险评估。
● 风险管理。
在风险评估时，项目组要花费一些时间进行脑力激荡，列出项目中可能存在的所有风险，然后非正式地选择对项目威胁最大的两至三项风险，并编制出管理这些风险的计划。
风险管理计划应当提出降低风险发生可能性的措施（预防措施）以及风险发生时要采取的措施（应急措施）。预防性措施可能会在项目计划中加入更多的任务。应急性措施需要一个触发标准，以通知项目组何时需要启动风险计划。例如，对项目最终完成日期10%的偏移将启动一项应急计划来减少项目范围。具体的偏移量就是应急计划的触发标志。
通常，风险管理计划要简略地记录在项目文件中。在许多情况下，项目组会指派某个成员来负责监控项目的触发标准并通知项目组需要启动应急计划。

例：某家公司承担了一个项目，为整个校园系统铺设光纤，使计算机能够安装在所有的教室和办公室里。项目必须在开学之前完成。

该项目需要大量的光纤。风险评估表明从主要供应商得到光纤存在巨大的风险，因为所需要的光纤数量非常大，而且供应商正在处理一个非常棘手的劳资纠纷问题。项目经理和项目组采取了如下预防性措施：
● 拜访供应商，确定其生产能力的正式状况。
● 储存额外的光纤（在合理的额外费用下）。
● 建立和其他供应商的关系，包括下一些小的订单。
● 储备一些“应急”资金，以备可能出现的、超出正常价格的采购。

不幸的是，在学校即将开学之前，供应商不能交付所有需要的光纤。项目经理启动了应急计划，使用应急资金从其他供应商处采购光纤。尽管公司损失了一些毛利，但损失是很小的，而且项目在学校开学之前完工。风险管理计划直接推动了项目的成功。

编制风险管理计划的关键行动：

● 确定所有项目风险并确定其优先顺序。
● 编制风险管理计划，包括预防性措施和应急计划。
● 指派专人管理项目风险。

3．项目跟踪和管理
3．1 搜集状态
3．2 计划和采取相应的措施
一旦项目启动，保证其不偏离轨道甚至是比第一次制订项目计划更艰难的挑战。跟踪和管理步骤的目的是让项目是让项目经理和项目组把注意力重点放在那些提供项目进展最优信息的领域。好的信息又反过来会帮助项目经理和项目组面对所有项目中发生的动态的变化，相应地作出更好的决策。
搜集状态的关键问题
● 正式的“搜集状态”的频率是多少？
● 如何进行？
● 需监控什么信息？
● 要作什么决策？
● 要采取什么措施？
● 如何沟通这些决策和措施？
好的规划真正带来的收益是项目极好的“实时”管理。实际上，有效的跟踪让项目组的重点和精力如此集中，项目组经常会觉得热情高涨，会检查项目的进展和作出及时的决定。同时，并不是所有的人都喜欢项目跟踪。对于他们而言，跟踪意味着严格的责任、过多的繁文缛节，以及得分配更多的时间做项目工作以外的事情。对于这些人来说，跟踪是件讨厌的事，应该尽可能地少做或者应该完全忽视。
使这两种看起来相对立的观点协调一致并不难。如果跟踪体系足够简单，只需花很少的时间维护，但体系却非常有力，可以给项目经理和项目组提供制订有效的决策所需要的所有数据，则项目跟踪可以高效并且甚至令人愉快。如此简单的体系必须将重点放在那些影响决策的数据上。令人吃惊的是，这样的话并不会产生很多数据。
一套好的跟踪体系仅对三个有限的主题搜集状态信息——进度状态、未决问题和风险。
进度状态包括：
● 按进度应在该期开始的任务是否已经启动？
● 如果没有启动，能做些什么才能让它们启动？
● 按进度应在该期结束的任务是否已经完工？
● 如果没有完工，能做些什么才能让它们完工？
未决问题包括：
● 所有未决问题的状态如何？
● 能采取什么措施来解决它们？
● 是否有些新的未决问题？
风险包括：
● 风险状况如何？
● 是否有新的风险？
这三个方面阐明有效管理项目所需的所有项目信息。收集这些数据是容易的。可以利用声音邮件、电子邮件或者会议来搜集这些数据（虽然最好是在会议前就搜集信息，通过会议来界定问题和指派行动）。通常，项目状态信息是每周搜集，虽然在一些短期或者尤其重要的项目里可以更频繁地搜集状态信息，或者在一些较长期的项目里减少频率。
虽然还有些更复杂和更全面的跟踪体系，但该体系通常是以满足大多数的需要。
显然，一旦搜集了状态信息，项目组就必须调整计划并且采取相应的措施。这里的决策与优化步骤里的决策完全相似。通常项目组可以：
● 将项目在“是项”清单和“否项”清单之间移动。
● 去除一个或者多个主要交付物。
● 制订不同的方法来完成任务工作。
● 改变依存的关系。
● 改变资源。
● 接受新的参数。
再次，项目管理的精髓在于根据大量的项目数据制订艰难的决策。这些决策发生在整个项目的生命周期内。
例A：一个咨询公司的项目组受委托为一个准备推出新产品线的客户做一次全世界范围的市场研究。接受委托时，一个需主要关心的市场是东欧和苏联。当项目组打算开始做与项目该部分相关联的任务时，苏联发动了政变，加速了该国的瓦解。与东欧和苏联市场相关的任务因此延误。在审查后，项目组决定在那种决定下做研究的价值实在是太小了。
咨询项目组和客户一起审查了集中选择方案，并决定推迟研究中东欧和苏联的那一部分任务，将研究的重点放在太平洋沿岸。虽然该决定代表着项目的范围、进度和资源的变化，但这是在当时的情景下最好的决定。任务延迟的报告触发了一些关键的业务决策。
搜集状态和采取相应措施的关键行动
● 确定搜集状态的频率。
● 确定将如何搜集（电子邮件、会议等）。
● 分析状态对项目的影响。
● 采取相应的措施。
3.3 结束项目
如果我们正式抓住了项目中该学到的知识，则会显著地提高接下来的项目
的项目管理。结束项目这一步骤的目的是正式地捕捉主要学习到的内容和一些
反思，以期望改善未来的业绩。
结束项目的关键问题
● 项目管理中的哪些方面是有效的？
● 哪些方面可以改善？
● 将如何改善？
● 是否完成了所有的书面工作？
● 主要的所学内容是否已记录在项目文件中？
● 如何在将来的项目中使用学习到的知识？
● 项目文件是否存档于某个地方？
● 你们将如何答谢和庆祝？
项目经理和项目组成员通常都非常繁忙地进入下一个项目，而没时间正式地结束一个项目。但是，这种仓促意味着个人和团队都失去了成长和改善的机遇。那些愿意花时间（可以只是几个小时）来正式结束项目的项目组大部分都能更高效地从事于下个项目。
结束项目方面的典型活动包括：
● 评估增加了项目有效性的实践。
● 评估那些不如预期有效的实践。
● 为将来的项目制订可能的过程改善。
● 对人们所作的贡献给予答谢。
● 完成项目的文书工作。
● 项目文件存档。
● 庆祝项目的完工。
尤其是对有效实践和不甚有效的实践的评估、可能的改善和庆祝活动经常对下一个项目的效率产生影响。
例：一家纸业公司的项目组用了一天的时间来“结束”项目。项目组成员在活动挂图上描述出所学到的关键知识、讨论了改善的选择方案并制订了行动计划，并举行了很棒的聚会。因此，在接下来的一周里，项目组成员都觉得很乐观，并开始系统地实施它们的过程改善方案。
结束项目的关键行动
● 进行正式的汇报。
● 完成文书工作并进行项目文件的存档。
● 对项目组成员的贡献给予答谢和报酬。
● 庆祝项目的完工。
附录：全明星电影——项目定义文档
简介：
该文档是对全明星电影项目的定义文档。由以下各节组成：
项目目标书
主要交付物——定义
主要交付物——时间目标
项目组花名册
主要风险
关键框架过程
该项目的定义文档和项目优化进度计划一起代表着业务基线。所有的变化都需要应用于该基线。
项目目标书
在1997年6月1日前拍摄并发行一部动作片，成本为3500万美元。
主要交付物——定义
最终交付物
该项目的最终交付物是一部完整的、经过剪辑并发行的影片。最终交付物和每个主要交付物的“是项”/“否项”
请单见附录。
主要交付物
该业务主要有三个主要交付物。
1、 全面的准备期安排
团队将分析影片所需的所有的准备期工作。团队将制订实施准备期工作的书面计划。计划应得到导演和制片的批准。团队还将完成所有的准备期工作，包括与“明星”签约、剧本的最后定稿以及制片人员饿雇佣等。
2、 影片的初步剪辑
团队将完成影片的首次制作，包括实地拍摄、摄影棚拍摄以及初次的剪辑。制片和导演都得批准影片的初步剪辑。
3、 适于上演的影片剪辑
团队将为上演影片最终订稿。包括重新拍摄所需场景、声音的编辑、色彩的修正和试播。制片和导演都得批准影片的最终剪辑
4、 影片的有限发行
团队将会选择一些电影来有限地发行影片。发行工作包括：制作5000份拷贝、关键刊物上登广告以及安排明星参加电视上的“脱口秀”。根据观众的反映，可能会进行更全面的发行。
主要交付物——时间目标
下表中列出的是主要交付物的目标完成时间。在详细的项目计划完成、优化并得到制片、导演和制片厂确认之后，才需遵照执行。

主要交付物  目标完成日期
全面的准备期安排 10/1/96
影片的初步剪辑 4/30/97
适于上演的影片剪辑 7/31/97
影片的有限发行 10/31/97
项目组花名册
项目团队
克拉克.肯特 项目经理
布鲁斯.韦恩 导演
西利妮.凯尔 准备期经理
迪克.翠喜 制片经理
赞助商
埃里克.凯恩 制片

主要风险
经过初步的风险分析，认识到下述事项对任务的成功有“高”风险：
● 无法与大腕明星“签约”可能会削弱票房的成功性。
● 实地拍摄可能会因为多雨的天气而放慢。
● 剧本没有按时完成。
● 在“拍摄”时剧本可能会重写。
● 特技实验室可能无法按时准备好。
关键框架过程
项目文件
项目文件由克拉克.肯特实地维护。没隔一周备份一次，存档的拷贝保存在Vue制片厂的总部。
事情/行动项/变更跟踪
使用标准的事情/行动项/变更跟踪日志。所有的事情/行动项/变更都将记录在日志中，并每周审查。
会议
每周周一的上午开会，审查状态报告并确定新的行动项。

附录A ——影片项目的“是项”清单和“否项”清单
交付物#1。全面的准备期安排
是 否
● 与主要明星签约 ● 与临时演员签约
● 完成剧本的第二稿 ● 最终稿
● 安排场景，包括到场景的旅行计划 ● 将设备运到场景
● 与制片人员签约 ● 开始制片
● 由制片和导演批准 
● 书面的制片计划 

交付物#2。影片的初步剪辑
是  否
● 完成电影的拍摄 ● 额外场景的拍摄
● 初步剪辑 ● 色彩的更正
● 由制片人员放映 ● 最终剪辑
● 最终稿 ● 观众测试
● 由制片人和导演批准 

交付物#3。准备上演的影片剪辑
是  否
● 最终剪辑 ● 发行
● 色彩的更正 
● 声音的更正 
● 由制片和导演批准 
● 观众测试 
交付物#4。影片的额有限发行
是  否
● 对有限数量的影院发行 ● 全面发行
● 在部分刊物上作广告 ● 全面的广告
● 明星在脱口秀上的采访 ● 欧洲式发行
● 给审查者的播映 
● 制作5000个拷贝 
项目后评估的重要意义
法兰克.R.古利威

如果你的企业同大多数企业一样,可以花几千小时策划一项投资,耗费数百万美元实施一项投资,但却从不进行项目评估,也不在其中吸取经验教训,那么你就无法解答最基本的问题---投资项目是否成功?它能否按期进行?按期完成的原因是什么?虽然这些问题表面上很简单,实际上却不太容易回答.
BP(BP公司)在澳大利亚建立了一家工厂,把天然气转化成为高辛烷汽油，工厂建造成本控制在预算内，并且提前完工。相比之下，在鹿特丹建造一家同样的工厂，不仅成本超出了预算，而且工期比原计划晚了一年完成。一开始，BP管理者做出了一个显而易见的结论：澳大利亚的项目是成功的，荷兰项目是失败的，但进一研究的结果却对此结论提出了质疑。
澳大利亚项目最初拟定时，澳大利亚正面临国际收支赤字的重负，人们期望该项目能够帮助该国降低石油进口。但是当工厂提前完工时，澳大利亚的经济状况已经有所改变，结果，市场上汽油的实际需求量低于预期水平。
虽然鹿特丹项目存在明显的问题，但该产品在欧洲依然有非常强的市场潜力。所以，鹿特丹项目的投资收益率最终与预期持平，而澳大利亚的收益率则相对较低。鹿特丹项目的成功让BP的高层管理者获得了非常宝贵的经验：项目规划者必须改进自己对市场预测能力。
BP在伦敦总部设有一个独立部门负责处理这些问题----项目后评估部（PPA）。这个部门主要调查投资项目的运作理念、项目管理和项目结果。PPA的唯一的使命就是帮助BP全球组织从错误中吸取经验教训，学习和推广成功的经验。
自1997年成立以来，PPA已经对80多项BP世界各地的投资进行了评估，包括陆上和离岸的建设项目、收购、分割、项目撤消、研究项目、多元化方案以及运输计划等等。这类评估并不是纯粹学术上的练习，而是为了改进公司业绩的一项努力。
BP管理层通过PPA学会了如何更准确制订投资计划、以更客观地态度审核批准，并更高效地执行这些计划。这样做的结果是，大多数项目的投资收益率相当于甚至高于预测水平。这些改进措施也提高了公司的总体财务表现。1985年，BP的税后利润达到了前所未有的15.98亿美元的水平，虽然PPA不是唯一的功臣，BP经理们相信，这个部门的工作的确起着相当重要的作用。
广角查询
当我与英国的大型企业和跨国企业员工交谈时，我发现很少有对企业完成的项目进行深入的研究。大多数审计工作只局限于小范围，侧重项目过程中的控制因素。例如，当经理们对一家炼油厂进行审计时，他们会详细收集石油与天然气采集、称量与运输的信息，并找出这样做的原因。
而项目后评估则需要更广阔的视角。项目后评估首先审视的是总体问题：为什么要启动这个项目？它是否能够产出预期的石油？石油的需求量是否和预计水平相当？承包商能否遵守承诺？项目是否符合BP公司的整体战略？
在美国企业采用的“项目完工评估(post-completion review)”中.一些企业对过去的项目进行了类似的广角评估。但是这种评估与BP的项目后评估在客观性和适用性上有所不同。首先，美国企业的项目成员会参加项目的后期评估，他们不可避免地持有成见，或者在评估中有个人利益的考虑。而BP的PPA员工则与被评估项目之间没有任何关系，所以能够以从客观的角度评价投资项目。
另外，美国企业的做法并不能保证最需要的人能够得到这些宝贵经验，因为一切仅仅靠口头传达。而PPA则是设在总部的一个部门，它能够对分布在世界各地的BP子公司的任何投资项目进行视察，并把信息从一地传到另一地。比如，它能够从法国的炼油厂项目获得经验教训，并把这些经验教训传达给澳大利亚的工厂规划者。
PPA还是BP投资审核流程的一部分。该部门负责审查所有的投资建议，确保没有错误重复产生。如果有时间，他们甚至会与项目规划者一起制订项目建议书。
评估流程
PPA部门由一个经理，四个助理组成，直接向BP董事会报告。部门成立九年来，员工组成当然有所变化。不过PPA的经理必须满足同一标准：他们必须为BP最高管理层所接纳，而且在BP至少有15年的广泛工作经验。其他成员则由公司根据专业特长挑选，他们可能是工程师、化学家、物理学家、经济家或会计师等等。每个项目一般由两至三名员工负责调查。
一项大型投资项目的评估通常需要花6个月的时间完成。因为有限的时间内只能处理有限的信息，因此该部门每年只进行六次大的项目评估。最有价值的经验来自那些巨额投资项目，而它们也是BP最有可能赚大钱或亏老本的地方。PPA总是小心仔细地选择评估项目，以找出最有启迪的项目。
因此，该部门不会选择那些已有前车之鉴的项目，也不会选择BP不可能再次实施的项目。比如，该部门曾考虑对BP与另一家大型石油公司合作的原油销售合同进行评估。但由于中东国家对其油田进行了国有化，BP不可能再签订这样的合同，于是PPA决定放弃该项目研究。
项目研究的开始 BP经营11类不同的业务，每类业务都有自己的董事会及首席执行官。这些业务分支向BP的中央管理层报告，而中央管理层由公司的一个中央董事会所领导。由BP中央董事会成员组成的公司评估委员会负责对所有PPA的评估报告进行审议和批准。该委员会不仅主管PPA的所有事务，还负责审查所有的资本投资项目是否符合公司战略。PPA向该委员会建议未来18个月到2年内能够评估的项目，委员会通常都予以批准，不过偶尔也否决或增加一到两项。
随后PPA将决定项目评估的次序，并与该项目所属业务的首席执行官一起确定每项调查的大致时间表。
PPA的研究从项目形成概念（项目建议书尚未拟定）开始，通常到项目运用两年后结束。研究小组总是试图系统地回顾项目运作的整个过程：提议阶段、建议阶段（如果涉及收购，则为目标企业的购买阶段）、项目运营（被收购企业与BP的融合）阶段以及项目正式运营后（整合后）阶段。PPA总是努力找出那些致胜或者项目出现问题的关键因素。
虽然人们能从问题的产生和演变过程中获得更多的教训，但该研究小组发现，了解致胜因素也大有裨益。举例来说，高层管理层都认为，整合亨德里克斯这家荷兰营养公司是迄今为止最顺利的收购。PPA则把其成功的主要原因总结为项目规划者能够准确地判断亨德里克斯与BP的整合程度。
档案材料及面谈 评估初期，评估小组依靠各种档案熟悉项目有关情况，这样就能够避免浪费人们的时间。通过阅读档案，评估小组可以了解当时了经济环境、承包商身份以及采用的化学流程。在六个月调查期内，评估小组会花两个月时间熟悉各种档案----与项目有关的材料以及企业档案，在会计、法律或规划部门寻找相关资料。
虽然PPA经理已知道参加面谈的高级经理人选，但是详细的档案资料能够提供一张完整的清单。评估团队一般尽量访问所有和项目有关的人员。由于大多数项目在评估小组开始工作的前两年就已经完工，而且当时的成员如今可能分布在世界各地，这是一项并不容易完成的工作。在某项调查中，PPA团队一共和80个人进行了会谈。通常来说，调查的平均人次达到40人。
在会谈中，PPA小组会设法了解项目成员和经理人的心理状况。参加面谈的成员通常是两个人，一个人问问题，另一个人观察被访者。不论是掩饰性的表情，还是坦率的回答，都能透露出大量的信息。
会谈后，两个小组成员会对照彼此的笔记，并协调双方在看法上的差异。通过零碎的信息可以凑成完整的答案：比如，在伦敦的高级经理提供一条信息，在北海某石油钻井的工程师将提供另一条信息。PPA小组将项目成员不同的观点融合起来就拼出了一幅完整的画面。
PPA研究员发现，项目成员能够就与他们的专业毫不相关的问题提出很好的见解。那些在野外工作的人一起生活、进食、一起出去喝酒。所以，毫不奇怪，即使双方并不在一个部门工作，一个会计师却能够对总工程师提出令人信服的看法。
将PPA研究员派到野外进行调查的成本比寄送问卷的成本高多了，但前者的效果却非常好。由于问卷只是一堆事先定好的问题，所以人们从中只能获得有限的了解。而在面谈中，被访者往往会提供意想不到的信息，而且PPA研究员也能在谈话中及时提醒，防止谈话离题太远。
研究结论与人们的反应 项目后评估小组得到了BP员工的大力支持。在该部门的九年历史中，PPA遇到的几乎所有员工都真诚地希望，通过项目业绩的调查使公司的利润增长再上一个台阶。就连那些表现不够好受到单独批评的人也一如既往地重视该部门的价值。一次，某评估总结认为一位高级经理没有尽责，结果公司评估委员会把他叫去，痛斥一顿。后来该经理与PPA的关系一度较为紧张。但几个月后，他又致电PPA，了解一个与他手头项目类似的项目报告。显然，他希望得到良好的建议。
BP员工与该部门配合的一部分原因是希望在结论出现在PPA的报告之前获知这些问题。但是，虽然如此，却没有人利用这种机会来欺上瞒下，这一点也证明了PPA工作的公正和准确性。
当研究小组翻遍了所有的材料，与所有有关人士进行了面谈，分析和总结了相关的信息，并把初稿提交给主要经理人传阅之后，才向董事会和公司评估委员递交了最终报告。委员会将仔细审视研究小组的报告，一般情况下，委员会总是支持研究小组的结论，它收到建议有成千上百件，仅仅只有一件被驳回。被驳回的建议认为BP应当聘请冶金行业内的各类专家以弥补承包商的不足，但是这样做的成本显然太高。
BP并不把报告的完整版本让公司全体员工传阅，当然，相关的经理能够获得完整报告，BP会把这些报告压缩成三个小册子，主题分别是收购、合资企业以及项目开发与控制。PPA会定期对这些小册子进行更新，增加最新的评估内容，删除一些过时的经验。删除的案例之一是鉴于英国劳工关系的紧张，建议在欧洲大陆而不是在英国建立炼油厂。但此后英国的劳工关系大有改善。
BP的高层管理希望项目规划者能够利用这些小册子中的信息作为撰写项目建议书的指南。当然，一个项目没有必要符合所有规定，但如果项目规划者不能认真的地重视和奉行这些指导方针，公司评估委员会则认为该项目必定蕴藏潜在的风险。
PPA将这些小册子分发到BP在伦敦的11家业务总部以及全球30家BP子公司。如果任何部门还需要，该部门都乐意提供。PPA的理念是让更多的BP人了解公司过去发生的事件，懂得什么是正确的、什么是错误的，只有这样，公司的投资业绩才能大幅度提高。
从十年前尝试性的开端到如今成熟悉的运作，PPA部门已经发展成为BP项目规划及控制中不可缺少的一部分。由于一向坚持挖掘真相，它获得了极大的声誉和良好的口碑，BP的高层管理以及董事们对这个部门绝对信任，他们相信研究报告中的事实及结论都是正确的。由于研究小组在调查中穷尽一切努力、不放过一个细节的精神，由于他们对技术事务了解，由于他们在评估一项证据时表现出的公正，也由于他们对员工心理的微妙把握和对激励手段的了解，他们的报告具有了从称赞的准确性和可信度。由于具有了这种准确性，公司上上下下才能从中获得有益的信息，项目评估小组的成功也才是众望所归的。
项目后评估给我们的启示
课堂上学到的知识与实践中获得的教训存在很大的区别。理论上不言自明或根本不可能的恰恰就是实际生活中的关键因素。下面我将介绍在采用PPA建议之前BP进行的一个项目。
1967年，BP负责工程及冶炼的一位董事希望开发埃克森美孚石油和其他公司已经使用的一项新技术。该董事在公司很受人尊重，而且有相当大的号召力。凭借个人魅力，他督使建造了BP有史以来最庞大的工厂。埃克森美孚的一家工厂在三条生产线上生产3万桶石油，而BP却要在一条生产线上生产同样产量的石油。为了建设这条生产线，BP需要有史以来最大的压缩机和油泵，而且反应堆容器必须采用全新的技术。
在工厂的建造及测试期间，公司在这三种设备上都遇到了困难，而且反应堆容器的问题更大，因为该反应堆容器的体积庞大，它应该比一般的容器壁更薄，所以需要用不锈钢作为内衬。虽然BP的承包商向管理层保证这工作很轻松，但他们还是碰上了一连串的问题。最后，还是BP自己的工程师耗巨资解决了这些问题。
通过了PPA对这个项目的调查，BP获得了很多经验教训，它学会更仔细地评估各种项目提议。它学会更全面、更客观地了解新技术的风险，它懂得必须对承包商的选择更加慎重的科学。也许公司早就应该明白这些道理了，不过在PPA阐述这些经验之前，它显然还没有学会如何吸取教训。项目后评估的作用就是系统地分析和总结这些经验，把它们汇编成正式文章，让大家清清楚楚地看到发生的一切。
所有公司的经理都会犯意料之外的错误。项目后评估小组的职责和作用就是不断地发现这些问题，并帮助BP避免再犯同样的错误。
四大教训
过去十年，PPA让BP管理层获得了四大宝贵的经验教训。它们是：
确定准确的成本
PPA成立以前，BP管理层会批准那些不符合现实的低预算项目，因为项目规划者在提交预算时错误地预测了项目规模。现在BP则分不同阶段批准预算，每个阶段的预算会随着规划者对项目细节的了解而更加准确。
第一阶段，工程师首先提供项目预算的粗略数字，这个数字有可能与实际相差至少50%。然后董事会将批准相当于该金额的1%聘请外部工程师和咨询专家更完整地进行项目设计。之后，工程师会提交更准确的预算。最后，当董事会批准整个工程时，它的最终预算与实际间的差距不超过10%。
BP现在更关注当地健康、安全以及环境法律方面的技术要求。公司经理不仅仅考虑当地立法要求：为了准确地预测成本，项目规划者在项目提议阶段就要考虑，要满足所有法律要求应注意哪些设计问题。
现在，经理们已经学会，不必为了获得政府的援助贷款或其他奖励而催促项目的审批。过于仓促的项目常常准备得不够完备，所以从一开始就会失控、拖延工期，最终超过预算，甚至于超过预算的部分抵消了利润贡献。
公司不再总是把合同交给竞标价最低的承包商。他们的价格之所以低是因为他们并不了解BP的真正需求。PPA发现，竞标价低的承包商往往不会交出一份好的答卷。
预测并最大程度地减少风险
有时候，在试图进行收购业务时，BP的某个部门会担心竞争对手抢夺时机，所以就加快审查速度以及决策过程。而PPA部门发现，这种自我定下的最后期限往往都是幻觉。另外，如果一项收购计划被证明并不明智，BP也宁愿不要这个机会。
过去，BP曾经在不了解情况的前提下就决定生产规模，而根本不考虑新工厂的产品是否能卖掉。现在，公司在决定增加生产能力或开设新工厂前，都要求提交完整的调查报告，确认市场的潜力和盈利能力。
承包商评估
BP现在专门设立了承包商评估部来监察承包商的表现。公司在招标时，往往已经心中有数，哪家承包商最有可能达到自己的要求。而在以前，BP挑选承包商的方法还不成熟，它常常并不了解承包商的弱点和优势，也不知道这些承包商在承包其他项目时的表现好坏。
为了确保承包商在项目整个过程中表现专业的技能，BP现在非常仔细地了解对方关键员工的能力，而且一定要这些技术上的好手一直坚持到项目结束。
改善项目管理
未经历练和雕琢，一个工程师不会自己摇身变为优秀的经理人。公司常常把某个项目的工程师调到世界上另一处尚未完成的项目中去。没有人去问这个工程是否熟悉这个工程、所在国家、甚至主要的承包商。在PPA的建议下，BP建立了项目部帮助工程师发展自己的控制技能和学习控制流程，并切保证专门的项目由专人管理。
为了把项目进度报告编写得更加完善，工程部建立了工程控制分部。分部使用软件系统与每个项目连接起来，帮助项目经理撰写报告，识别可能的问题，并提出为什么没有达标的理由。这些报告可以通过项目控制分部的计算机中心输入，每天，甚至每分钟都可以对项目的进度进行评估。
项目部还做到尽早确定项目经理，使他们可以早早地参与设计规划、项目战略以及控制系统的工作中。在项目部的指导下，项目经理可以进行更独立的决定。
资本投资分析师常常把各种学术研究的成果提供给经理人作为建议，但是这些内容仅限于收购方面。现在，有了项目后评估，经理们可以就各种类型的项目问题从公司自身的经验教训中寻求明智的建议。
项目结构与项目绩效
下面概述了对几种项目组织结构的有效性所做的研究。该有效性是从这些组织结构对技术、进度和成本的影响等角度做出的衡量。该研究旨在考察项目所涉及的问题是否因组织结构的不同而不同。
范例
以下研究是项目管理研究所（PMI）组织的一次项目研究的一部分。该研究所系项目管理开业者协会，拥有来自世界各国的15000多名成员。
数据是以问卷形式邮寄给抽选的加拿大和美国的PMI成员而收集的，回收率达64％。有效答卷1，484份。这些答卷者根据他们熟悉的一个完整的近期项目答卷的，从采用的结构、遇到的问题和取得的成绩等角度做出评价。
62％的项目与建设有关，涉及的范围包括从扩建电站到创建海外国际机场。
余下的38％的项目是开发性的，涉及新产品、服务或加工。该类项目涉及面甚广，包括研制激光制导雷达系统，从环保角度评审危险废物处理系统、合成燃料的研究和开发，以及研制新抗生素。
46％的答卷者系项目经理，33％为项目成员，11％的人是监督项目的高层管理人员，余下的10％是直接或间接参与项目的部门经理。
该研究虽有过时之嫌，但它所反映的问题对于今天的项目仍有普遍意义，为我们探讨不同组织项目方案的相对优缺点提供了有益的启示。
项目管理结构
拉森（Larson）和高贝利（Gobeli）（1985年）详细地阐述了五种项目管理结构，符合盖尔布雷斯（Galbraith，1971）的早期研究结论。这些结构以设立项目经理和强调项目经理的相对作用为基础，然后建立依次从职能部门到真正的项目组共五种类型的整个系统。表A对此做了归纳。
问卷要求答卷者根据A所列的情况，确认完成他们所审的项目是用了哪个主要结构。
使用每种结构的项目数量如下所示：
建设性 开发性 合计
职能型结构 74 80 154
职能矩阵型结构 148 150 298
平衡矩阵型结构 135 97 232
项目矩阵型结构 395 158 553
项目组型结构 161 86 247
衡量项目成功度
项目成功度是指项目结果与预期的绩效、进度、成本等目标之比较。问卷要答卷者根据项目所采用的结构，就每项目标的实际情况是“失败”、“勉强”，还是“成功”对某一特定项目进行评级。
就技术发挥而言，职能型结构和职能矩阵型结构的成功率在50％以上，平衡矩阵型结构为70％，项目矩阵型结构和项目组型结构接近80％，该结构拥有越强有力的项目经理，技术水平越高。
成功率与项目经理权限成正比的格局在进度和成本上表现得尤为明显。在本例中，项目矩阵型结构和项目组型结构的成功率均近乎职能型结构和职能矩阵型结构的两倍。平衡矩阵型结构介于两者之间。比方说，在成本控制上，职能矩阵型项目中成功的不到四分之一，而项目矩阵型项目的成功率超过一半。
对项目总体成功度作评估，这种基本格局不变。总体成功度指对项目结果的全面衡量，不拘泥于技术、进度和成本等方面。有时逾期或超过预算成本，项目也算是成功的，尤其是项目的完成重于进度和成本时。
五种结构的总体成功度因项目类型不同而不同。就建设性项目而言，项目矩阵型和项目组型两种结构的成功度远远高于职能型或职能矩阵型结构的成功度；平衡矩阵型结构介于两者之间。开发性项目的格局稍有不同，其项目矩阵型和项目组型结构的成功度于建设性项目。其中原因也许是开发性项目比建设性项目风险大，因而影响平均成功度。另外还有个小小区别，即开发性项目采用职能型结构，其效果比建设性项目采用职能型结构更差。
影响成功度的因素
问卷要求答卷者对所涉及的每个项目指出最大的问题所在。对问题的阐述编为三大类：项目界定、组织设计和项目实施。这种方法遵循了自然顺序：确定项目的范围、目标和进度－>组织项目，配备人员－对项目进行指导和控制。项目界定（43％）最棘手，接着是项目实施（34％），然后是组织设计（23％）。
每一类中的具体问题待后讨论，先要考虑的是这些问题如何因结构而异。尽管在组织
设计方面的问题随项目经理的作用的加强而减少，因而项目组型结构出现的问题最少。项目实施方面的问题呈现相似的格局，只是与项目矩阵型结构相比，项目组型结构的问题更大一些。项目界定方面的问题随项目经理的加强而加大，对比，项目组型结构也是一个例外。项目组型结构出现的问题比项目矩阵型结构少。
项目矩阵型结构与众不同，它在项目界定方面的问题最大，而在项目实施方面的问题最小。造成项目界定问题大，可能因为许多项目为了制定一个易于实施的方案常常广泛征求意见，经过层层审批。建设性项目就往往出现这种情况。
项目界定的具体问题
大多数结构蕴含高难度的项目界定问题（包括制定计划、确定进度等传统管理活动）表明，这是项目管理中最普遍的一类问题。这类问题具体包括五个方面。
界定不明确
项目界定中将近35％的问题与目标、范围不明确或不现实及方案或设计不可行有关。对预期之事界定不明确意味着方向不明确，此乃项目管理成功之大碍。
进度安排不当
项目界定中28％的问题与进度安排有关，其中包括进度安排不合理或不切实际，各环节不履行规定的进度安排（结果影响其他环节的进程），以及未对进度表作适当调整。
决策不力
项目界定中20％的问题归因于决策缺乏有效性，包括开发项目未管理人员深思熟虑便急于上马，项目不分轻重缓急，决策过程草率，缺乏评审过程草率，缺乏评审机制或评审过多，决策过程没有要人参与，以及高层管理者缺乏决策能力。
信息不充分
9％的问题归咎于信息不全或信息不多，包括计划制定者对设计者提供的信息不够，对消费者的要求估计错误，缺乏成本观念，对关键技术分析不够等等，结果造成决策不力，方向不明。
变化因素

8％的问题涉及项目的范围、目标、优化顺序、设计等方面的变化，其中，项目范围的变化大多造成人们对项目的模糊。
项目组织设计上的具体问题
组织设计包括组织结构及相关的人员配置，或传统管理中的组织和人员配置。该类问题主要有三个方面。
人员配置
53％属于人员配置问题，包括没有按需配置人员而造成不能按时按质完成项目，项目经理不能胜任且缺乏必要的技能和经验，主要人员调度不当，以及人员不称职。
缺乏责任感或职责不明
27％属于责任和职责方面问题的，包括项目成员责任不明确或没有赋予责任，对职责范围内的事不负责任，以及一人的职责过多，委派参与的其它项目过多。
项目经理不得力
20％的问题是由于项目经理威信及在需要的情况下而没有设项目经理、项目经理缺乏高层管理人员或职能部门的支持、官僚规章消弱了项目经理的作用。
项目实施上的具体问题
项目实施上的问题包括传统管理中的指导和控制。答卷反映了这方面存在五种问题。
控制上的问题
控制上有21％的问题，包括后续措施不力、监督不严、完全没有控制系统及不善于发现主要问题。
缺乏协调
27％的问题出在项目活动和资源配置不协调上，造成任务不能按时完成，重要资源需要时不能到位，经理之间－象项目经理和职能部门经理之间－互不配合。协调不够还表现在重复劳动。
缺乏沟通
19％的问题是缺乏沟通，包括项目成员之间或经理之间互不沟通、出现问题不反映。而大多数答卷者只是表示，“缺乏沟通”是一大问题。
领导不力
17％的问题是领导不力，包括不做指导、对项目上的需求不闻不问、玩弄权术、不承担责任以及不以身作则。
敬业精神差
17％的问题表现为工作动力，不参与项目活动、缺乏合作甚至矛盾深重。敬业精神差可以视作领导不力的另一方面。表B对这三类问题进行了归纳。
小结和结论
1） 职能型结构和职能矩阵型结构成功度较低，项目矩阵型结构和项目组型结构成功度较高，平衡矩阵型结构的成功度介于二者之间。
2） 项目经理的作用越大，项目越是实现预期的进度、成本和业绩目标
3） 开发性项目采用项目矩阵型结构和项目组型结构效果较差。
4） 除职能型结构外，项目界定是所有结构的最大难题。对项目矩阵型结构来说，项目实施是最小的问题。
表A ： 项目结构

结构 说明
职能型（154个项目） 项目分成若干部分，分配到有关职能部门和或者职能部门内的单位，由职能部门和上级管理部门协作完成。
职能矩阵型（298个项目） 确立一个限定职权的项目经理与不同的职能部门或小组协作完成项目。职能部门经理对自己负责的项目的某个部分拥有职权并负有责任。
平衡矩阵型（232个项目） 确立一个项目经理监督项目的实施。与职能部门经理共拥职权、共担责任、共同完成项目。项目经理和职能部门经理共同批准决策。
项目矩阵型（553个项目） 确立一个项目经理监督项目的实施，对项目的完成拥有主要职权并承担主要责任。职能部门经理根据需要指派人员并提供技术指导。
项目组型结构（247个项目）确立一个项目经理主管一个从各职能部门抽调的骨干人员组织的项目组，这些人员专职服务于项目。职能部门经理不正式参与其中。

表B: 项目问题分类

项目界定 （43％） 组织设计（23％） 项目实施（34％）
界定不明确 （35％） 人员配置不当（53％） 缺乏协调 （27％）
进度安排不当（28％） 缺乏责任感或职责不明（27％） 控制不良 （21％）
决策不力 （20％） 项目经理不得力（20％） 缺乏沟通 （19％）
信息不良 （9％） 领导不力（19％）
变化 （8% ） 敬业精神差（17％）

第三讲：工作细分结构

要制定项目计划和预算，就必须充分了解项目中待执行的各项任务。确定项目任务的传统过程往往依直觉而定并没有什么更可怕的方法。在20世纪80年代，美国能源部公布了《成本、计划控制系统标准》（CSCSC）,以协调第三方分包商的成本管理。成本管理的关键在于工作细分结构。
工作细分结构这一概念目前已经被几乎所有的项目类型所采用，并且得到了商业项目计划和成本控制系统的全力支持。
CSCSC要求采用一种连贯的方法来进行估算、预算、进度安排、成本控制、报告等，这意味着上述各步骤是相互联系、相互交叉的，而这种联系和交叉关系正是通过工作细分结构建立的。
工作细分结构（WBS）
项目的工作细分结构是一个将项目工作范围进行分解的逻辑过程。其目的是了解项目的执行方式（项目战略），作为项目规划、估算和进度安排的模板。WBS的关键组成要素是工作包。每一个工作包都是一个成本中心，都有以人工时、材料及其它完成工作包所必要的资源来表示的预算。
WBS－层次
以下将给出一些术语的定义。其中最重要的有关层次的概念，因为它影响到预算、时间进度汇报以及绩效评估。

第一层次
项目工程
（最终产品或项目）

第二层次
主要工作要素

工作界定增多时，会有更多的次要工作要素。


工作包

第N层次

产品导向
WBS 的准备工作首先需要一份有关项目目标的说明书。这份说明书表达的并非是
项目财务利得，而是项目必须产生的最终产品。
这一方法贯穿了WBS的各个层面，因而每一个工作包都是以产品为导向的。
WBS是项目的自然分解，不应该受到任何固定组织结构的限制。如果受到了限制，
则工作细分就不可能是以产品为导向了。按某种组织结构在高层次上对工作进行划分
会使WBS不起任何作用，第一层次以下的工作计划仅仅反映出一个工作块的需求，
而无法反映出各个工作块之间的相互的依赖性和义务。总言之，这样一种方法与WBS
预期达到的目标大相径庭。
什么是工作包
工作包用以确认产品，阐述为达到目标所需作出的努力，确认所需运用的资源，确
定预算及计划的制约因素和技术要术，并且确认负责项目工作的组织要素。
项目进度、预算、成本汇集系统、报告系统及绩效评估都是从WBS 发展而来，它们从工作包开始并沿着WBS纵向移动。
需要说明的一个简单问题是：工作包有多大？通常的答案：不大也不小。
如果项目要由工作包来控制，那么，每一个工作包应尽量地小，以具有一定的可见性和便于控制。也因此项目经理可以只关注已经完成的行动。
成本汇集及控制
工作包确认－系统合在一起将代表最终主产品的子产品。成本由工作包汇集而成，包括材料成本和人工成本。工作包领导对发展该产品所作的所有努力负责。
工作包完成后，成本就可以和预算相比较。项目发展的趋势可以进行评估，并且有一连串的工作包正接近完成。一旦这些工作包完成后，即可进行绩效评估。
由于成本汇集是按工作包而不是按职能逐个进行时，WBS将使成本报告和分配系统的武断色彩减少。
随着项目的进展，在任何时刻工作包的数量都会增加。几个月以后的工作包并没有详细的计划。将这种方法应用于会计制度准则，则可能建立随着项目发展而移动的窗口。一旦窗口移动过，工作包完成，账户就关闭。当窗口接近新的工作包时，该工作包的成本账户就打开了。
由于这种工作系使项目经理对人工时分配和协调具有更严格的控制力，因而更具有吸引力。工时的计入仅依据那些由于工作包中的时间。而在职能体系下，记账的依据是项目职能，这会计入更多的人力及工作时间，而且由于无法清楚地确定因而不可能防止假造的计帐。
报告
WBS支持每一层次的项目报告：高级管理层第一层次报告：项目整体进展状况如何？而在客户及承包商组织内部的低管理层次上，则需要低层次的报告。
工作包的定义
工作包的定义是一个综合描述过程，具体内容包括：
标题
1. 工作说明书（SOW）
2. 计划逻辑流程
3. 任务的顺序
4. 现有的投入
5. 所需的产出
6. 项目里程碑
7. 工作包与整体项目的关系
8. 人力资源需求
每一份工作表现的细节取决于其在WBS中的层次。确定高层次或低层次要素也可使用相同的方法。在工作包层面，项目里程碑细节之间的关联程度比其在第2层次中要低，而以上2、3、5项则向工作包领导提供了他所需的基本信息。计划逻辑流程中所需的细节则取决于工作包的范围及工作包领导的经验。
定义
以下定义是从各种不同的参考书中摘录的。
1. 工作细分结构（WBS）
WBS是最终产品（或交付物）的族谱层级图，表明为完成项目目标所需生产的产品。WBS是最终目标及为达到这一目标所需的努力之间的桥梁，它描述了工作产品完成的方式，为计划和控制这项工作提供概念性的框架。
2 . 项目总结WBS(PSWBS)
PSWBS是通过独特项目需求的运行而对WBS进行的总结。它常由三个层面的工作界定组成，是随后承包商支持的基础。PSWBS可能需求进行修改，以反映在合同履行过程中低层次工作的逻辑发展。所有层次中的变化必须服从于正式的变化控制程序。
3. 合同工作细分结构（CWBS）
一项完整的CWBS，是由承包商根据工作说明书制定和加以运用的。CWBS的组成成分与基础是合同中所含的经过选择的PWBS要素，以及承包商为了涵盖较低层次的WBS所作的扩展内容。
4. WBS层次
各种WBS要素的层级位置由层次指定所定的。WBS族谱图将子产品置于产品层面之下。在同一层面的子工作块要素处在WBS同一层次上。随着层次的降低，
就会提供更加详细的最终产品的定义。层次的数量取决于每一个项目的范围和复杂程度，以及它所需要的控制程度。项目的三个最高层次可典型地细分为如下三种：
 第1层次仅仅包括项目的定量目标或最终应完成的项目。
 第2层次包括主要的产品细分或最终项目的组成部分。主要产品细分通常用位置或所服务的目标进行界定。
 第3层次包括第2层次主要细分中可界定的组成部分或子集。
5. WBS要素
WBS中规定的各项产品都称作WBS要素。每一个要素都是WBS的一个独立的部分，由一项硬件。或服务或数据组成。
6. 产品构成管理
产品构成管理是在产品整个生命期中管理、控制、报告有关项目的计划或实际设计的一项任务。因为有了产品构成管理，WBS将将进行扩展，从而确定用于上述目的的要素。
7. 产品构成项目（CI）
产品构成项目被定义为：为满足最终使用功能，并为配置管理而指定的硬件/软件或其任何独立部分组成的总和。构成项目在复杂程度、规模和种类等方面存在着很大的差异。
8. 工作包
为完成某一种特定工作所需的部分努力，如科研、技术研究或报告、试验或测试、设计、规格、一个硬件、软件构成要素、一道工序、施工图、现场勘测、建设阶段要素、采购阶段要素或者一项服务，这些都是执行工作的组织中某一单独单位的责任。工作包通常是WBS最低层次中的要素。
9. WBS词典
WBS词典列出并界定了WBS的要素。WBS词典应该进行修改以反映各种变化，并应在整个项目期间不断更新。
第五讲：网络分析
导论
 一旦项目的工作细分结构已经建立，完成工作所需的成本、时间和资源已经估算，下一步工作就是确定整个项目所需的时间。如果是一个仅由几项工作构成的简单项目，全的技术来协助描述各项活动之间的关系，并且计算出整个项目的时间跨度――进入50、60年代为支持大型高科技项目的项目管理而开发的网络分析。
该技术采用图表式的网络描述所要完成的工作活动之间的相互关系――完成各项活动的逻辑顺序。它使项目经理能够专注于那些对于他们在所限时间内必须完成的项目具有重要意义的活动。
构建网络
对某一项目进行关键路径分析通常要采用以下步骤：
 将项目分解成几项单独的工作或活动。
 建立各项活动之间的相互关系，即对于每一项活动我们必须提出：
（a） 在此之前必须有哪些活动？
（b） 在此之后必须有哪些活动？
（c） 哪些活动可以同时进行？
 估算每一项活动的持续时间。
 根据活动必须完成顺序将它们安排成一个逻辑网络。
 分析网络并确定那些对于在所限定时间内完成项目具有决定意义的活动。
 以适当的形式将分析结果分发给参与项目的管理成员。
 定期检查网络，根据新的信息修改网络，并且在需要时采用修改措施。
网络中使用的符号
所描述的方法称为“优先法”，其中的每项活动或工作由下列符号表示：

最晚开始 浮动时间 最晚结束

识别
最早开始 持续时间 最早结束

联接活动
工作执行的逻辑顺序是通过如下符号联接来表示：

  
A

  
  
B

  
  
C
  

只有当A 、B均结束时C才能开始。
持续时间
指工作活动所耗费的时间。
一个简单的网络
想一想下列项目：
工作A是起始活动；
工作B、C和D在A结束时立即开始。
工作E可以在B结束时立即开始。
工作F可以在C结束时立即开始。
工作G可以在E、F和D结束时立即开始。
这个项目的网络可以表示如下：

B
  
E

   
   
   
  

A  
C  
F  
G
                    

  

D

在这一阶段有一、两点须强调：
 除了第一个活动以外，其余每一个活动都至少要有一个进入的箭头；
 除了最后一个活动，其余每个活动都至少有一个流出的箭头；
 只能有一个起始动作；
 只能有一个结束活动；
 不能有松散的结尾；
 工作流程必须遵循一定的方向，不能循环。
活动编号
在分析项目，尤其在使用计算机时，为方便起见，通常将活动进行编号或注上标签，使用WBS代码最方便易行。
网络分析
在画好了网络之后，我们现在开始分析以确定：
1. 每一个完成了的活动的最早开始时间和最早结束时间；
2. 每一个活动的最晚开始时间和最晚结束时间；
3. 关键性的活动：从网络开始至网络结束过程中相互关联的关键性活动所构
成的顺序称为“关键路径”，任何一项活动延期将导致整个项目的延期；
4. 每一个非关键性活动可有浮动或自由时间。
最早开始和结束时间的计算
从网络系统往前看，将开始活动的最早开始时间定为零。沿着网络的路径各项工作按时间往前进，将最早开始的时间加上各项活动的持续时间，这就决定了最早结束时间。前一个活动的最早结束时间构成后一个活动的最早开始时间。
我们来看看下面这个简单的例子。我们已经插入了持续时间的估算，并已计算出最早开始时间和结束时间――“前向通道”。
   
  

B
  
E

5 5 10  10   8  8

   
   
   
  

A  
C  
F  
G
0  5  5  5 10 15  15 5 20  20 5 25

  

D

5 12 17

如果某个活动不止有一项投入，例如，最早的开始时间G是投入项中较大的一个。G必须等到所有投入项完成后才能开始。因此，G的最早开始时间是期间20――来自活动F的产出。
最晚开始和结束时间的计算
从网络的最后一个活动沿着网络往回看，将最后活动结束时间设定为其最早结束时间，从结束活动开始按网络的反向顺序前进，从该活动的最晚结束时间减去活动的持续时间就产生每项活动的最晚时间。活动的最晚开始时间构成所有在此之前每项活动的最晚时间。
7 2 12 
12 2 20

B
  
E

5 5 10  10   8  8

0 0 5 
5 0 15 
15 0 20 
20 0 25

A  
C  
F  
G
0  5  5  5 10 15  15 5 20  20 5 25

8 3 20

D

5 12 17
采用这种方式的话,有些活动会有多项产出.例如,活动A.活动A的最晚结束时间必须是活动B、C或D的最晚开始时间中较小的那个时间,此处应该是活动C.
浮动时间
浮动时间是指在非关键性活动上的富余时间。所有的关键性活动没有浮动时间。在网络分析中运用到的浮动时间有多种，其中最普遍的要算是总浮动时间。
浮动时间是指一定量的时间，这段时间中一项活动的最早开始时间的延长不会导致整个项目完成的延迟。
以下是浮动时间的计算：
浮动时间＝最晚结束时间－最早结束时间
关键路径
这条路径贯穿于网络，由那些控制整个项目持续时间的活动所构成。这条路径上的所有活动都是至关重要的，完成过程中的任何延误都将延长项目的持续时间。对关键路径上的每一项活动，其最早开始和最晚开始时间或者最早结束时间和最晚结束时间都将相同。