项目计划、进度与控制
【美】詹姆斯·刘易斯
译者序
大师将心理学、性格学的大量研究成果引入项目管理的软技巧，从人性的高度，不吝笔墨地深入分析了影响项目进度、成本乃至项目成功的人的因素。
前言
多年以来，我一直告诉人们，管理，包括项目管理，是一门行为艺术。大部分商学院教人们思考，即教授知识性技能，这有助于进行商业分析、决策和执行特定类型的计划。但是，你和项目团队成员、项目不同干系人的日常交往，要求你必须知道如何影响别人，这类技能是无法通过知识性培训获得的
参加管理培训班之前，先参加一个表演培训班。
太多的项目经理不明白，项目管理几乎都是在处理与人的关系。项目经理往往没有权力却承担太多责任。缺少与人打交道的能力，工具只能帮项目经理精确地记录下他们的失败。
什么是项目
PMI把项目定义为“为创造独特的产品、服务或成果而进行的临时性工作”。“临时性”是指任何项目都有明确的起点和终点；“独特”是指项目要创造的这个产品、服务或成果与此前其他的产品服务或成果不同。他们可能不需要使用关键路径法及挣值分析法，但必须掌握一定的项目计划与控制的技巧。项目是用来解决两类问题的——积极的和消极的问题。
什么是项目管理
项目管理中需要处理大量的政治问题，使团队成员的表现达到同一规定水平，为稀缺资源谈判。
项目管理不仅仅是排进度表。它也不仅仅是一些工具。它也不仅仅是一个工作岗位或一个职位头衔。它也不是上述这些的总和。组织是人的集合，过程是人在处理。如果人的因素出现问题，那么过程就可能出现问题；而过程有问题，任务的完成就会大打折扣。不幸的是，我们懂得更多的是怎样提高设备的效率而不是管理人。
一直以来，大家都在普遍谈论项目管理的三重约束——质量、时间和成本，换个说法，就是好、快、省。通常的说法是：好、快、省中只能选两个。就是说，三者之中你只能决定两个，第三个是个变量。
项目的目的是为了创造某种成果。建筑项目为人们建造居住的房屋、行走的路、供水的水利设施；产品开发项目是为了给人们提供产品；软件项目也是一样。
这里有两类质量要求，合在一起被称为规范。一类是功能的要求，用来描述可交付成果的用途；另一类是技术要求，用来说明可交付成果的特征
定义一个项目，重要的是要明确项目的各项要求。我认为，要求不明确是导致项目失败的最常见原因。
P——技术与功能方面的质量要求；
C——工作中的劳动力成本（注意：主要设备与材料成本要与劳动力成本分开计算）；T——项目规定的时间；
S——工作的范围与规模。
这些变量间的关系可以用下式表达：
C=f（P，T，S）换句话说就是：“成本是质量、时间和范围的函数。”在理想情况下，可以把它写成一个精确的数学表达式，例如：
C=2P+3T+4S
可是，在项目管理中，项目发起人或其他管理者通常想同时决定四个因素。实际上，这就是导致项目失败的普遍原因。
我们需要知道，当越过成本最低点后（时间延长），项目成本会因为缺乏效率而提高，这是说，你干得太慢了。
这时我们可以看到，缩减时间时，项目成本开始上升，并且是急剧上升，这是因为我们要动用更多的资源来加快速度。用句大家常说的话：我们实行的是“人海战术”。
甚至，有一个起源于软件项目管理的法则，叫做布鲁克斯法则：“为一个已经延期的项目增加人手，只会让该项目延误更多。”
还有一种说法，“异想天开的人总是做着一直在做的事，却期望得到不同的结果。”这是说，如果你一直努力却没有什么成效的话，你就必须改变你做事的方式，亦即你必须改变做事的“过程”。事实上，这种改变正是规范的项目管理能给予你的。
如果你想要人们更快、更省地完成工作，并且不允许缩小项目范围，那么我敢肯定，他们会牺牲工作质量。
过去，人们常用两种方法来定义质量：一种是，质量就是符合技术规范；另一种是，质量就是要满足消费者的需求。当然，技术规范本身就应当以符合消费者的需求为准，所以，第二个定义可以说更好些。
质量成本来源于三个方面：预防、检查与失败成本。预防是指我们为了防止错误发生所做的一切努力。
检查成本是对已完成部分的监测，以确认没有质量缺陷。质量中一条基本的法则是，你无法检测产品内在的缺陷（在产品的设计和制造过程中就已经存在的缺陷）。
失败成本是发生在产品离开工厂到达消费者手中以后的质量成本，包括保修成本、修理成本，等等，其中最不容易量化的失败成本是客户流失成本。
对于项目来说，如果你能改进流程提高质量，那么，你就能同时降低项目的时间和成本，因为你减少了返工（这对项目不产生任何增值）。质量的改进会给你带来很大的收益。
项目经理不是独自为团体制订计划，而是让那些实际实施业务的人参与制订计划。
项目开始时能使人激发起极大的兴趣，但很快情况就会变糟，就像你看到的，所有的人都在争吵，激烈的争吵过后，他才坐下来定义这个项目的需求，而这本是一开始就应当做的事。
有的模式仅包括四个阶段，即定义、启动、执行和结束。但是不要忘记，任何项目都是从某种构想开始的，并且，构想在最初常常是含糊不清的，所以，我们的工作就是去明确这个构想，并把它变成整个团队的共识。许多项目失败就是因为这一点没做好。
怎样定义成功
答案是，你首先要在定义过程中弄清楚项目干系人的期望是什么，项目结果是什么，然后确定什么样的交付物，怎样才能得到那些结果并达到那些期望。
项目管理系统
人的因素位于最底层，因为处理人的关系是整个架构的基石。
如果你讨厌人事纠葛，你就很可能处理不好人的问题，而且这些问题会让你发疯。以我的价值观来看，人生苦短，完全没有必要做你自己讨厌的事情，还是去当一名技术人员吧。
有些人会说：“我的确不擅长人际关系，但是我愿意学习。”如果是这种情况，我建议他们为自己设定一个学习目标。这个模型中标出的任何技巧都是可以学到的，即使是领导才能也一样。虽然不是每个人都擅长这些东西，但每个人都可以提高或者改进，这是毫无疑问的。
项目本身变得越来越全球化，与过去相比，项目组中常常包含更多不同文化。项目经理必须学习了解不同的文化，以及如何处理文化差异。
问题在于，人们通常并不把他们的文化告诉你，当你意识到差异的存在时，你已经伤害到他们的文化了。遗憾的是，我们的社会也没有很多这方面的教育或培训，你只能认真关注别人的文化，如果觉得有什么不对劲时，一定要开诚布公地讨论，这样才能解决问题。
项目经理常常抱怨说，他们有太多的责任，却少有权力，我总是对他们说，这种情况不会有太大的改观，所以，你只能去适应。
一种是可以吩咐人们去做事的权力（叫做法定职权），即对人的权力，这是项目经理们通常所没有的，他们只能通过发挥自己个人的影响力来解决问题。即使对那些拥有用人权的经理而言，发挥个人影响力也是很重要的。
第二种权力是独立做决定的权力，即无需事先得到批准就可以做决定的权力。这主要体现在支出管理上。长期以来始终让我耿耿于怀的是，虽然项目经理们管理的项目预算达百万美元，但他们的任何超过25美元的支出都必须经过批准，这简直太可笑了！
控制就是对比你所在的地方和你应该在的地方，当偏离目标时采取措施纠正。
成功的组织往往面临着巨大的危险，因为成功会让人们变得故步自封。
项目管理与六西格玛
人们关注的另一个模型是六西格玛模型，它主要解决流程或者产品中可接受的错误量。其指导思想是，将错误量控制在一定的限度内。
这样便可以看出项目管理与六西格玛的区别：项目管理为组织提供手段，帮助其达到六西格玛的质量水准。
项目管理刘易斯方法
对那些特别小的项目而言，做一个关键路径进度表几乎是在浪费时间，但有的项目缺了这样的表就是不可想象的。
我十分赞同项目管理中的KISS原则（Keep It Simple Stupid），即不多做任何不必要的事，但也不少做任何必要的事。我喜欢把它称为懒惰原则，也许我本性懒惰吧。我不想过多地花费时间与精力，够用就行了。
第2章 美国项目管理协会与《PMBOK指南》
在过去几年里，PMI会员人数几乎成指数级增长，因为越来越多的人意识到了用结构化方法管理项目的价值。
过程和知识领域
项目过程是指为确保项目创造出来的产品符合最初设计目标所进行的行为，例如计划和控制等。
·产品过程是指为创造某种产品所进行的活动。这些活动可能包括工程设计、房屋建筑或其他这样的活动。
知识领域
在任何事件中，质量制约因素通常被遗忘，当你投入人力并要求在规定时间内完成项目时，质量有时会变差。
信息对于一个项目的顺利推进而言是必不可少的，然而，这个过程常常在项目的计划阶段被忽视。
你必须管理风险，否则风险将管理你。
第3章 项目经理的作用
应该清楚的是，如果你不能描述和定义某种事物，你就很难能做好它，所以这是必需的。
现实中，大多数管理培训侧重于分析和规划。但我之前说过，管理是一门行为艺术，它本质上更多的是右脑思维，并只能通过工作实践来学习
一切都关于人
首先必须认识到项目管理的核心是人，而不是技术。
你的主要任务就是有效地处理人际关系——不仅仅是在你们项目组中的那些人。
一名项目经理的核心工作就是处理政治。没错，就是政治。
如果你讨厌处理这类政治问题，那么答案就是否定的，人生苦短，回到你的技术岗位吧，把我的这本书作为一个警言，你经常看看它并提醒自己你不想走那条路。
我喜欢的领导力定义是，领导力是一门艺术——让他人想做你认为应该做的事。
并且，因为项目经理们通常责任大而权力小，你必须有很好的领导技能让别人做那些应该要完成的工作。再次强调，人是核心问题。
如果你想被别人视为成功人士，就必须成为一名经理人。至少，很多人这么认为，我自己也是如此。
使人们想成为经理的另一个原因来自于人们的控制欲，我们希望控制而不是被控制。
项目经理有两类：矢志于此的项目经理和暂时栖身于此的项目经理。如果你是一个矢志于此的项目经理，那么从项目的摇篮到坟墓（不是指你的坟墓，而是项目的坟墓），你都拥有这个项目，就是说，从项目开始到结束，都是你全权负责。如果不是这样，你仅仅是借此过渡，你也不会得到这个职位应有的所有荣誉与嘉奖。
如果你是一名真正的项目经理，你应当是积极主动的，而不是消极被动的。不管你是否喜欢，一名项目经理必须积极主动地采取行动开展项目。如果你不是这样，就需要改变。
有时项目经理们不能积极主动管理项目，是因为他们没有被赋予什么权力，并且他们认为，在他们采取行动之前，必须获得批准。
自然，我们不能超越权力红线，但是，我们应当自问：“我的工作中，哪些是我可以自行决断的？
我的经验是：想有多少权力，才能有多少权力。如果你总是在等待别人赋予你权力，你永远都不会拥有它，因为你还没来得及证明你能够运用它。
你真的想管理吗
许多人只想成为管理者而不是想真正做管理。
一个经理人要在问题出现之前提前采取行动；或者说，一个经理人是积极主动的；抑或，一个经理人总是设法提高组织的运作效率，他必须有前瞻性。
一个经理人心中也有一个目标，他需要制定出实现目标的计划，然后采取步骤去实现它。他也要对比实施进度与计划，并在实施情况偏离计划时采取纠正行动。
系统理论中有一条必要多样性法则：任何人类或机械的系统中，最活跃多变的因素控制着整个系统。
实现这种控制有两种途径：一是提高你的灵活性，使你成为系统中最活跃的因素；二是降低系统中其他因素的可变性，使你能跟上或超越系统本身的变化。
我的意思是，他们总是试图用规章、条例和程序等限制变化，而不顾这些管制措施常常也扼杀了这个组织为适应环境所必需的应变能力
汤姆·彼得斯说过，这些政策（通常这么说）不能确保人们做正确的事，只能被组织用来惩罚做错事的人。
这种控制也无法通过微观管理实现。所谓微观管理是要你只监督一个人的行为，这样的话，你的经理职位就没有意义了。
做计划的首要原则，就是必须由具体实施该工作的人来做计划，原因有两个。
·人们不赞同其他人的计划——这不是因为自我主义，而是因为别人的计划通常是不正确的，无论在估计、顺序还是周密性上。·作为一个集体，团队总是能考虑到一些个人（比如项目经理）没有考虑到的事情。
实际上，一个项目经理要进行控制，就必须有项目计划
你必须要明白的是，如果你花大量时间做那些技术工作，你无法顾及你的本职工作——管理。
或许，你更喜欢进行微观管理：你不相信来那些提交上来的报告；你不相信团队成员能像你做得那么好。所以，你就逐个仔细指导监督他们工作。无论如何，这时你的管理职能就被你忽略了。
另外一个陷阱是，组织常常希望项目经理们能承担一些项目组中其他成员正在做的工作，他们被称为“干活的项目经理”。这种做法的问题在于，当完成具体工作与进行管理出现冲突时，完成具体工作总是优先于管理的实施。这样，管理职能就被弱化了。我宁愿看到一个人同时负责几个小项目而没有工作责任，也不愿看到每个人都既有管理项目的责任又有具体的工作，那样什么事都做不好。
事实是在IT和软件项目中使用滚动式进度计划，也利用了传统的进度计划——它只意味着你不是一步完成整个项目规划，而是随着项目的推移建立小的规划增量逐步细化进度计划，这种方法曾经被称为分阶段计划。
决定你的职业
项目经理们要面对公司内的方方面面，他们必须具备特别的政治和外交技巧，因此，如果他们能成功地管理项目的话，他们几乎就能管理整个公司了。
高绩效项目管理模型
大多数组织处于三西格玛的质量水平，这意味着每100万个任务中，将出现66 807个错误。这些错误会造成他们每卖出1美元就有25～30美分的成本
你也许也发现这个故事中，做计划用的时间比实际执行用的时间多得多，虽然通常不是这样的，但这也说明了一个计划的重要性——如果你想让工作尽快完成。
对一个新方法的需求
我曾经读到过一份研究，它报道说不超过33%的所学内容可能会被应用到工作中（我已经不记得这个信息的出处了）。主要的原因在于：一是他们所学到的不被人们支持；二是没有人要求他们说明学了什么。
用这样的态度对待计划是普遍现象，管理者们都是任务导向，他们想看到员工在做事，不是画工作分解结构或者关键路径图。
因为项目是靠人做出来的，而不是技术。而且，你只能通过实践、反馈、更多实践才能学到这些技能。
彼得·圣吉指出，系统产生行为，与系统中的人无关，而且，除非你改变系统，否则你将继续得到同样的行为（Senge，1990）。
然后他告诉这些人，如果你给工人们一个固有地产生一定缺陷率的系统——无论他们如何工作——都不能创造出超过生产系统能力的更好的结果。
提高项目管理绩效必须避免的一个错误，就是独立地优化三个因素（工具、人和系统）。
发展的阶段
组织里项目出现问题的一个主要原因，是他们试图用有限的资源同时做太多的项目，其结果就是人们不停地从一个项目跳到另外一个项目以勉强维持。这样一来，他们每次换班时必须重新适应，这种再适应在制造业中被叫做调试时间，它对工作过程本身毫无益处。
在同一个时间你只安排一件事情，你就全力以赴去做这件事，这将提高你的生产率；你的生产率高，你的成本将显著地下降。多任务并行造成一种很多事可以被完成的错觉，是的，但是这时的生产率很低。
这对组织有着意义深远的启示，包括项目在内，唯一真正的激励是内在的。
他们最重要的事情是尽量将团队成员安排到他们喜欢并觉得有挑战的工作上去，并且，他们应该积极地创造一个互相尊重和合作的风气。
第5章 全脑式项目管理
你不能用造成问题的思路去解决这个问题。
——阿尔伯特·爱因斯坦
无疑大部分人都听说过左脑或右脑为主的思考方式。左脑思考者更加注重分析、充满逻辑、具有顺序感，而右脑思考者更加平行化、直觉化和全面化。
设计工作与制造业要求不同的思考方式。设计工程师必须会综合考虑，而制造业工程师必须会专业化思考。综合思考是右脑模式，而专业化思考是左脑模式。是我聘用了错误的人。
思考模式
这个工具测量的是人的思考偏好，而非技巧或能力。
如果你拥有一个很强的思维偏好，你将经常倾向于去做事情，因此你也将非常善于做该事情。久而久之，偏好很有可能导致了技巧的形成。
最后，只有占3%人口的思考偏好在全部四个象限里。当然，这种剖面图叫做四重支配。这些人被称为多显性翻译者，内德认为他们将会成为优秀的CEO，因为他们可以与每个象限的人们高效地互动。这个结论很难被论证，因为这样的人很少，只有其中一定比例的人是CEO，所以我们或许永远不知道他们是否是很好的候选人。
由于只有5%的人是单支配的，所以这样的项目经理也是非常少见的。
如果你需要一个对细节比较关注的人，你最好找一个具有很强B模式偏好的人。不过，如果他们只偏好这一种模式，他们就很有可能会只见树木而不见森林。
一个主要偏好C象限模式的项目经理，本能上可能过分关注项目的人事工作，这对工作的完成有时候是有害的。
如果能使你在那些你喜欢的思维方式下获得成功的话，你将愿意去做一些具体的事情。
项目管理需要创造性思维。所以，如果你是一个有很强的A或B模式偏好的左脑思维者，不喜欢用D模式思维，你可能觉得自己有点不走运。不用担心，事实证明，左脑思维的人学习概念或者创造性思维要比概念思维的人学习分析性思维容易得多。
工作激励与HBDI剖面图
我最不喜欢的是B象限，因为那需要考虑太多的细节问题。我会觉得一个要求这样思维的项目太麻烦。在我当工程师的时候，我讨厌分析图纸或者检查原料单是否正确。这些都是重要的工作，但我就是讨厌它们。
因此，一个人的思维模式非常好地解释了他行为的动机。如果你了解工作的特性，你将了解这个工作是否可以激发这个人。
这两个图表明，项目经理来自于“各种各样的”人，因为只有一个相对平均的分布才能形成一个正方形。所以，项目经理的思维模式分布与普通人并无太大区别。
一个人的思维偏好会影响他进行项目管理时的风格。
如果你讨厌人事纠葛，又何必要做一名项目经理，陷自己于日复一日的痛苦中呢？
大部分是C-D模式，右脑思维的。因为项目经理必须利用影响力使事情得以解决，所以他们需要非常强大的C象限思考模式。而且，项目经理有主要责任去帮助团队理解项目的成果，这就需要非常强大的D模式。
我相信，在A和B象限很强的项目经理或许更会在技术和细节上陷入泥沼，很有可能会做过多的计划，这并不很好。
如果他们意识到处理不好C象限的事就会影响到那些他们真正关心的事情的解决的话（比如技术问题），他们就会花更多的时间来处理那些C象限的事情。
团队动力
“坏消息是，我们每个人的意见都不统一。”贝斯继续说，“好消息是，我们每个人都能从不同的角度看到问题。”
有一种情况是，如果你批评我的设想，你就是在挑我的错，所以我就很生气，接下来就是陷入一场人际纠纷。造成这种情况，有时候是由于性格冲突，但主要原因是我们看问题的角度不同，观点与思想也不同。
问题是，如果人们能够理解彼此思维偏好的差异，情况就会简单得多了。
原因
你一定记住，同样的事情正好发生在那个项目中，因为没有人说什么，所以项目经理就以为大家都同意并理解了要完成的任务。
事实上他们没有理解，只不过谁都不愿意提出来。
或许是因为他们不想在众人面前丢丑，他们看到同事们都面带笑容地听着，便以为别人都领会了经理的意思，小组里的每个人都在想：“也许只有我没听明白。”
但是，大多数经理人不明白是过程决定了项目的成败！
很多时候，任务仅仅是交给了团队，而没有人关注任务有效性的问题——直到项目未能解决要解决的问题时这个问题才会被发现。
这意味着他们与项目本身的方向是一致的。然而，你总会发现，有些人的想法与众不同，这种差别必须得到解决，否则项目很难成功。
作为一名项目经理，你最重要的工作就是让你的团队对项目的任务、前景和问题理解一致，否则你的项目一定会成为一个“无头小鸡”项目。
任务与愿景
你必须有一个正式的描述告诉每一个人他们的方向，如果你不喜欢“任务”这个词，我们可以称它为“意图、目的、目标”。我将继续使用“任务”，因为它是一个正确的术语，项目任务就是为了实现项目愿景。
所谓愿景就是对团队努力获得的最终成果的描绘。只有当你知道最终结果是什么样子时，你才能知道什么时候你才算完成了工作。否则，你不可能知道工作是否已经完成。
问题、问题的类型
每个项目都是为组织解决问题，但是我们经常误认为我们已经解决了问题，但实际上并没有。
很多试图解决问题的努力都是这样，我们定义问题的方式总是决定着我们解决问题的方式，如果定义下错了，就不可能解决。
项目团队的任务就是解决这个问题，实现愿景。
还有另外的解决办法，那就是，如果你一定要到长廊那头的一个房间里去，你可以不走这个长廊，而是绕道从其他路线进去，这样就能躲开鳄鱼的威胁。这就是创新思维的本质——找到另一条更容易实现的解决路线。
只有一种解决方法称为封闭的问题；有多种解决方法的称为开放的问题。
封闭的问题最好用左脑分析方法解决；而开放式问题最好用右脑综合方法。
封闭式项目指向过去，而开放式项目面向未来。
定义封闭的问题
对封闭的问题来说，最好的定义方法就是用所谓的科学思维的方法，包括以下六个步骤。
·提出问题。·制定调查计划。
·提出假设。·收集数据验证假设。
·从假设验证中得到结论。·验证结论。
问题模板应包含以下五方面内容。
·问题的说明应该能反映共同的价值判断和明确的目标。
·问题的表述不应提及原因和解决办法。
·问题的表述应当在可控制的范围内定义问题与过程。
·如果可能，问题的表述应当描述出问题的可测量的特征。
·问题的说明应尽可能精练。
所谓问题是指理想状态与现实状态之间的差距，并且有障碍存在，使这种差距很难弥合。
有的项目本身存在很大的可变性，这时就需要给关键指标严格地设置标准，一旦出现偏差，我们就能判断这个偏差是否严重，无论他是正偏差（表现得比标准状态更好）还是负偏差（表现得比标准状态差）。
利用头脑风暴收集一组想法，所有原因都被列在分支上。再次必须强调的是，不要事先排除任何可能的原因。
一旦确定假设，就必须验证假设。要验证假设，首先就要提出疑问，这个假设是否可以同时解释该问题的正反两方面，或者说，这个原因必须能同时解释是与不是两种结果。如果不能，它可能不是真正的原因。
·临时行动：在问题的原因未找到之前，可以用临时行动来争取时间，但这是治标不治本的方法
·适应行动：你去决定接受或适应这些问题。
·纠正行动：这是能真正解决问题的唯一途径。它直接指向造成问题的真正根源，而不是仅仅减轻症状。
定义开放的问题
通常开放的问题要比封闭的问题多得多，在项目上尤其如此。项目要解决的问题与前面所讲的封闭的问题有不同的解决方法，甚至连通常用于定义问题的方法都是不同的
目标指向首先是一种态度，同时也是一种激发这种态度的技术。
具有目标指向性格的人，总是能明确地意识到所追求的最终状态（“我想要什么”）及其障碍（“是什么阻止我得到想要的东西”）。
如果项目仅仅满足PCTS就可以那就好了，但事实并非如此，我们还必须照顾到干系人的期望。
你要明白，如果在项目中途干系人发生改变，你就必须重新来弄清楚他的期望，不要以为只符合前面干系人的期望，一切就没有问题了。新的干系人会以不同的眼光来看待这项工作，你必须同他讨论哪些是可以调整的，哪些不能调整。新的干系人对交付物和结果可能有不切实际的期望，这时，你必须努力让他的期望与现实统一起来。
你应该把这当成项目管理工作的基本原则，因其重要性，忽略它只会让你暴露于风险之下。
对项目管理的错误理解
因为目标本身总是在变动的（这也是为什么敏捷项目管理方法被IT和软件开发项目经理采用的原因）。
当然也要注意，如果你总是因为新想法而改变产品，你就永远无法推出产品。这是完美主义者最容易遇到的陷阱，他们永远也完不成设计，因为他们总想做得更好。
许多技术人员对市场不了解，他们总是热衷于技术改进，尽管这样的产品有时根本卖不出去。
战略是什么
战略是完成一个项目的总的方法，有时又称为总方针。战略与战术的区别在于，战术用来对付一个项目的细节和后勤问题。
这些技校毕业生的水平有限，但是已经足够满足他的需要，而且大大减少了不断更换工程师的成本。
15年以前美国就缺少程序员。后来许多公司发现，这些程序可以以远远低于使用美国本土程序员的成本在印度完成。这些印度程序员能说很好的英语，教育良好，并且要的薪水很低。而在印度的生活费用远远低于美国，这样它们就可以及时而低成本地完成程序设计了。事实上，这样的战略在美国已经使用多年了。
不管可行×××的结果如何——行，可以；不，行不通——都看成是一项成功的项目，因为你已经找出了问题的答案。
形成与选择正确的战略
最常用的是头脑风暴法，用这种方法，团队中的每一名成员都尽可能多地提出自己的想法，不需要评估，然后从中选择一个。
当你为项目选择战略时，你应该用赫尔曼模型中D象限的思维方式，而当你选择项目战略与技术策略的最优级组合时，所用的则应是A象限的思维方式，因为这需要对各种选择涉及的因素和细节进行严格周密的分析。
风险与威胁的差别在于，风险是可能发生的事件，如一次事故、自然灾害或者项目延期；威胁则来自别的组织可能做的事，例如一个竞争者在市场上将你打败。
但在现实生活中，把威胁与风险放在一起考虑也没有什么不妥，因为无论你如何看它们，它们的发生都会危害你的项目。
·减轻——努力做某些事情来减少事件造成的危害。
·避免——努力防止这样的事件发生。·转移——把风险转移给他人。保险就是个风险转移的例子。把工作转包给其他人做也可以是一种风险转移。
·接受——接受风险并且不采取任何特殊的行动去处理它，我们开车的时候就是采取这种策略（系安全带是一种试图减少车祸伤害的办法）。
组织与项目从本质上讲都是政治性的，政治的基本特征是，每个人都想更多地获取和拥有权力。
力场分析就是要求你考虑所处环境中所有可能导致项目成功或失败的力量因素，因为总会有人赞成、有人反对。这就是要求你关注项目中的政治因素，可惜这一点常常被项目经理们所忽视。
有四种方法可以用来对付反对力量：
·忽略它。
·克服它。
·绕过去。
·中和它。
有时需要忽略反对的力量，因为有时你越是注意它，它就越是加强。当反对意见较小，或者反对的人所处的位置对你根本构不成威胁时，尤其是这样。
这是最常用的一种对付反对意见的方法，就是你努力说服对方接受你的意见。
这种冲突的本质就是一种作用和反作用的交换，或者可以称之为无休止游戏。就是说这种游戏几乎没办法结束，因为系统本身无法改变其运行方式。
所谓绕过去，就是你找到反对者的老板，让他的老板与他进行一次“心贴心”的谈话。这种办法也许会奏效，但日后会让你后悔。所以，多数情况下，这不是一个很好的办法。只有当涉及严重的安全问题，其他方法都不奏效时，你才应该把它作为最后的救急措施使用。
人们对变革的第一反应总是反对。
想要克服对变革的抵制是非常困难的，通常只有在新的模式发展到一定阶段，其正确性不断得到证明时，人们才开始接受它，改变立场（
许多组织不得不面临的现实是，他们被迫因为某些人反对新模式而改变正确的方向。这是不幸的，但在反对者的力量很强大时，这又是不可避免的。
所有这些问题的关键在于，项目常常因为这些“人”的问题陷入困境，而不是因为技术或人们不会制订计划。
第8章 制定实施计划
总之，你现在要计划出完成一件工作的全部细节
计划中的错误
所谓片面计划的错误，是指项目经理自己为团队制订计划，然后交给下属执行。这之所以是个错误，是因为没有人能够想到项目的方方面面，即使是一个单人项目也能从别人的参与思考中受益。
进一步讲，当你单独为项目制订计划时，你必须自己估计任务完成的时间，而这种估计很可能是错误的。具体地说，你的估计很可能只是理想状态下的，因为你忽略的太多的细节。
项目计划的首要原则就是让具体执行的人帮助你制定这部分计划。
人们不愿进行项目计划的一个原因是，他们认为与其花时间去做计划，工作可能早就完成了。常听到的一句话是：“我来不及做计划了，必须马上把工作做完。”
然而，这种观点从直觉上看也是错误的。如果你急于要完成某件事，胡乱做一气又有什么用呢？如果你面临严格的时间底线时，你就更需要一个好的计划。
项目失败的一个主要原因是把模糊预测（ballpark estimate）当做了目标。
问题在于模糊预测是通过对两个相似项目的比较进行的，或者多一些，或者少一些，并要为未知的事情做好准备（这称为随机性）。这种估计的范围可能会非常大。
计划的规则：
·每项任务的存续期都不应超过4～6周。·设计或软件工作的存续期不应超过1～3周。
·所有的任务都必须有一个用来表示任务完成的标志。
一条基本的原则是，你计划的细节应当在你可控范围之内。对设计与软件项目来说，这意味着时间应以天来计算，比天还精确的事你根本无法控制。
显然，人们有时掉入微观计划的陷阱中，是因为所有的进度表软件都支持人们把计划制定到分钟。如果你可以做到，就自然回去想，而且就会去做。
一个“没问题”的态度总是比一个“不行”的态度更受欢迎，尤其是当人们忽视风险的存在时。有一位经理曾经对我说，他不喜欢我建议他的员工做计划时太小心，他喜欢积极进取的计划。我欣赏他的态度，但是，积极进取并不等于鲁莽。
墨菲定律说，任何可能变坏的事都会变坏。用概率的语言来说，就是事情变糟的可能性总是比变好的可能性大。当然，我们知道，墨菲其实是一个乐观主义者。
制定工作分解结构
WBS有什么用呢？首先，项目失败的一个主要原因是，直到项目要完结时才发现忘记了某些工作。工作被遗漏会对项目产生重大的影响——无论在进度上还是在成本上。WBS可以提醒我们不要忘记那些重要的事情。
有的项目太小了，安排进度表简直是在浪费时间，但是WBS却永远不能省略
每一层次的WBS都有一个名字：第一层次叫做项目集，下一层次叫做项目。这代表了工程管理与项目管理的区别，一个工程是一项非常大的包含着多个项目的工作。
项目集经理对整个工作负责，项目经理只在名义上而不在实际上向他报告
在画WBS时，我们还不需要考虑这些工作完成的先后顺序，这是制定进度表时才要做的。
任何项目都不能脱离PCTS制约——即使是像家庭野营这样的小事。项目的各项要求总是需要权衡。
如果是你自己来做，则有可能漏掉某些东西。所以，即使你计划的是一个个人项目，在这个地方让别人来帮你检查一下WBS也是很有好处的。
大多数项目解决方案的都是开放的问题，因此都有不止一种解决办法。
生产设备的结果是有形的，管理家庭事务的结果则是无形的。
我认为，WBS主要是面对过程的，虽然飞机项目的WBS在最高层次上是交付物导向，但是，随着项目过程的展开，你会发现，大量的活动其实面对的是过程。
有家公司生产出某个产品蓝本后，拿去让他们的副总看。结果，产品的某个主要设计使这位副总不太喜欢，他坚持要重新设计，而建立这个蓝本已经费了很大力气，重新设计的代价是高昂的。
在这种情况下，验收的标准就是这位副总的认可。早知如此，就应当在画设计草图时就让他过目，而不是等到现在。
下面是一些你在做WBS时应当遵循的规则。
·20个任务就足够用了，超过20个任务就是过分追求技巧。
·并非所有的任务都要分成相同的几个层次。
WBS并不意味着工作顺序。
只有在安排出进度表之后，工作顺序才能决定下来。
WBS应当在安排进度表和资源分配之前完成。只有先明确了任务，才能回过头来讨论由谁来做，做多长时间。
WBS应该由了解工作的人来做。
项目分解只是为了实现对项目的准确估计。
·WBS是一系列的任务，而不是一张购物清单。
估计时间、成本和需要的资源
人们认为不能为创新型任务设定进度表，其实他们能。
但是，你不能为纯发明性的工作制定进度表。在产品开发中，发明与开发是不同的。
所有的活动都是概率性的，而非确定性的。在既定的努力水平下，任务只能在某一时间可能被完成。如果你想保证任务在确定的时间内完成，你就必须增加努力，缩小范围，或者牺牲质量。既然这些目标你不能同时实现，精确的估计是不存在的。
帕金森（Parkinson）法则，该法则表明，工作总是会拖到规定的时间才能完成，从来不会提前完成。
为什么呢？因为如果你提前完成任务，每个人都会认为你是把进度表故意拉长了，下一次就会相应地缩减你的时间和预算。这就是组织悖论，想用一次工作结果来要求今后的所有工作！简直不可思议。
问题是，管理职能部门与管理项目不同。给部门制定预算是建立在人头基础上的，所以你能更严格地控制花销；而项目预算是建立在一组猜测之上的。
假如你提前完成了工作，并把结果交给流程中的下一个人，会发生什么呢？她会立即开始工作吗？当然不会。按照进度表的安排，她本来是在几天后才开始工作的——所以她不会立即开始工作。
戈德拉特（Goldratt）把这种现象称为学生定律（Goldratt，1997）。
戈德拉特推论说，当你把帕金森法则与学生效应结合起来时就会发现，项目可能会把延期积累下来，却绝不会把提前的时间积累下来。这就是说，他们总是要比必需的花费更多，或者时间更长，因此提高的余地很大。
正如戈德拉特指出的，任务完成时间有些偏差没关系，关键是要按时完成整个项目。
明确资源提供者的责任
在许多项目中，你自己并不拥有资源，而是由职能经理们随时提供
编写项目预算
真实的人力成本不是简单的付给个人的工资，真实的成本是使用人力的效率，这些人力效率需要按照每小时去计算；你也需要为在工作中使用的设备等付钱。使用人力的效率的成本通常比直接的工资要高很多。
各部门都试图找到方法花掉他们预算的所有钱，这样他们就不会失去它，这就产生了大量的浪费。
进度表的基础
大约在1960年，人们开始用条形图来制定项目进度表，这种图表系统是由亨利·甘特发明的，用来记录过程，所以被称之为甘特图。
当项目的结束时间被设置在关键路径终点时，就没有了时间富余量。其他用时较短的路径则存在富余时间，这种富余被称之为松弛量或浮动时间。
人们常犯的一个错误就是：把每一个任务必须开始的时间与必须完成的时间都输入软件，如果你输入的时间与基于任务相互关系的时间不符，软件会选择接受你的时间，而忽略任务间基本的时间关系，这样产生出来的进度表就是没有意义的。
如果你不把任务间的先后依赖信息输入软件，它就计算不出关键路径，以及非关键路径有多少富余时间或浮动时间。
要想实现最短的时间，就要尽可能地同时开展所有的任务。
更好的办法是，先在纸上或白板上大致规划出各项工作之间的逻辑关系。
资源配置
导致时间分配不足有两个主要原因。一是人们同时做着太多的项目；二是给做项目的人安排了太多工作。当人们同时身兼多个项目时，就要不断地在项目之间转来转去。这种复合任务的问题就在于，每次转换时人们都需要时间调整适应。用平常的话说，就是人们需要时间来确认自己上次做到什么地方，现在做到哪里等。这些额外的时间在制造业中被称为“启动时间”。我们早就认识到启动时间完全是一种浪费，因为它不会带来任何增值。所以，在制造业领域，总是要尽可能地减少启动时间，甚至通过流程的持续运转使其完全消除。
可用时间少的第二个原因是给工作配置过多的人员，理解这一点需要了解排队等候理论。或许你从来没有听说过排队等候理论，但你肯定有过这方面的经验。每次当你在交通高峰期试图进入一条高速公路时，便会体会到排队等候效应。
在制造业领域，人们早就认识到，一个工厂的平均负荷程度不能超过85%，你可以偶尔超过，但如果负荷水平长期高于85%的话，就会有很大的麻烦
总的原则是，任何人都不应当同时做2个或3个以上的项目，理想的情况是，一个人制作一个项目直到完成它，然后转入下一个项目。
这样真的可行吗？肯定的。
沟通管理过程
沟通规划的第一步就是要识别干系人并进行调查以确定他们的信息需求，
但是随着项目规模的扩大，沟通成本会相应增加。事实上，这笔费用很高，并使项目经理通知每个人目前状况的负担加重。这是因为潜在沟通渠道的数量由下式得出：
沟通渠道=N（N-1）/2
确定沟通要求需考虑一下因素：
·项目组织和干系人职责；·纪律，部门和项目特点；
·项目相关人员数量及位置；·需要信息的外部机构，如媒体。
项目需求决定沟通规划的形式，可以是正式的或非正式的，结构化程度高或低。
除非传递到项目所涉及的合适的人手中，否则信息毫无价值。此外，信息还必须以恰当的格式及时地发布出去。由于沟通系统的漏洞，经常出现信息延迟到达的情况，使相关人员无法按规定的方式办事。
只有发送者承担沟通责任而接收者可以不承担责任，发送者必须要确保预期信息被收到并理解。
作为项目经理我们必须要记住一个基本前提，就是防止误解是信息发送者而不是接收者沟通职责。
一切顺利的项目可能产生糟糕的产品。
第11章 风险管理
所谓风险，就是指任何可能发生的会对项目的时间、成本、质量或范围产生消极影响的事件。
作为项目经理，不考虑这种延期是不负责任的。于是，你要把项目时间定得比天气良好时所用的时间稍长一些，这就叫做保守的进度表，是一种正确的建筑项目风险管理。
风险管理过程
把所有可能出问题的事情都找出来是没有必要的，但是，应当注意，不要只因为一种风险发生的可能性小就不去考虑它。
风险量化
有三个因素决定风险重要性：一是风险发生的概率；二是风险如果发生对项目影响的严重程度；三是是否可以在风险发生之前监测到。
风险应对方法有五种，前三种是主动管理方法。
·风险规避。
·减轻（减小影响，就像使用气囊一样）。
·转移（比如通过上保险防止损失）。
·迁就：接受。
·忽略风险（非常危险）。
只有当未知的工作真正出现时，才能动用应急储备账户，这种情况当然包括项目范围的变更。
第12章 项目控制
制定项目计划（包括进度表）的唯一目的，就是为了实现对项目的控制。
只报告时间进度表的危险
关键路径上的延期会相应地导致项目最终完成日期的延期。
用挣值分析法跟踪项目进度
挣值系统被项目管理者作为一种测量进度的方法，而且被认为是截至目前最好的方法。
挣值分析法通过对三个方面的测量说明一个项目运行的状态。这些测量指标分别是：应该做什么，即计划价值（PV）；已经做了什么，即挣值（EV）；投入的精力或成本（AC）。
控制就是比较你所在的地方（你只能猜测）和你应该在的地方（这是另一个猜测），并且当两者之间出现差异时采取措施纠正。
即使我们得不到精确的结果，但总比什么都没有要好。
如果你只看进度表，不看成本，往往不能发觉项目已经变糟了。同样，如果你只跟踪预算偏差，你虽然也知道自己花费太多，但这还不足以反映事情的真相。你不仅花费太多，而且你的服务所得也远远少于用你的花费所应当得到的。这也进一步说明，应该同时了解成本和进度表，以便对项目进度有一个真实的判断。
检查工作进度的频率应该与总的工作时间成正比。
处理偏差
所有的估计都应当是因人而异的。其他人能做到并不能说明什么，如果你想知道项目什么时候可以结束，你就必须只对执行任务的这个人进行估计。
要回答这个问题，我们必须看看我们有哪些选择：忽略偏差？采取纠正行动回到计划轨道上来？或者改变计划接受偏差？
在分析偏差时，你需要经常用到四重约束的关系公式，公式如下：
C=f（P，T，S）如果你试图回到原计划轨道上来，你可以提高成本（增加资源）、缩减范围或者降低质量要求。
让我重申一下，这样就没有人会遗忘了。当项目出现偏差时，你只有四种处理方法可供选择：忽略偏差；采取纠正措施使项目回到原目标上来；修改计划；完全取消项目。
用图形法跟踪进度并预测趋势
没有报酬的加班真的是免费的吗？当然不是这样，你将付出生产率降低、返工增加、大量出错、员工缺勤、压力病以及员工流失等代价。
如果你在项目时间轴上的15%处遇到麻烦，你将注定无法摆脱困境。这意味着，如果一个项目计划要花100周的时间完成，你在第15个周末遇到了延误，你永远不可能赶回正常进度，永远！
用表格法跟踪进度
你一定听说过一句话，看起来太好的东西往往是不真实的，这是很有道理的。所以，首先的考虑是，数据是否真实，或者人们是不是在欺骗自己？如果是真实的，实际情况如何呢？
关键比率可以提醒你该对项目采取什么措施。
预测项目最终结果有两种方法：一种是根据当前已经完成的数据重新计划；另一种是用挣值数据计算预测结果——也许最好是两种方法同时使用。
挣值分析的替代方法
跟踪项目范围变更次数也是很有用的，但是你一定要了解范围变更对项目的影响。你可能找出了很多小的范围变更，却对项目几乎没什么影响；而往往是某一次范围变更就可以毁掉整个项目。
另一个应当考虑的方面是：是什么原因造成了范围变更。如果是无法预见的环境改变，则范围变更或许是合理的。
如果你获得信息不是为了控制，而只是为了让项目好看，那又何必浪费精力去收集数据呢？直接杜撰你想让人们看到的数据可以节省大量精力。
唯一合理的办法是每天都做记录，这不会花很长时间，如果花的时间超过5分钟，你就是过分认真了。
项目变更控制
导致项目进度落后和费用超支的主要原因之一，就是范围蔓延。干系人只要求“一点点”改变，这些改变并不十分重要，所以你接受了。但问题是，5分钱的改变可以累加成几元钱。最终结果你知道，项目范围会大大超出原来的计划。
有趣的是，当初要求进行改变的人，通常都会在项目结束时患上失忆症。
这种控制要通过正式的项目变更批准程序进行。当某人要求进行变更时，你应当先让他了解变更对项目的影响，说明它将如何影响进度、费用、性能。然后问他是否愿意接受这些影响，如果他愿意接受，这时你再进入正式的变更批准程序。
第13章 指导项目总结
项目总结分为三种，分别是状态总结、设计总结和过程总结。每一种都有不同的用途：状态总结主要是检查P、C、T和S目标是否达成，我们是否遵照了预定时间安排和预定预算安排，项目范围是否正确？质量需求是否良好？
仅当项目中有设计的工作时，才需要进行设计检查，如产品、服务或软件设计。在设计检查中可能会问这些问题：是否满足范围说明书要求？是否是用户容易掌握和使用的？我们能否制造出来？我们要生产的东西是否还有市场需求？投资是否能收回以及是否证实有其他同类产品？
过程总结的重点是我们是怎么样完成工作的。这就存在两个问题：什么是我们做得较好的？什么是我们需要改进的？这通常也被称为经验教训总结总结。
总结
我不赞成完全否定那些出现问题的人，我们对解决问题也应当充满希望，但是我无法容忍那些不愿承认问题严重性的人，而且工作拖拖拉拉，也不肯寻求帮助。
AT＆T在几年前发现较成功的工程师区别于其他人的一点就是，当他们无法成功解决一个难题的时候，他们愿意向别人请教。（我不记得这一发现的出处了）古语所说的“自古成功在尝试”应该修改为“自古成功需求助”。
过程总结
过程总结的目的是为了吸取经验，这样做得不足的以后可以避免，做得好的可以继续发扬。这并不是一种谴责惩罚行动，如果你用一种惩罚式的方法去做，只会让大家把错误隐瞒起来。
一个工作能力最佳的团队应该是不断地寻求进步，而且他们的竞争对手也不是整天无所事事的坐着让一切维持现状。他们也在不断地进步，如果你一段时间没有进步，他们就会超越你们了。
时候，他们不是找借口而是解释。我觉得这种态度很好，而且很容易学会。借口和解释有着本质的区别。
指导进度或经验教训总结
我曾经说过，经验教训总结的重点是过程。意思是，这项工作是怎么做得，以及这个过程能不能改进。
意见表述得越明确、越客观越好。第一个原则就是用人们可以直观感受到的措辞来表述——可以看、听和感觉的。第二个原则是用客观的措辞来表达你的意见，不用有可能让别人误解为是在***他们的措辞。
要清楚的是，如果人们不想告诉你关于存在问题的信息，你就不可能得到。所以如果你想整理清楚整个过程以便改进这种总结的话，就不要为了责怪和惩罚去指责他们的过错。
如果一个团队的目标都不明确，那么无论其他步骤进行的如何，都会指向失败。
人们必须清楚和认同他们的角色的责任，否则团队肯定会出现重大的问题。当
第14章 改进项目过程
一成不变，却预期不一样的结果。很显然，如果你一直在不停地重复尝试某件事，但是并没有得到想要的结果，那么就去尝试其他方式吧。
戴明博士过去常认为：有两种组织，一种组织会越来越好，另一种则会慢慢消失。如果你一成不变，那么你终将消失，而你却还未意识到这一点。你的竞争对手并不是一成不变的，如果你原地踏步，他们最终将超越你持续改进，戴明博士用这个观点去持续改善组织，这也同样适用于整个公司或者公司里的某个团队，包括项目团队。
几乎没有项目团队会停下来去思考自己是否在不断提高。
一个项目中若存在30%的重复工作，那么这就相当于全体员工每三人中就一个人在全力重复更正另外两个人做错的事情，如果能够降低重复工作，那么你就能够既减少工时又能降低成本。
定义过程
在过程结束的时候，我们将得到进步曲线。在这个时候，我们就应该放弃以前的方法，计划一个全新的方案。不幸的是，一些项目经理终止了一些本不该被淘汰的进步方案，因为这是进步的最后一步了，但是他们还没有意识到这一点。
过程改进原则
在项目改进中，首先要考虑的是，如果我们知道在某个领域内如何改进项目，我们就应该应用一些从其他项目中学习到的方法。
改进项目质量：你所做的可以减少重复的任何工作，都将改进整个项目的进程，甚至可以加快整个项目的进程。
同时执行两个项目：如果我们能够同时做同样多的事情，而不是连续做完一件又做一件，我们就可以加快项目进程。
尽量在项目进程中每一步增加价值。在生产中，对顾客来说，原材料本身并没有价值，只有当原材料被使用、成型、用于生产和用模型铸成型之后，他们才具有价值。在项目中，也适用同样的道理。在项目进行的每一步都应该增加最终产品的给消费者带来的价值。
改进在途物资的质量和时间：一个收到劣质原材料的生产商，很难生产出高质量的产品。
尽管已经出现了错误，我们也应该及时的更正它。一名优秀的信息管理员可能在处理这个问题上有很大帮助，从根本上说，我们需要的就是及时（JIT）的信息系统。
精简物资流：在生产制造过程中，现代物流装备都是从头到尾设计好的供应链。优秀的项目计划会产生同样流畅的信息流，或者顺畅的工作。
消除瓶颈：瓶颈是项目中限制物流的关键问题。
有时候，一支独立的支持小组也会成为瓶颈，因为他们为如此多的团队服务，以至于他们没有精力服务好每一个团队。
问题的可执行定义
除非每个人都对这个问题有相同的理解，否则我们不能解决这个问题。
一个特定的可执行定义没必要分清对错，它的意义在于在项目进行过程中所有成员都能够接受它。随着情况的变化，可执行定义也可能会发生变化，以满足新的需求。
一旦你已经确定了问题的根本原因，解决方案就相当明显了，尽管并没有那么容易实施。
第15章 管理和推进会议
现今社会，是一个“少花钱多办事”的社会。我们必须从我们现有的资源当中得到尽可能多的产出。
会议管理准则
开会的第一大宗罪是：在你不需要开会的时候开会。
开会的第二大宗罪是：会议没有得到所希望的会议成果。
如果你发现在规定时间内，你无法完成计划好的每件事情，那么另外安排一个会议。这样大家可以按时离开会议，做他们想做的事情。
超过1个小时的会议，应该在每50分钟后有5～10分钟的休息时间。
马拉松会议
最大时间浪费之一，就是马不停蹄地开连续好几个小时的会议。
分割“解决问题的会议”是尤其重要的。如果人们在解决问题上遇到困难，“马拉松会议”很少能起到作用。
最后一个准则，在你正式结束会议前，你应该做5分钟的会议总结。
当你进行一个项目的经验教训回顾时，要问的问题是一样的。明白下次哪些需要做得更好是非常重要的，比“有什么我们做得不好”更重要。有两个原因，第一，你不会每一件事情都做得很差，但是任何过程都是可以提高的。第二，问“做错了什么”只会叫人们更加防备，而且会对改善建议有所抵触。
如果你做这些审查，然后没有任何的改善建议，人们将会认为这些总结都是浪费时间的，并将停止参与其中。
会议中的重要角色
一个会议重要的指南就是让每一个参与者成为“第二推动者”。这就是说，每个成员都承担一部分使会议成功的责任。这将不只是“官方”领导者的责任。
没有任何一个想法应该被拒绝掉，直到所有的想法都被呈现出来，从而他们可以去对比得到最好的想法。
缺乏参与的一个主要原因是，外向型人喜欢表述他们的想法，而内向型人需要时间自己去整理他们的想法。
当你希望启发沉默者时，你也会想阻止喋喋不休的参与者。然而，你不能打消他们的热情，好的做法当然是尽可能达到一种参与的平衡。如我前面所暗示的，你可以对那些说很多的个体说，“我想我非常明白你的意思了，让我们看看其他人的想法吧。”这时候，你邀请另外一个人开始讲述。
那些善于说话的成员会推动他们偏向的选项，直到团队接受了这个选项，即便这个选项不是最好的选项（如同后面的客观的评价判断）。
正是因为如此，会议领导者必须坚持让善于说话的成员保持沉默，而其他人拥有机会表述。
记录员不需要很好的拼写或很好的板书。最重要的是讨论的线索要捕捉到。这个角色也应该轮换，以便每个人都可以做这个。
第16章 项目结束阶段
我认为只有当最后的总结回顾被实施并收集整理为经验教训文档后，这个项目才算正式完成。
行政工作结束
阶段完成时实施。正如在第13章指出的，项目总结（以及形成文档）不应该仅仅局限于整个项目的结束，而应该在全项目生命周期或阶段结束的时候进行。最后完成的文档应该是所有的之前的报告的总结。
一个项目可以推迟完成、超过预算并且范围缩小，但是如果产品是成功的，你将会被原谅。反之则不可饶恕。
最后的经验教训总结
不幸的是，在许多项目里，到最后总结时，团队成员已经被重新分配到其他项目，因此无法参与到经验教训总结中来。
知道已经做过什么同样重要，总结不仅仅局限于消极事件，当这件事做得相当好的时候，我们也需要知道其中的原因。
项目结束时的人员问题
人成为任何一个项目中的主要资源后，情感应该像其他信息一样，成为被管理的数据。如果不这样做，可能会导致人们不想接受未来的项目任务。
第17章 多项目管理
人类的大脑一次只可以处理5～9条信息。我认为，这是人们实际所能管理好的项目数目的有效范围。如果它们是大项目，那么这个数目范围可能就是3～5。假若是巨大的项目，那就只能一次进行一项了。如果是些小项目，那么这个数目范围就是7～9。
在管理项目和执行项目工作之间一直都有冲突问题，执行项目工作常常会被优先考虑——这意味着对项目的管理被放在了次要位置。
项目、任务、优先权？
把这些任务确定好优先级，首先完成级别最高的任务，然后再继续完成清单上的其他任务直到所有任务全部完成。
如果你的上司没有给你确定优先次序，那么你最好制作自己的任务清单，并呈上给你的上司，告诉他你估计每个项目或者任务将会耗费多少时间。
个人有效性
试图去做很多事情是没有效率的人的标志性特点。
你是要去管理项目还是执行项目？如果你在管理这项工作的同时还要做技术类工作，那么你能管理好一个项目就是幸运的了。
还有其他的问题，例如你的项目团队是各自为政还是互相合作，工作本身是由内部完成还是合同外包，项目是否被很好地定义，等等。所有这些因素共同决定了一个人能够同时管理多少项目。
管理生活的原则
我们相信什么，我们就能把它变成现实。
我们所坚持的信念，使我们产生对事情如何发展抱有期望，这些期望将变成自我满足的预言。
对于我来说，相信我能控制，比相信是世界上的其他因素在控制我，能赋予我更多权力。
自我概念
研究者们发现当一个学生对一门学科的学习有困难的时候，美国的父母会说这门课对孩子来说太难了。然而，韩国的父母会更倾向于说他们的孩子需要付出更多的努力，这显然是说孩子努力得不够。
如果一个人拥有普通的智商，他也能精通所有吸引他的科目。
自我概念包括三个部分，一个是你理想中的自我，这是你想要成为的样子。第二个是你的自我形象，即你相信你能变成的样子。第三个因素是自我尊重，或者是你对自己的感觉，如果你不喜欢你自己，你大概也不会去喜欢别人。
我也必须说，你不能希望一个人或一个团队第一次就能把工作做好。你应当为你自己和他人规划一个个小的成功。起点应该是容易实现的，哪怕很低，然后从那里开始提高。
为成功编制你的思路
为了确保人生的成功，你能做的最重要的事情是为成功整理你的思路，事实上你已经为你整个生命过程中的成功或失败整理了你的思路，但是你是无意识中或偶然完成的。其结果是，有一些你想做的事情，你发现无法顺利完成。如果仔细检查你的信念，你将发现你有一些潜在的信念，让你在特别的努力下也无法成功。
在假设下行动
这里有一个关键的成功秘诀：行动时假设你想要实现的事情已经成为了事实。如果你想要成为一个成功的项目经理，就表现出这是真的。去控制你的会议，像团队领导一样（事实上你就是）去影响你的团队成员，以一种积极的方式，但不要自高自大，咄咄逼人。
观察其他人的行为，看谁是有效的，并且效仿他们。
心理预演
当你面临一种情景之前，花点时间想象你自己在那种情况下，你想表现出的真实行为。心理预演已经被证实是确保你在付出努力下能成功的一种非常有效的方式。这是被运动员、音乐家和其他表演者广泛应用以提高他们的成功几率。
花时间去想象：你真的表现得很好，这将会大大提高你成功的机会。如果你自己怀疑这个结果，赶紧把它反过来，去想象成功。
预言和目标
一旦你发现地狱是真的，你再去改就晚了。
放松
你工作时，不断改变你的想法和行为，并带着你的激情将它们连成一线，这是很重要的，但是不要绷得过紧。当你放松不刻意追求的时候才能得到最好的结果。
自身调节
为了获得成功，你能做的最重要的事情是坚持去做你想要成为的人。
审慎
如果你和有着消极态度的人分享交流你的目标，他们将很快把你从理想中拉出来，并且告诉你，你是多么的不现实。
第19章 与高级管理者一起工作
项目经理与高级管理者相处的总是不那么融洽，这对于那些大部分职业生涯是技术专家而后来晋升到项目经理的人尤其如此。可以这么说，从技术专家到管理者并不是那么容易转变的。对于技术工作，你感觉到游刃有余，而对于很多情况下没有培训的管理工作，你却不知所措。除此之外，技术和管理这两个职位的语言是有很大区别的。
管理者经常谈论的是商业或组织，例如财务、政治、战略、合作问题，等等，而技术职业经常涉及的是他们特殊的领域，如工程、化学、信息技术、社会科学，等等，这意味着成为管理者的技术专家必须学会如何向管理者一样去说话和思考
为了赚取更多的薪酬而进入管理岗位就是职业生涯的规律，但是有很多处于管理职位的人们并不是真的想从事管理，只是他们不喜欢自己的工作。
我的同事道格·德卡罗（Doug DeCarlo）著有《高端项目管理》（eXtreme Project Management）（DeCarlo，2004），用以下的方式描述过，“我花了很多年试图在我讨厌的工作中变得很成功，因为我认为当我很优秀时，我就会喜欢这项工作，很不幸的是这条路走不通
假设你想做好你项目经理岗位的工作，你需要做的第一件事就是必须将你技术的角色换成管理的角色，学习组织管理的实质，学习怎么能使企业的高管夜不能寐，学习他们讲话并重视他们。你会发现，相对于你继续使用技术专家的语言，你将能够更有效的与他们交流。
帮助管理者满足他的需求
职业生涯中你最重要的人当然是你汇报工作的直接上级领导。他留你在这个职位上的唯一原因是，他希望你的行为能协助他完成他的领导给予他的目标。他们的领导通过如何评价他们完成任务和目标的情况，来考核他们的绩效，他们又依次将这些任务和目标下派给你。在项目经理的位置上，他们期望你让项目的质量、成本、时间、范围都实现目标。正是这个事实，引出了项目经理与高管的种种分歧。
我当然建议你试着影响你的老板，试着用理性面对现实。但是如果你发现你正在面对一个对你的任何合理的方式都没有反应的领导，那么你只能保护你自己，调离你所在的部门或者如果必要的话重找一份工作。人生苦短，不能承受持续的压力。
教会经理如何进行项目管理
真相是，实际的工作中并没有浮动时间，它只出现在纸上。显然，他的老板需要知道更多浮动时间的知识。
与高级管理者工作时应用HBDI剖面图
导致这些问题的原因不是性格差异，而是由于思维偏好的差异。
理解上级管理者的观点
你的老板根据你满足她标准的程度来考核你的绩效，这是很明显的，尽管有时会被忽视，因此你应该努力完善这方面的绩效。但是我知道有些人做了他们认为重要的事，完全忽视了他的老板所清楚描述过的重要事情，然后他们会很惊奇地发现老板对他们的表现并不满意。
如果老板给你布置了一项任务，发现老板评估你的表现是问“对于这项任务你想要什么样的结果？”第二个问题是，“你怎么知道已经达到这些结果了呢？”这些问题可以帮助你的老板明白他自己的立场，事实上他没有时间很透彻地思考这些问题。不管怎样，一旦答案给出了，你就会很清楚地知道老板如何对你的表现给予评价。
需要问的另一个问题是“你如何看待这种状况？”这个问题的好处是它不仅揭示出你的老板看待问题的方式，而且还教会你自己如何处理这种状况。他是一位经验丰富的管理者，而你年轻又没有经验，因此你应该学会如何去考虑商业问题。
找个良师益友
你并不会认同他所有的行为，但是试着去理解他从哪里来，找出他的背景，他来自于哪里，什么样的生活经历让他得到了这份工作。试着从他的角度去思考问题，即使你不赞同这种观点，如果你了解了他如何看待这个问题的，你可以从同样的角度出发来做出决策，那么可以肯定他会同意你的选择。
与项目团队成员相处
技术方面很强的人通常都是性格内向的，他们生活的大部分时间都在与物打交道，因此常常缺乏人际关系技能
彼得·德鲁克写到，经理必须让人们在工作中的绩效超越最低允许接受的水平，因为那只是生存水平。一个组织要做的不只是生存——它要不断地完善自己（Drucker，1973）。
人们的绩效水平不会超过他们的能力，但是，如果你不对他们的绩效水平提出期望，你甚至不会得到他们的能力所能达到的水平。
我们喜欢采用与我们现有信念一致的方式去感知世界。因此，如果我们认为大多数人都是刻薄的，讨厌的，不友好的，我们也会发现大多数人真是这样的，无论客观上他们是否如此。
由于无论你相信什么或者做什么，团队中总会有一些人会无动于衷。因此，如果你无法赢得一些人的绩效回报也不必让自己痛苦，也许本来就是不可能的。
激励
丹尼尔·平克明确表示，研究表明对人来说真正的激励都是内在的（Pink，2009）。尝试使用原本认为可以提供动力的外部激励措施如工资和奖金等，最终反而使个人有更少的动机去做成功这项工作［更多内容请见科恩（Kohn，1999）］。
如果我们知道一个人的思维偏好，将会对这个人从事何种工作有一个很好的处理。显而易见，如果项目中的工作与某个人的思维偏好不符，那么这个工作对该员工就没有较强的激励作用，他的表现或许可以接受，但这并不是他在巅峰状态的能力水平。
实现高水平激励的基本准则就是分配给员工的工作本身要满足他的内部驱动力或需要。如
处理政治
事实上组织生活中的每一个行为都是一种政治行为。
他们经常要与那些不了解项目性质，或者在很多情况下不关心项目实际情况的人打交道。他们所能做的就是对于政府发起人的问题提供满意的答复。由于不同的干系人有不同的利益，因此无法令所有人都满意。
如果不喜欢管理项目中的政治方面的工作，可以在项目中寻找在政治之外的工作或者直接寻找另一份职业。这不是我的草率之言——人生若短，不能将时间花费在做你完全厌恶的事情上。
不要指望花的时间多就能把自己不喜欢的事做好，不要抱着如果做好了就会喜欢的想法，很遗憾，从来都不会这样。
技能培养
神经语言程序的创始人之一约翰·葛瑞德在他的研讨会上曾告诉我们小组成员，如果想成为好的经理就要学习一门课——表演。我坚信他是对的。
虚拟项目团队
除了距离因素外，现在还有跨文化因素的问题。当团队成员来自其他文化领域时，在协调沟通、绩效评估和影响问题时很容易出现分歧。难以面对面地相处，而使用电话、互联网、甚至视频会议更显著增加了这种沟通的难度。
不仅仅是来自不同文化的人会误解词语的意思，美国人也会使用大量的成语，这令处在美国文化之外的人很费解。
文化差异通常没有好坏对错之分（除非涉及人权）。总体来说，文化差异是价值观的不同。
科技：更好或更糟
随时可用的软件在一定程度上强化了一些高层经理头脑中的观念；项目管理就是管进度
附录A 进度表计算
一旦画出工作网络图，并为所有的活动分配了持续时间，就有必要通过计算，找出项目中最长的路径。如果项目的开始日期和完成日期已经被事先“确定”，这些计算的结果可以告诉你要求的期限能否满足。从另外一个方面说，如果给定一个开始日期，就可以计算出项目的最早完成日期在什么时间。
一般来说，在估算项目工作时间时不考虑资源限制。就是说，任何活动的持续时间都被当成是固定不变的，因为我们假设当工作开始时，就可以得到所需的资源。
原则1：在一项任务开始之前，所有在它前面的任务必须已经完成。
原则2：箭头只表示逻辑顺序，它的长度与角度没有任何意义（它不是一个向量，而是一个标量）。
浮动时间只是项目涉及的一种风险，项目还会有来自技术问题、错误估计、天气或其他不可控因素等的风险。正确的决定是，应当综合考虑这些因素的状况。
增加一个项目的人力有两种方法。一种是增加人数，一种是让同样的人每天工作更长的时间，我们把这种方法称为工作超时。无论是哪种方法，很快都会出现边际收益递减的情况。
当生产能力降低，同时错误没有增加时，这通常是因为人们在有意放慢自己的步伐。
知识型工作也面临着同样的问题。一项研究表明，人们在知识型工作上超时工作12小时所增加的产出，仅等于他们正常工作2小时的产出量！
帕金森法则说，工作总是会被拖到所要求的时间才能完成。把这运用到浮动时间上，就意味着，只要给他们浮动时间，他们就会利用浮动时间！由于这个原因，有些软件可以设定不给浮动时间，这种进度表就只是要你按图中所示的开始时间去做工作。
更多内容，欢迎关注以下MVP公众号：
