下载掌阅APP，畅读海量书库
立即打开
所以，不就是项目管理吗，值得大动干戈写一本书？本书1997年出版第一版以来，项目管理协会（Project Management Institute，PMI）的会员数量已经从几千人，增加到2015年的将近46.2万人。可能有人不是很清楚，所以还是解释一下：PMI是项目管理者的专业组织，了解更多信息可浏览PMI官网www.pmi.org。除了提供多种会员服务之外，PMI的一个主要目标是提升项目管理的专业度。为实现这一目标，PMI建立了“项目管理专业人士”（Project Management Professional，PMP ® ）资格认证体系，要获得这一认证，必须具备工作经验（大约5000个小时），并通过一个在线考试，考试教材是《项目管理知识体系指南》（ Project Management Body of Knowledge ，PMBOK ® 指南）。
为何要专为项目管理成立一个专业协会？项目管理不就是一般管理的一个变种吗？
这种说法也对也不对。两者有许多相似之处，但是也存在差异，而且差异之大，足以将项目管理当作一个有别于一般管理的学科。其中一个差别是，项目的日程比一般管理者处理的大多数活动都要更加密集。另外，项目团队的成员常常不是直接向项目经理汇报，而是向最一般的管理者报告。
所以，什么是项目管理，项目又是什么呢？PMI将项目定义为“ 为创造一个独特的产品、服务或结果所做的临时性努力 ”。这意味着项目是一次性的，如果重复就不能称作项目。项目应该有确切的起点与终点（时间，time）、预算（成本，cost）、明确界定的工作范围（scope）或范畴，以及必须满足的具体质量（performance）要求。我之所以说“项目应该有……”，是因为很少有项目严格符合这一理想化的定义。后面的章节中，上述四个约束条件将被简称为PCTS（质量、成本、时间、范围）目标。
已故的质量管理学大师约瑟夫·朱兰（J. M. Juran）博士，同样将项目定义为“ 待解决的问题 ”。我很喜欢这个定义，因为它时刻提醒着我每个项目都是要为公司解决某些问题。不过，必须要指出的是，“问题”这个词常常是贬义的，可项目不仅解决“负面”问题，也解决“正面”问题。例如，开发新产品也是一个问题，不过是一个正面的问题，而环境清理项目则是处理负面问题。
目前关于项目管理成功率的研究，结果不尽相同。斯坦迪什集团（Standish Group）发布的《混沌》（ Chaos ）报告称，软件开发项目的成功率是29%，52%未完全达成目标，19%失败。需要指出的是，该报告规定的成功标准已“与时俱进”，也就是在预算内按时完成，而且结果达标。2011年以后发布的报告显示，软件开发成功率基本保持不变。报告还强调称，相比大型项目，小型项目的成功率更高。IT研究及咨询公司高德纳（Gartner）最近发布的报告也得出类似的结论，即大型项目（即预算超过100万美元的项目）的失败率较高，在28%上下浮动。
最有说服力的还是PMI最近发布的数据。PMI一直持续观测项目、项目集及项目组合管理的状态。他们2015年发布的研究《职业脉搏调查》显示了一些积极的趋势，但是，项目成功率依然持平，自2012年以来，成功率一直保持在64%的水平。那么如何才能提高成功率呢？PMI的建议是回归基本，他们归纳了三个基础领域：
基于28年的项目管理、最佳实践识别、项目咨询及培训的经验，我的看法是“万变不离其宗”。再怎么事先规划都不够，无论大项目还是小项目，无论是软件项目，还是研发项目，或者行政管理项目，成功的项目都有赖于良好的规划。太多项目经理为了快速完成一个项目，就采用“先开枪，再瞄准”的方法。许多组织则没有留给项目经理充足的规划时间，甚至完全不给规划时间，结果通常是花费更多时间和努力来修正错误、安抚不满意的干系人以及退出死胡同，简单来说就是规划不足导致项目失败。
PMI的调查报告称：“组织应重温项目管理的基础，并最终回归基本。”我无比同意这一说法。广大读者们，你们必须打好基础，理解本书阐述的这些基本知识，才能在推进并管理项目时获得进步与成功。
PMBOK ® 指南对项目管理的定义是：“在项目活动中运用知识、技能、工具及技术，达成项目要求。项目管理需运用并组合47个项目管理过程，它们依逻辑可归入5个过程组：启动、规划、执行、监控和控制、收尾。”
新的PMBOK ® 指南增加了五个新的项目管理过程，即：
这一修改意在强调项目团队在管理之前务必进行规划。为了强调让项目干系人适当参与关键决策和活动的重要性，所以在原本九个知识领域的基础上，又新增了“项目干系人管理”，“规划干系人管理”和“控制干系人管理”就是该知识领域下的两个项目管理过程。
项目要求即前述PCTS目标。本章后面部分将阐述启动、规划等过程，本书的大部分内容都将解释如何完成这些过程。
PMBOK ® 指南若明确指出“项目经理应促成规划”就更好了。欠缺经验的项目经理常犯的一个错误是，替整个团队制定规划，这样制定出的规划不仅不能获得认同，还常常漏洞百出。项目经理不可能面面俱到，比如他们对任务所需时间的估计可能错误，一旦项目启动就会纰漏不断。项目管理的第一条准则就是： 真正做事的人务必参与规划。
项目经理的角色应该是“赋能者”，也就是帮助团队完成工作，为团队“做好后勤”，为团队成员获取必需的稀缺资源，为他们屏蔽外力干扰。项目经理首先应是一个名副其实的“领导者”，不应是一个“皇帝”。
目力所及，我认为万斯·帕卡德（Vance Packard）给“领导”所下的定义堪称最佳。他在《金字塔攀登者》（ The Pyramid Climbers ，）一书中写道：“ 领导是一门艺术，是让他人心甘情愿地去做你认为应该做的事 。”这里的关键词是“心甘情愿”，独裁者也能指使他人做事，狱警能监督犯人干活，可是，领导者是让人心甘情愿做事，这中间差别很大。
项目工作的规划、排时程以及控制属于管理或行政的部分。但是，如果没有领导力，项目只能达成最低要求。有了领导力之后，就能达成更多要求。我在第14章深入阐述了运用项目领导力的技术。
关于项目管理，有一个很常见的误解，也就是项目管理只是排定时程。微软最新财报显示，其项目管理软件Microsoft Project的销售数量极为可观，可是项目失败率依然高企。毫无疑问，排时程是管理项目的一个重要工具，但是远不及明晰项目目标或做好工作分解结构（work breakdown structure，WBS）来得重要，创建WBS需识别所有待完成的工作（第7章将讨论WBS）。事实上，没有好的项目管理，一份详细的时程表，只不过是一份准确记录项目失败的回忆录罢了！
关于时程软件，我还想再多说几句。你选择哪个软件并不重要，因为每个软件都有各自的优缺点。可是，目前常见的做法是，把一个软件丢给相关人员后，就指望他们能无师自通，学会如何使用。这绝对是行不通的。时程软件的特点是，大多数人不能靠自学掌握其微妙之处。他们还要做分内的常规工作，自学时间不多，而且也不是每个人都擅长自学。你不可能让一个毫无经验的新人，不经培训就去工厂操作一台复杂的机器，因为你知道后果肯定是搞坏设备，或者新人伤到自己。软件也是同理。
你是否经历过这样的事：突然被派去管理一个项目，可是没有“项目经理”这个头衔，也没给你提供太多支持？你是否认为自己是项目经理，而且你一个人就是一个项目团队？遇到这种事的不止你一个人。越来越多人管理的内容符合PMBOK ® 指南对项目的定义，也就是“为创造一个独特的产品、服务或结果所做的临时性努力”，有最后期限，有待确定的工作范围，资源有限，预算通常是固定的。尽管不那么正式，也不需要项目团队，但这些项目必须经过规划、排定时程并进行控制。必须交付一个优秀/可接受的项目产品，客户应该赞赏有加，或者至少是满意的。
我为美国管理协会（国际）主持过一门研讨课，名为“非项目经理的项目管理要点”，非常受欢迎，在非传统项目经理、主题专家、发起人以及项目贡献人中引发巨大反响。学员通常包括销售经理、行政人员、市场经理以及采购专员等。似乎每个人都会或多或少涉入某些项目。这些学员不是传统意义上的项目经理，但是必须管理项目。项目管理工具有帮助，可我总是跟学员说，大家使用的项目工具都一样，要发挥其价值，关键在于如何使用。
首先要进行评估：你是否受限于工作范围、成本以及有限资源？是否有最后期限？如果答案是肯定的，那么就可以当作一个项目来管理，明确什么样的项目工具合适。例如，限期两周的项目所需的项目管理应用工具比限期50周的项目要少得多，应根据项目的长度、宽度、深度和广度来精简或增加管理方法。
有一种情况很常见：一个人既是项目经理，同时也需要承担部分具体的项目工作。这势必引发一系列问题。如果是一个真正的由几个人组成的团队，那么，到最后项目经理必然分兼两职，既从事管理，也要完成分给他的工作。他自然要将工作摆在第一位，否则进度就会跟不上，所以他选择完成工作，这就意味着他会疏于管理，他希望团队能自我管理，可是这绝无可能。毕竟，如果一个团队能自我管理，那从一开始就不需要项目经理了。（还记不记得我们关于项目管理是否重要的讨论？）
不幸的是，到了绩效评估时，他就会挨批：你在管理方面还有待改进。实际上，他只是需要从一开始就专心于项目管理工作。
是的，对于一个只有三四个人的团队来说，项目经理可以分担一些工作。可是，随着团队人数增加，分兼两职就力不从心了，因为团队成员总是会有各种问题需要你去处理，让你无法完成分摊的工作。
造成这种窘境的一个原因是：组织没有完全理解项目经理的含义，他们认为一个人可以分兼两职。导致的结果就是公司里的每一个人都开始尝试管理项目，可有些人擅长项目管理，有些人就是没有这方面的细胞，实际上每个领域都是如此。我发现更好的做法是：选择一小部分有能力且有意愿做项目经理的人，让他们管理一些小的项目，这就能让“技术”人员（广义的技术人员）从事具体的技术工作，而不必担心行政问题，也可以让项目经理真正做好管理工作。
如何选择项目经理不在本书的讨论范围之内，对这个问题感兴趣的读者可以参阅罗伯特·维索茨基（Robert K. Wysocki）和詹姆斯·刘易斯（James P. Lewis）合著的《世界级的项目经理》（ The World-Class Project Manager ）。
导致项目失败的一个常见原因是：项目发起人要求项目经理必须在一定时间内，在预算范围内按照规定的质量标准完成给定范围内的工作，换句话说，发起人对项目的四个约束条件都做出了规定，这是强人所难。
质量、成本、时间和范围这四个约束条件的关系可以用下面这个函数来表示：
C= f ( x )（ P , T , S ）
用文字来表述就是，成本（C）是质量（P）、时间（T）和范围（S）的函数。如果用图像来表示，我想用三角形来进行说明，P、C、T代表三角形的三条边，S就是其面积，如图1-1所示。
学过几何的都知道，给定三角形的三条边，就能计算其面积。或者，如果我们知道了面积及两条边长，那么我们就能计算第三条边的长度。应用在项目管理上就可以得到一个非常实际的准则：发起人可以规定其中三个变量，但是剩下的第四个变量必须由项目经理来确定。
图1-1 用三角形来表示 P 、 T 、 C 、 S 之间的关系
打个比方，发起人如果规定了一个项目的质量、时间和范围要求，那么需要多高的成本才能达成这些要求，就必须由项目经理来确定。不过，我常常提醒项目经理一件事：你向发起人报告成本时，最好请一个医生站在旁边，因为她听完那个数字很可能会中风或心脏病发作。
发起人无一例外会大惊失色说：“怎么会要这么多钱？”发起人自己心里有个数字，可是你给出的数字肯定比那个数字高，接下来发起人可能会说：“如果成本这么高，那我们觉得项目可行性就有问题了。”是的，这绝对是发起人会说的话。可是，她也绝对会跟你讨价还价，让你接受一个较低的成本，如果你接受了，那么结果就已注定：你，以及她，之后都将栽个大跟头。
你的责任是给发起人一个合理的成本，发起人据此做出一个合理的决定，也就是这个项目还应不应该做。如果你经不住吓，接受了较低的成本，那就做好准备迎接灾难吧，你还不如早死早超生，比日后受尽折磨要好得多。
当然，你还有另一种选择。如果发起人说成本就这么多，你可以提议减少工作范围。如果你提出的范围可行，那么项目就能继续下去。如果不行，你最好忘掉这个项目，为公司做点其他能赚钱的事。正所谓，项目出错是必然，项目一帆风顺才是偶然，成本评估也是如此：项目超出预算的可能性更高，而不是相反。这其实是墨菲定律的另一种表述，墨菲定律的原话是：只要可能出错，就一定会出错。
关于项目生命周期的阶段划分，有许多不同的模型。其中一个模型概括了项目管理不善时所经历的阶段，极其常见，如图1-2所示。
这张图我给无数人看过，每个人看完都笑着说“真的，太准确了”，无一例外，这让我稍感“安慰”，因为由此可见，不止我们美国人会遇到图里提到的这些问题，但可悲的是，人人都对这个模型心有戚戚焉，表明项目出错非常普遍。
图1-2 出错项目的生命周期
最简单的划分是将项目分为开头、中间及结尾。就我个人而言，我更偏爱图1-3所示的生命周期模型，但有效的模型不止这一个。按照图1-3这个模型，每个项目都是从一个概念开始，这个概念往往是“模糊的”，接下来，在开始各项工作之前，项目团队必须正式给出工作的定义。然而，由于“先开枪，再瞄准”的心态作祟，我们常常在没有适当地定义工作或者团队还有人不了解工作的使命和愿景之前，就已经开始具体工作。随着项目推进，这必然导致严重问题，后面会举例说明。
图1-3 恰当的项目生命周期
几年前，某个客户公司的项目经理打电话给我说：“我刚和项目团队的关键成员开了个电话会议，发现我们对于项目目标没有达成共识。”
我非常肯定地跟他说这很普遍。
“我应该怎么办？”他问。
我跟他说：你别无选择，只有明确项目使命，才能让所有团队成员朝着同一个方向前进。他让我协助他开一次会，来解决这个问题。
开会时，我首先站在夹纸白板前说：“我们先撰写一份问题陈述。”话刚说完，马上就有人反驳说：“不用，我们都知道问题是什么。”
我不为所动，回说：“好吧，如果是这样，那么就走个形式，也花不了几分钟，如果能写下来，将对我有所帮助，所以有人能帮忙起个头吗？”
一个人接话说：“问题是……”我在白板上才刚写下这几个字，另一个人就跳出来说：“我不同意！”上面这个描述可能稍有点夸张，但当时情形差不多就是这样。
结果整整花了三个小时，我们才终于写出一份问题陈述。
项目经理没说错，团队确实没有就“问题是什么”达成共识，更不用说如何解决问题了。明确问题是基础，但常常无法做到，我甚至开始想，是不是我们每个人都有个缺陷基因，导致我们无法坚持做到“先清楚定义问题，再开始具体工作”。请记住，项目管理要做的就是解决一个大型问题，你定义问题的方式将决定你解决问题的方式。如果你的定义错了，那么你可能得到一个正确的解决方案——但解决的问题却牛头不对马嘴！
事实上，我现在坚信项目很少会在收尾阶段功亏一篑，而是在定义阶段就已宣告失败。顾名思义，“定义”阶段处于项目早期，是定义问题、制定愿景、明确使命的阶段。我把没有清楚定义的项目称作“无头鸡项目”，一只鸡的头被砍掉后，会四处乱跑，鲜血喷涌，最后终于倒下，“正式”宣告死亡，没有清楚定义的项目也是如此，它们一路上“鲜血四溅”，最后终于有个人跳出来说，“我认为这个项目已经死翘翘。”这个时候项目确实是死翘翘了，但实际上，早在“头被砍掉”的那一刻，它就已经死了，只是我们还需要一段时间来确认。
项目被“定义”之后，你就能规划各项工作了。规划分为三个组成部分：战略、战术和后勤。战略就是各项工作须遵循的纵观全局的方法或“制胜之道”。我一个喜欢军事史的朋友曾给我讲过一个故事，下面我用这个故事来说明战略。
战略阶段决定项目为达成要求将采用的高层次方法，一个典范案例是埃文代尔造船厂（Avondale Shipyard）。第二次世界大战期间，国防承包商需大量建造武器，所以面临巨大压力。特别地，为了加快舰船和飞机的建造速度，发明了许多新的组装方法。位于新奥尔良以北密西西比河的埃文代尔造船厂也开始尝试新的造船方法。传统的造船方法都是甲板顶面朝上的正造法，然而，钢质船船底的龙骨区需要焊接，船体正放时焊接非常困难。于是，埃文代尔造船厂决定采用反造法，也就是将船体倒过来使船底朝上的建造方法，这样焊接操作更容易，之后再将船体翻转，完成甲板以上的结构装配。这一战略十分有效，埃文代尔造船厂因此获得竞争优势，造船速度更快，成本更低，质量也更好。如今将近70年过去了，这一战略依然广为使用。
项目的执行面规划阶段包括战术和后勤。如果你打算采用反造法造船，你必须搞清楚反造法造船的细节。例如必须建造一个能托住舰船的固定装置，确保翻转时不会受损。这就是所谓的制定战术。此外还包括确定工作顺序，由谁来完成，以及每个步骤花费的时间。
后勤则是确保团队的物资供应。通常来说，我们可能只需要给团队提供原材料，但是如果项目所在地无法获取食物，那项目马上会陷入停滞，所以必须喂饱团队成员，很可能还要为他们提供住宿。
一旦制定好规划并得到批准，团队就可以开始工作了。这就是项目的执行阶段，但这个阶段也同时包括控制，因为，执行规划时须监控进度，确保工作进度与规划保持一致。当项目偏离规划时，需采取纠正措施让项目重回正轨，如果无法纠正，就得修改规划，重新获得批准，修改后的规划成为新的进度参考标准。
所有工作都完成后，项目收尾阶段须对项目进行总结，目的是总结经验教训，供未来借鉴，可以问两个问题：“我们哪些地方做得不错？”“哪些地方有待改进？”
请注意，不要问我们哪些地方做错了，这个问题会让人产生防备心理，大家可能会有所隐瞒，避免受到惩罚。事实上，经验教训总结绝不应该采用责备与惩罚模式，如果你是想实施调查，那又另当别论。调查的目的往往是找出谁应该为重大事故负责，然后实施惩罚，而经验教训总结就应该是单纯地总结经验教训。
过去几年，我发现只有极少数的组织会例行总结项目经验教训，大家都不愿“自找麻烦”，只想开始下一个项目。可问题是，如果大家都不知道上一个项目哪里犯了错，不知道怎么犯的错，自然就不知道该如何避免，因此极有可能重蹈覆辙。但最重要的是，如果不总结，你甚至没法借鉴之前好的经验。
有人说过，能活下来并且活得很好的组织都是学习能力比竞争对手更强的组织，从项目角度看，这话尤其正确。
项目管理的实际步骤其实简洁明了，但实施可能就不是那么回事了。图1-4列出了这些步骤。
本书接下来的章节将详细阐述如何完成每个步骤，本章将简短描叙一下大致框架。
图1-4 项目管理的步骤
前面说了，你需要识别项目要解决的问题，这有助于明确理想的结果长什么样子。项目完成后，会发生哪些变化？你将看到什么，听到什么，尝到什么，碰到什么，闻到什么？（如果问题不能量化，就使用感官证据。）项目能满足客户的哪个需求？
你可以采用哪些不同的方法解决问题？针对不同的解决方案进行头脑风暴（你可以单独完成或者组队完成）。可用的解决方案中，你认为哪个是最好的？成本相比其他解决方案是多是少？将完全解决问题还是只解决部分问题？
规划需回答以下问题：必须做些什么？谁来做？成本多少？如何完成？何时完成？很明显，回答这些问题通常都需要预测未来。我们将在第2章、第3章和第5章详细讨论这些步骤。
显然，规划一旦制定，势必需要执行。有趣的是，我们有时候会发现人们花了很大力气制定规划，可是之后又不按照规划来做。如果制定了规划却不遵循，那制定规划有何意义？
定好规划就是迈出了成功的第一步，可是如果不监控进度，你就不能确保一定会成功。就好比确定了目的地后，手里明明拿着地图却不注意看沿路的高速公路标志。
当然，一旦发现偏离规划，你必须问自己如何才能重回正轨，如果无计可施，面对新的现实，应该如何修改规划？
一旦达成目标，项目就完成了，但是还有最后一个步骤。有人称之为审计，还有人称之为“验尸”（听着有点瘆人，有没有？）。可不论叫什么，重点都是总结经验教训。注意问题的措辞：“哪些地方做得不错？”“哪些有待改进？”“额外学习到什么？”不论做的怎么样，我们总会有改进空间。可是，如果你的问题是：“我们做错了什么？”那么，大家可能会产生一点防备心理，所以关注点应该是如何改进，而不是追责。后面会进一步阐述。
项目管理协会尝试确定了一个高效项目经理需掌握的“极简”知识体系。我前面讲项目管理定义的时候说过，PMBOK ® 指南定义了5个过程，加上10个一般性的知识领域，这里我将简单总结一下。如果你想要一份完整的资料，可以浏览PMI的网站。
过程就是做事的方法。前面提过，PMBOK ® 指南确定了管理项目的5个过程。尽管其中一些过程会在项目的某些阶段占据主导地位，但也可能随时都会用到。不过，一般来说，它们都是随着项目推进依次出现，也就是首先“启动”，接着“规划”，然后“执行”，以此类推。如果项目偏离轨道，就要重新规划，如果项目出现严重问题，可能就得全部推倒重来，再次“启动”。
一旦决定上马一个项目，就必须启动或者开始。启动包含许多活动，其中一个是项目发起人制定项目章程，明确需要做些什么才能满足项目客户的要求。这是一个经常被组织忽略的正式过程。章程应授权项目工作，规定项目团队的职权、责任及问责机制，划定工作的范围界限。如果不制定这样的章程，那团队成员可能误解组织对他们的要求，可能因此付出巨大代价。
项目失败的一个重要原因是规划没做好。实际上，我这样说还算客气了，大多数时候，根本就是没有规划！团队就只是“走一步算一步”，完全没有做任何规划就开始工作了。我前面已经解释过了，有许多人是任务导向的，认为做规划是浪费时间，所以直接动手去做。当我们想要控制项目的时候就会发现，没有规划意味着不能实际控制项目，等于是在闹着玩。
项目执行分两个方面。一是为了创造产品，执行必须完成的工作，这可以称为“技术性工作”。项目的目的就是创造产品，请注意这里说的“产品”是非常广义上的产品，可以指摸得着看得见的物品，如一个硬件或一幢建筑；也可以指软件或某种服务；还可以指某个结果，例如，一个包含更换机油及调换轮胎的汽车项目，就不会产生可交付的有形产品，但显然有一个必须达成的结果，如果中间出了差错，汽车可能因此受损。
执行也可以指实施项目规划。项目团队常常花不少时间制定规划，可是一旦遇到困难，就将规划抛到九霄云外，这真的很不可思议。一旦抛弃规划，团队就会失去对项目的控制，因为没有规划就没有控制。至于解决办法，要么是采取纠正措施，让项目重回旧轨，要么修改规划，使其反映项目现状，同时指出未来方向。
实际上，监控和控制可视为两个不同的过程，但因为它们是相辅相成的关系，所以被归为一个活动。控制就是比较项目的“实然”和“应然”，一旦发现项目偏离目标，就采取措施纠正，而规划就确定了项目的“应然”，所以如果没有规划，你就不知道项目的“应然”，控制项目自然就无从谈起。
另外，要了解项目的“实然”需对项目进度进行监控。根据工作性质，利用任何可用的工具对已完成工作的数量和质量进行评估后，将评估结果与规划进行比较，如果实际进度超前，那就要采取行动将进度往后调整。当然，小的偏离在所难免，只要不超过事先设定好的限度，也没有继续扩大的趋势，大可以置之不理。
一种极为常见的情况是，只要产品达到客户的要求，团队就认为项目完成了，或者结束了。这种做法应避免，进行最后的经验教训总结之后，项目才算真正完成。如果不总结经验教训，就意味着未来的项目可能重犯刚刚犯过的错误。
前面说了，PMBOK ® 指南总结了一个专业的项目经理应熟悉的10个知识领域，下面一一说明。
项目综合管理应确保项目规划、执行及控制都做到位，还包括正式的变更控制。“综合”也意味着，为了达成理想的成果，每项活动都必须与其他活动协调或整合。
项目范围变更往往是扼杀一个项目的“凶手”。项目范围管理包括授权工作，制定范围说明书以定义项目的界限，将工作细分为易管理的、带可交付成果的组成部分，核实规划的工作量是否完成，规定项目变更控制的程序。
我认为这个术语不够准确，因为“时间管理”似指个体管理自己的时间。实际上，项目时间管理特指制定一个可行的时程，然后据此控制工作进度，就这么简单！因为所有人的用词都是“时程”，所以应该称之为“时程管理”。（好吧，我知道，我可能会因为这样的“异端邪说”而被踢出PMI！）
这个术语就很准确了。项目成本管理首先估计各种资源成本，包括人力、设备、物资、出差以及其他支持费用，之后就是做预算并跟踪成本，确保项目不超过预算。
前面说过，项目失败的原因之一是为了“赶工期”而忽视或牺牲质量。就算项目按时完成，可交付的产品不达标也是无济于事！项目质量管理包括质量保证（通过规划达到质量要求）以及质量控制（监控结果，检验结果是否符合要求）。
常被忽视的项目人力资源管理包括确定完成项目需要什么样的人，明确他们的角色、责任及报告关系，招揽这些人并在项目执行过程中对他们进行管理。请注意，这里所说的不是实际的人员日常管理。PMBOK ® 指南表示这些技能不可或缺，可是没有展开论述。由于这是项目经理必须具备的重要技能，因此可以说PMBOK ® 指南是有所缺失的。
顾名思义，项目沟通管理是指，对于所有项目干系人所需全部信息的获取和传播，进行规划、执行及控制。这样的信息可能包括项目现状和成果，以及可能影响其他干系人或项目的事件。同样，项目沟通管理不涉及与人沟通的实际过程，PMBOK ® 指南也提到了这个主题，但是未包含在内。
项目风险管理是识别、量化及分析项目风险并做出应对的系统性过程，内容包括：对于正面事件，尽可能提高其发生的概率，增加其对项目目标的影响，对于负面事件则相反。这是项目管理中极为重要的一个方面，有时会被没有经验的项目经理忽视。
项目所需物品及服务的采购隶属于后勤范畴。项目采购管理包括确定什么必须采购、发放投标或报价邀请、选择供应商、合同管理以及完成采购后的收尾工作。
项目干系人管理包括识别及管理可能影响项目或被项目影响的个人、团体或组织。“干系人”这个术语名副其实，项目经理必须问自己：“谁和项目成果利害与共？”如果干系人会影响项目或被项目影响，那就应该找到他们，进行适当的管理。干系人不应该一视同仁，而应该根据他们对项目影响与支持程度的差异来制定规划，然后再投入适当的时间与精力进行管理。
● 项目是为了创造一个独特的产品、服务或结果所做的临时性努力。
● 项目同样是一个待解决的问题。
● 项目管理是在项目活动中运用知识、技能、工具及技术，以达成项目要求，项目管理会用到如下几个过程：启动、规划、执行、监控和控制、收尾。
● 所有项目都受到质量、时间、成本及范围这四个要求的约束，只能对其中三个约束条件任意赋值，第四个必须由项目团队来确定。
● 项目失败的一个原因是团队没有花时间定义需要解决的问题。
● 项目主要阶段包括概念、定义、规划、执行、控制及收尾。
● 必须识别项目干系人并进行管理。
1．项目管理不仅仅是
a．规划
b．返工
c．排时程
d．控制
2．一个需要边做边管的项目经理面临的问题是，当分摊的工作与管理之间发生冲突时：
a．你不知道两者该以谁为优先
b．老板会觉得你偷懒
c．如果两者兼顾，时间绝对不够
d．将优先完成分摊的工作，无法兼顾管理
3．PMBOK ® 指南指的是：
a．PMI认为高效项目经理所需的知识体系
b．PMI的项目经理认证考试
c．某种特殊风险分析的缩写，和FMEA（Failure Mode and Effects Analysis，失效模式与效应分析）一样
d．以上都不是
4．项目范围指：
a．项目经理规定的结束日期
b．工作的范围或规模
c．项目变更的频次
d．项目经理的权限