作者：杨爱华,王丽珍等
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
项目管理：计划、进度和控制的系统方法：第12版试读：
译者序
科兹纳博士的《项目管理：计划、进度和控制的系统方法》一直被业内称为“项目管理圣经”，是学习项目管理知识的一号读本。
第 12版的更新，科兹纳紧跟业界最新的动态和理论前沿，依据《项目管理知识体系指南》第6版的最新调整，根据作者咨询团队的实践，深入介绍了新近的项目管理热点：包括怎样进行全球干系人管理、导致项目失败的原因分析、敏捷项目管理的最新进展、项目治理失败的原因分析、如何处理客户批准的里程碑、怎样正确对待当前的各种项目分级的标准等。同时，也为这些新的问题更新了相关的参考资料。
在这个版本中，作者特别关注了如何理解组织结构和项目管理职能的关系；怎样去控制成本、管理风险和进行机会成本分析；如何验证用在计划、进度和质量分析等方面的各种方法的差异；并试图在项目范围扩大和复杂性增加的国际环境中，建立一种跨越时区和语言障碍，面向全世界不同技术平台的通用的项目管理体系。
第12版对全书作了大篇幅的调整，由前版的24章，调整为21章，也删除了与一般项目管理者无关的几个大案例（且多为公共信息，如依星计划），且对前一版各章中的烦琐重复的部分进行了删减和归并，使本书在增加大量新理论和方法的基础上，却减少了1/3的篇幅。
作者对Program一词的使用频繁，也许是他认为今天的项目越来越复杂，不能用一个简单的Project来表示。但我们认为，过于区分二者的差别，在很多地方逻辑上说不通。所以，我们在全书中，一般把Program译作项目，而不译作项目集。只有在特别说明各类项目级区分标准时才译作项目集。此次翻译也对Trade-off作了一点变通处理。在项目前期，特别是商务论证中，用机会成本分析更确切些；但在项目展开后，它表示的是时间、成本、质量（绩效、客户关系）三角或多角度间的平衡分析。
作者经常提到，在解决项目问题时，可以使用高薪员工。他暗含的是，所有高薪员工一定比低薪员工的能力强，可以加快进度并提高质量。也许作者更多的是从项目成本管理的角度来看待人力资源的。为了保持作者的本意，我们多用了“高薪员工”一词，只有个别地方为了兼顾前后文的内容，使用了“技术能手”或“技术专家”。
关于这一版本与第 11版的更新内容，作者在前言中特别作了专门介绍。读过以前版本的读者，可先认真读一下作者前言。
这个版本的重译是在第11版中译本的基础上完成的，所以对参与第11版翻译的主要贡献者表示感谢，也对参与本书第7～10版的译者表示感谢。他们的努力为本书奠定了很好的基础。
第12版的译者分工如下：前言、第1～8章（杨昌雯、杨爱华）；第9～17章（王丽珍）、第18～21章及所有附录（杨婧）。杨爱华统校了全书。
尽管此书在1998年年底与我结缘（当时在美国做访问学者，从一个月只有100美元的伙食费中省下65美元购买了此书），但真正引领我走上项目管理翻译和教学道路的是我的导师——北京航空航天大学经济管理学院的邱菀华教授。从 1995年冬天开始跟她读在职博士的22年来，她的教诲伴随着我的成长。在此向邱老师表示衷心感谢。
本书的主要术语尽量与《项目管理知识体系指南》（PMBOK®指南）（第6版）（此书已由电子工业出版社出版。——编者注）的术语统一。
这次的更新版，科兹纳博士为了配合 PMP认证考试，进一步细化了每章每节每段中与《项目管理知识体系指南》（第6版）相对应的重点内容，在章尾更新选择题和参考题，使得本书既可作为各类学习项目管理知识体系的教材，也可作为 PMP考证备战的理想工具书。
科兹纳博士是美国人，他的项目管理经验是美国式的。如果项目管理专业的教师使用本书授课，对书中提出的问题可以做些变通，结合中国的国情，用中国人的思维和习惯来处理。有些调查数据资料，在引用和向学生介绍时，一定要说明出版情况及背景，以免发生误导。
成功的项目就是在一定的时间内、花可能花的钱、整合资源、冒着风险去办一件大家都满意的事。翻译工作也是如此。译著中如有词不达意之处，祈盼读者多多指正。杨爱华yangah@buaa.edu.cn北京航空航天大学公共管理学院前 言
项目管理原本被当作一种局限于某些职能领域的经营理念，而且仅被人们看成对某些事物有作用的方法，如今却已经演变为影响公司所有职能部门的企业管理体系。简单地说，项目管理已经不再是一个项目的管理过程，而发展成一个企业的业务流程。越来越多的公司已经把项目管理作为公司生存的必要手段。那些曾经与项目管理唱反调的组织，如今却开始提倡项目管理理念。早期的管理教育学者曾经认为项目管理起不了什么作用，它只是一股短暂的热潮，如今他们却变成了项目管理理念的忠实拥护者。项目管理就这样发展起来了。现在一些理工院校和综合性大学都为项目管理设置了专门的本科和硕士课程。
本教材的适读人群很广泛，不仅包括希望提高项目管理技能的本科生和硕士生等学生群体，也包括项目投资方的部门经理和高管们。经过多年的发展，管理学的知识和项目管理理念已经发展得相当成熟，几乎所有的企业都以不同的形式运用项目管理。由于这些公司已经意识到生产效率与项目管理息息相关，也开始把商业活动切分成一系列的项目。公司也为项目管理培训课程划拨了比过去更多的培训经费。
本书为工程师们提供了项目管理的总体参考，但读者不要以为项目管理只与工程相关。书中提供了一些工程案例，只是因为事实上项目管理最先出现在工程领域，我们应该从中吸取经验教训。如今项目管理存在于各个专业领域，包括信息系统、医疗保健、咨询、制药、银行和政府机构。
本教材适用于工商管理、信息管理、工程管理的本科或硕士课程。项目管理是人为管理而不是工具计算，意味着它是一门行为科学而非数理科学。基于我对项目管理理念的个人理解，对本书的结构进行了重新规划。前7章是涉及项目管理理念的最基础、最核心的知识点，特别是美国项目管理学会（PMI）的“项目经理的基本三素质”。第8～10章讨论支持职能，阐述预测项目成功的因素，以及管理层的支持。也许你会感到疑惑，为什么在三大核心内容，即规划、进度计划和控制章节之前需要用 10章的篇幅讲解组织行为和结构？原因是这 10章可以让读者更好地理解所有类型的项目和流程系统的背景环境、文化环境。这些章节有助于读者了解以下内容：团队成员同时参与多个项目合作的困难，以及为什么人们要参与到项目中来；参与项目的人有着不同的背景，不可能毫无摩擦地凝聚在一个工作群体中。第11～20章是比较定量的内容，包含了项目规划、进度计划、成本控制、预算、商务合同（含采购合同）和质量。第21章集中介绍了当代项目管理的前沿话题。
第12版做出改动的内容包括：（1）更新了项目管理概述的内容（2）更新了竞争约束条件的内容（3）新增了项目经理的三个素质（4）新增了初级项目经理的项目管理（5）新增了技术类项目管理的知识（6）更新了项目成功的一些因素（7）新增了项目管理架构调试的方法论（8）新增了导致项目失败的一些原因（9）新增了项目成功或失败的程度（10）更新了知识管理和数据库（11）更新了项目管理的知识产权（12）新增了利益增收和文化变迁（13）新增了转型中的项目领导（14）更新了大型项目管理的内容（15）更新了敏捷项目管理的内容（16）新增了敏捷的和适应性的项目管理文化（17）更新了跨国项目管理发起的内容（18）新增了如何准备项目商务案例（19）更新了项目假设的验证（20）更新了项目目标的验证（21）新增了项目生命周期里程碑的内容（22）新增了项目管理办公室的内容（23）新增了项目组合管理的内容（24）更新了项目最佳实践的内容（25）更新了资源水平颁布的内容
本教材包括案例分析、多选题和简答题等多种题型。另有一本案例分析集——《项目管理案例集》（第5版）（Project Management Case Studies，5th Edition），提供了更多的真实案例。以下是案例分析集的部分新增案例：续表
第12版、《PMBOK®指南》和《项目管理案例集》是准备PMP®资格考试的最佳自学教材。因此，本书每章末尾都会详细列出《PMBOK®指南》和《项目管理案例集》中相应的引用部分。在本书每小节标题的左侧空白处，有相应的侧栏框明确列出该节内容对应《PMBOK®指南》的哪些知识点，以便学习。基本上每章末都有专门关于PMP®考试考点的学习指导。
本教材目前被用于大学教学、参考资料和PMP®资格考试培训多种市场。因而，为了满足各类市场的需要，同时确保内容不会过于冗长，本书在与《PMBOK®指南》的联系程度和包含多少不相重复的新内容之间进行了折中。部分院校单独使用本教材教授项目管理基础课程，没有参考《PMBOK®指南》。本教材并没有涵盖《PMBOK®指南》的所有内容，因此，要参加PMP®专业资格考试的话，必须将《PMBOK®指南》与本教材配套使用。本教材涵盖了《PMBOK®指南》几乎所有的重要知识点，但并没有达到《PMBOK®指南》的深度。
本教材对应的教师指导书仅供大学院校的教职人员使用，可通过联系当地Wiley教育出版社销售人员或者登录Wiley官方网站（www.wiley.com/kerzner）订购。此教辅资料的版权归属John Wiley & Sons教育出版社，并非本书作者。
如需使用本教材进行项目管理1～3天短期研讨会或PMP®专业培训，可联系国际学术协会的执行副主席 Lori MIlhaven，电话号 800-325-1533，分机号 5121（邮箱地址：lori.milhaven@iil.com）。
每章结尾的思考题及案例分析涵盖了不同行业。这些实例全部来源于我做顾问时收集的实例和专业的调查研究课题报告。使用过以前版本教材的同行们给我提供了众多的建议，这些建议中的大部分都吸收到了第12版的修订中。
编写前 11章，我参考了大量的经典项目管理文献，这些文献奠定了许多现代项目管理发展的基础。本书对这些文献的引用都给出了明确出处。
许多同行提出了很好的批评建议。我特别感谢帮助本版做出重大改进的行业或政府机构的培训经理们，他们为提高项目管理教育与培训的质量做出了重大贡献。还要特别感谢国际学习研究院的首席顾问兼培训专家弗兰克·塞拉迪斯先生（PMP），他提出了许多富有建设性的意见、推荐并帮助绘制本书中涉及的PMBOK®指南的图表，建议本书相关章节随指南修改而如何调整。我也要特别感谢埃德蒙德·孔若（Edmund Conrow）博士（PMP），10年多来，他协助我准备了书中所有有关风险管理的章节。同时，还要感谢雷内·兰登（Rene Rendon）博士对如何修改合同管理的章节提出的评论和建议。
我再次向国际学习研究院的员工和管理团队致以感谢，25年来他们所给予我无尽的鼓励、支持和帮助，已经融入了我所有的项目管理研究成果和著作中。哈罗德·科兹纳国际学习研究院第1章概述引言
在美国，追根溯源，项目管理产生于20世纪60年代的重工业和国防部（Department of Defense，DOD）。项目管理的早期着重于项目的预算和进度，主要应用在一次性独创任务的完成，偶尔也用在重复性任务中。为了项目管理标准化和监控正在实施的项目，DOD创立了相关的监控项目的制度、流程以及项目进展报告的方法。
早年间，项目管理只是一种兼职工作，并不是一个正经的职业职位。在许多企业中，项目管理并不重要，很难得到全公司的支持。
后来，管理层才开始逐渐地意识到资源统筹的复杂性和项目的效率等问题。与此同时，科技和市场日新月异，公司或机构的组织形式也千变万化。传统组织结构官僚主义严重，很难快速应对这种环境变化。因而，传统的组织形式被项目组织形式或其他短期临时性的组织形式替代。这些替代的组织形式不仅结构上高度紧密结合，而且能快速应对企业内外部不同程度的事态发展。现在，项目管理实践积累的这种结构优势允许项目经理根据不同的项目环境选择相应的管理工具和流程。
项目管理理念被接纳并非易事。许多高层管理人员不愿接受改变，他们固执地不愿接纳应对不同管理环境采取灵活的组织结构的观点。其原因和项目管理的模式有关。项目管理的模式是打散传统商业结构上级领导下级的垂直层级关系，本质上确保上层具有强力集权的传统模式被打破。大部分高管坚信这个垂直的领导关系才是公司管理运行模式的正道，因而他们拒绝去了解也拒绝承认项目管理理念会给公司带来益处。
但残酷的经济环境迫使这些高管重新考虑项目管理给公司带来的价值。最为突出的几次经济环境的恶化是：20世纪70年代末期和90年代初期的经济萧条，2008年的次贷危机，2013年、2014年的欧洲经济衰退，2015年的世界经济停滞。这些恶化的经济环境增加了对有限资源合理规划的需要，要求我们通过项目组合给公司创造最大的价值，并提升项目的成功率。显而易见，项目管理可以满足以上所有需要。其实，无论市场经济条件是好是坏，项目管理都是必要的。现在，项目管理理念已经被运用于各行各业，如国防、建工、制药、化学、银行、医院、会计、广告，法律及各级政府部门，甚至联合国。
现在，绝大多数高管都相信项目管理可以使工作完成得更好。项目管理已经延伸到企业的方方面面而非仅仅被用于企业的某些部门。现在的项目管理已经与企业的战略目标和宏观目标紧紧结合在一起了。简而言之，再傻的人也不会去做与战略目标不相符、不会带来价值的项目。在某些类似IBM、微软、惠普的公司，项目管理被当成企业生存和战略实现的必要手段。项目管理在企业生存和发展中越来越重要，这一认知如今已经渗透到不同领域、不同规模的各色企业中。1.1 理解项目管理
为了理解项目管理的含义，首先要理解项目的定义。一个项目可以被看成具有以下特征的一系列活动和任务：
• 有一个在特定计划内要完成的具体目标。
• 有确定的起始日和终止日。
• 有经费限制（如果项目可以实施的话）。
• 消耗人力和非人力资源（如资金、人员、设备）。
• 多职能（如横跨几条不同部门的职能线）。
项目的产出或成果可能是独创的，也可能是重复的。但项目必须在规定的时限内完成。由于企业的资源是有限的，因此企业应该把重心放在已有项目的正确组合上。在此要求下，我们也发现了项目的另一个结果，就是项目必须给企业带来价值，带来经济利益，而非做一个“米虫”，只知道吃米，没有有效产出。
另外，正如《PMBOK®指南》中所定义的那样，项目管理包括五个过程组。
• 项目启动
— 在现有资源条件的限制下选择最佳的项目。
— 确认项目的收益。
— 准备项目许可所需的文件。
— 任命项目经理。
• 项目规划
— 确定各项任务的要求。
— 确定各项任务的质量和数量。
— 确定各项任务具体所需资源。
PMBOK®指南，第6版
第1章 项目管理简介
1.2.1 项目
1.2.2 项目的重要性
1.2.4.5 项目管理过程组
— 制订活动的时间计划。
— 评估各种风险。
• 项目执行
— 为获取项目团队成员谈判。
— 指导和管理工作。
— 同项目组成员共同工作，帮助他们成长。
• 项目监控
— 跟踪项目进程。
— 比较实际产出和计划产出。
— 分析偏差和影响。
— 做出调整。
• 项目收尾
— 工作收尾：检查所有的工作任务都已完成。
— 业务收尾：合同完成的确认。
— 财务收尾：确定项目的最终支出。
— 管理收尾：完成文书工作。
因此，成功的项目管理可以被定义为结合一定时间和成本，达到一连串的项目规定的性能或技术水平，高效有力（时间效率和质量）地整合被分配的资源，最终成果被客户或权益方认可。由于项目原本就是不同的，不同客户的要求也是不同的，项目流程中具体的组成活动也是不一样的。《PMBOK®指南》给出的是最完整、最详尽的项目流程。在实操中，通常根据项目所需量身定做，选取必要的活动形成流程，最终制定一个可以实施的项目管理办法。
有效项目管理的潜在优点：
• 明确岗位职责，无论人员如何变动，保证所有的活动都在计划中。
• 缩小对持续汇报的需求。
• 明确项目进度计划的时间限制。
• 明确平衡分析的具体方法。
• 对计划完成情况有准确衡量。
• 尽早明确项目的各项问题，以便问题发生时可以采取正确行动。
• 提高对未来计划的预测能力。
• 知道何时目标无法实现或将超额完成。
但是，这些优点只有在克服以下困难后才可实现：
• 项目的复杂程度。
• 客户的特殊需求和范围的变化。
• 组织重构。
• 项目风险。
• 技术变化。
• 将来的规划和价格。
项目管理的设置是通过企业内部横向和纵向的工作流程更好地配置和使用企业现存资源。这种模式并不是直接打破传统的纵向管理模式，而是简洁地要求各职能部门相互横向交流。通过组织内部横向和纵向工作流程的共同运作，使整个组织的工作协调完成。在这种模式中，部门主管依然对纵向工作流程负责，而项目经理则要对横向流程负责。也可以说，项目经理的首要任务就是横向协调各职能部门之间的各项活动。
PMBOK®指南，第6版
3.4 项目经理的能力
图1-1显示了许多公司是怎样组织的。不同的管理层级之间总是存在“层级和威望”的鸿沟。在组织中，各个工作包之间也存在职能鸿沟。如果我们把横向的管理鸿沟叠加到纵向的职能部门鸿沟上，就会发现公司被分割成一个个拒绝相互沟通的孤岛。这些独立的业务组织担心信息共享会增强对手的实力。项目经理的职责就是促使这些孤岛进行交叉协作和交流，从而达到整个组织的共同目标。图1-1 组织的鸿沟
项目经理与不同业务孤岛合作时使用的技能组合也是不同的。《PMBOK®指南》明确了项目经理的三项基本能力是技术项目管理、领导力、战略和商务管理。在如今的大环境中，战略和商务管理越来越成为焦点，原因是现代项目需要从项目本身的专业层面和企业战略目标两个角度思考并做出决策。
以下是对项目管理的总体定义：
项目管理是为一个已经设置好的相对短期的目标（这个目标包含具体的重点标杆和目标值）去计划、组织、指导和控制公司的资源。进一步来说，项目管理就是利用系统化、流程化的管理方法，将各职能部门的人员（纵向垂直体系）安排到一个具体的项目中（横向水平体系）。
以上定义还需进一步解释。我们通常认为传统项目管理具有5个方面的职能和原则：
• 规划。 • 控制。
• 组织。 • 指导。
• 人员配备。
PMBOK®指南，第6版
2.4 组织系统
你会发现，上面的项目管理定义忽略了人员配备职能。这样定义的根本原因在于，项目经理不为项目配备人员，人员配备是部门主管的职责。项目经理有权要求具体资源，但最终什么资源可被使用还是取决于部门主管。
我们还要分析“相对”短期的含义。不同产业对短期项目的定义不尽相同。在工程领域，“短期”也许是6个月或两年；在建筑业，也许是3～5年；在核电装备制造业，也许是 10年；在保险业，则可能只是两个星期。长期项目需要专职人员，通常需要建立独立的项目管理部门（如果项目足够大的话）或新设置一个垂直体系上的部门。
图1-2形象化地表现了过去对传统项目管理的理解。如图1-2所示，项目管理的设置实际上是为了在有一定时间、成本、绩效要求的指定活动中，管理或控制公司资源。其中，认定了时间、成本和绩效是项目仅有的约束因素。如果项目是为外在客户完成的，那么又有了第四个约束因素：良好的客户关系。客户可能是母公司的子公司，也可能是其他外部公司。读者也许会很快意识到，如果只注重在一定的时间、成本和绩效约束下管理项目，而在一定程度上忽视客户关系，就不会有下一单生意了。高管会根据客户是谁和需要怎样的客户关系来选择项目经理。图1-2 项目管理示意图
项目的存在是为了生产出可交付成果。根据项目可交付成果的大小、类型和范围最终任命恰当的项目经理。可交付成果是在项目结束时或项目一个生命周期结束时的产出品或最终结果。可交付成果是可度量的、看得见摸得着的产出品，可能包括以下几种形式：
• 可交付的硬件。就是一些硬件产品，例如，一张桌子、一个样品或设备的一个零部件。
• 可交付的软件。与可交付硬件相似，但它们通常是纸质产品，如报告、论文、新闻稿或者文件。有些公司并不区分可交付的硬件与可交付的软件。
• 可交付的软硬件。这些产成品可以是可交付的硬件，也可以是可交付的软件。而且，随着项目进行逐步演变成最终形态。例如，企业一系列季度报告汇总为企业年报。1.2 定义项目成功
PMBOK®指南，第6版
1.2.6.4 项目成功标准
在前面的小节中，我们将项目成功定义为在一定的时间、成本和绩效约束条件下完成一个活动。这个定义已经沿用了三四十年。今天，项目成功的定义已经有了细微的改进，增加了以下完工条件：
• 在被分配的一定时限内。
• 在预算好的一定成本下。
• 要达到适当的性能和规格水平。
• 得到客户或使用者认可。
• 尽量减少范围变化或者在范围变化上达成共识。
• 不影响组织的主要工作流程。
• 不改变企业文化。
最后三个因素需要进一步解释。只有极少数项目是在原有的项目范围内完成的。范围变化是不可避免的，它不仅可能打击项目组成员的士气，甚至可能破坏整个项目本身。必须尽可能地缩小项目范围的变化程度，同时，一定要保证项目经理和客户都认可这些必要的变化。
项目经理必须主观上愿意在管理中不改变公司的主要工作流程（如果需要的话，可做出让步或交换）。大多数项目经理在项目启动后自立为王，把自己看作独立经营的企业家，喜欢将其项目从母公司的运作中分离出来（这种模式的可行性有待商榷）。一般情况下，项目经理必须主观上愿意在其母公司的方针、政策、程序、规章和指导下进行管理。
所有公司都有自己的企业文化，尽管每个项目都有其固有的特点，项目经理不应期望他所被分配的职员游离于企业文化之外。如果公司在对待客户方面有一个开放和诚实的准则，那么无论客户是谁，也不论项目经理对成功的渴望有多强烈，所有项目都要保有开放诚实的文化价值。
最后需要指出，一个项目的成功并不意味着整个公司在项目管理上取得成功。项目管理成功是指连续取得不同项目的成功。因为，任何单一项目在正式授权和强大的行政干预下，都可能被带向成功。连续的项目成功则需要公司对项目管理理念有一个强有力的认可，而且这种认可必须是显而易见的。1.3 机会成本分析和竞争的制约因素
尽管有很多项目完成得很“成功”，至少在权益方眼中是这样的，但是，由于机会成本的存在，项目最终的成功衡量标准与最初的成功衡量标准不尽相同。机会成本是指为了得到某种东西而所要放弃另一些东西的最大价值；也可以理解为在面临多方案择一决策时，被舍弃的选项中的最高价值者是本次决策的机会成本；还指厂商把相同的生产要素投入其他行业当中去可以获得的最高收益。
图1-2中的三角图形是项目三重制约因素的经典模型，说明了时间、成本、绩效是项目的制约因素，其中绩效可以定义为范围、质量或技术标准。这些制约因素不仅被定义为主要的制约因素，也常常被当作衡量项目是否成功的标准。
如今，我们已经意识到项目成功的标准有多元制约因素，而不仅仅是理论性的三重制约因素，因此，我们将关注点转移到竞争性制约因素上。有时，制约因素还被分为主要的制约因素和次要的制约因素。次要的制约因素包括项目风险、客户关系、企业形象、企业声望等，这些次要的制约因素可能影响决策者偏离最初关注的成功标准，如时间、成本和绩效。这些变化会贯穿项目的整个生命周期，因而要在三角约束模型中进行机会成本分析。因此，就可能对成功标准做出调整。在理想的状态下，我们需要对任何一个或所有的竞争性制约因素进行机会成本分析，只有这样才能获得满意的成功验收标准。
举一个例子，假设一个项目最初的成功标准是图1-3中的三重制约因素。为简单起见，图1-3使用了一个三角模型来说明三重制约条件。然而，项目的制约因素可能更多，不能简单地使用三角模型，用其他的几何图形（四边形、五边形之类）可能更为精准。随着项目的进行，环境逐渐发生改变，如一个有自己独立目标计划的新的高级管理团队的加入或者一个会导致公司的信誉受损的新的公司危机的出现。这种情况下，图1-3右边的三角模型中的制约因素就可能比最初的制约因素更重要。
次要的制约因素也是制约因素。有时，这些次要因素比主要因素还要重要。如多年前，项目经理们在迪士尼乐园和迪士尼度假区各个主题公园内设计并建造了许多著名的旅游景点，他们主要考虑以下六个制约因素：
• 时间。 • 安全。
• 成本。 • 审美价值。
• 范围。 • 质量。
在迪士尼的项目中，后面三个制约因素（安全、审美价值、质量）被认为固有的不可替代的制约因素，在进行机会成本分析时要锁定这些因素，不能改变。所有的取舍替代只能在时间、成本及范围三个因素上进行。有的制约因素不可改变，而其他制约因素则可变通。图1-3 竞争性制约因素
所有制约因素的重要性并不相同。如在项目的启动阶段，范围是最重要的制约因素，因而可以对其他因素如时间和成本进行机会成本的平衡分析。在项目执行阶段，时间和成本因素变得更加重要，因而可以对范围进行机会成本的平衡分析。关于机会成本的平衡分析更详细的讲解在第16章可以找到。1.4 初级项目经理
经常发生这样的情况，人们在追逐项目管理岗位时，并不知道这份工作具体需要什么技能素质。有些人认为，成为项目经理后被授予极大的权限，可以决定项目的任意方面。对内，他们可以拥有自己的小“领地”，控制自己雇用的员工；对外，连接公司内外部的接口。
事实上，项目经理和某些人的想象大相径庭。大部分项目经理并无实权，权利权限都在投资人和部门主管手中。某些人称为项目经理，实际上就是无实权的领导。
项目经理们对聘用员工没有话语权，他们甚至无权裁退表现差的员工。绝大多数项目组成员是由部门主管指派的，而这些人也只接受所属部门主管的调遣。项目经理没有权限左右被分配到该项目中的团队成员的薪酬待遇。被指派到这个项目的组员可能同时在参与多个项目，因此项目经理不能强求这些组员单单为了满足这一项目的要求条件而进行时间安排。项目经理也没权雇用和借调公司外部的劳动力，只有投资人有这个权限。
一般情况下，项目经理应该对企业的商业模式及与项目管理匹配的企业业务流程有一个大略的了解。必要时，项目经理也可以对与项目相关或与企业业务相关的事务做决策。
有些人认为，项目经理是项目的最终决策者，可以对项目的方方面面做出任意决策。这显然不是事实。在现如今的高科技环境下，项目经理不可能是所有领域的专家。他们的专业知识有可能无法涵盖到项目所在领域。这在以高新科技为基础的项目中尤为常见，如1.5节所讨论。因此，项目经理必须依赖监管委员会和项目组成员共同决策项目问题。
项目经理对项目强制附加的限制或项目的边界条件也没有话语权。这些限制条件可能是在竞争招标环节客户和企业销售部门协商好的，然后直接告知项目经理，因此项目经理只能接受这些限制条件。这种情况并不罕见，经常是销售部门为了赢得业务合同自行同意不切实际的预算和时间要求，然后直接跟项目经理甩一句“这是从客户那儿所能要到的全部资金和时限，忍着吧”。
最后，一个初级项目经理不能理所当然地认为他对参与者的角色有了全方位的理解。因为，项目各不相同，所有参与者的职能和权限以及伴随着的相互之间的关系都可能变化，这在1.6～1.10节中有所讨论。
在不同的企业中，相同项目的特征也是会变化的。在接受项目经理这个职位前，初级项目经理作为新人有必要对工作需求有所了解。1.5 项目经理的三种基本技能
PMBOK®指南，第6版
3.4 项目经理的能力
因为每个项目本来就不相同，所以项目需要的技能组合也不相同。PMI引入了一个“能力三角形”代表现在被大型跨国公司认可的项目经理所需的高阶技能群，这三种技能：
• 技术项目管理。
• 领导力。
• 战略和商务管理。
在各种项目、项目集和项目组合的管理活动中，这三种技能的组成部分是可以改变的。本节只是简要提出项目的技术管理能力和领导能力，本书后文会有更加深入的讨论。第三种战略和企业管理能力对许多项目经理而言相对新鲜。在一些企业中，战略层面和企业层面的决策都是由投资人单独做出的。在这种情况下，项目经理的主要任务就是制造产品或完成项目要求，这极有可能只是一个技术性的成果。而怎么使用这个成果以及成果是否会为企业带来商业价值对项目经理而言犹未可知，它是投资人所要负责的部分。
现今世界，项目经理必须以企业战略和企业目标为导向。今天的项目经理不仅仅是单纯地管理一个项目，他们也不应该把自己的管理再局限在一个项目中，而应该视之为管理企业的一部分。因而，他们应该从专业技术和企业战略两个层面来考虑问题。项目经理使用的各种工具，特别是项目管理方法论已经被潜移默化地嵌入了企业的各个流程，而不单纯是企业的管理流程。
商业价值一词将会变成项目经理口中的最重要词汇。项目的成果不再是一个简单的完成品，而是可以不断创造商业价值的载体。项目的成功也不再是单纯地完成某些既定要求，而是创造连续带来正现金流的永动机。本章我们都会特别注意价值的重要性，这个趋势还会愈演愈烈。1.6 技术类项目
PMBOK®指南，第6版
3.4.2 技术项目管理技能
技术类项目是所有项目中最难管理的，特别是对于初级项目经理简直就是一块硬骨头。技术性强的项目相当复杂，需要创新，而且和传统领域的项目相比，风险也更大。并且处理这类项目出现的问题需要通过实验或试验，各种迭代方法，还需要创新能力。正如Hans Thamhain所说：
在我们生活的这个紧密关联的世界，大多数项目经理一定会面对技术问题，特别是那些就职于科技公司或是以技术制胜的公司的项目经理们。因此，这些项目经理接触的项目会充斥着科学技术。基本上，工业和政府的每个部门都尽力通过科学技术来提高效率，增加价值，加快速度。传统的直线性工作流程和自上而下的等级控制已经不能满足现今的需要，会逐步被更加新颖灵活的技术、更具优势的组织形式和相适应的企业流程所取代，例如，并行工程、施工总承包、门径管理和以客户为中心的组织。这些组织形式让企业更好地应对部门交叉整合、资源流动配置、项目效率和市场反应，但它们也需要相适应的更精妙的技术支持，从而有效处理当代大规模的技术和社会的双重挑战，例如更强的冲突、更大的变化、更高的风险、更多的不确定性、从职能功效向流程整合功效的转移、强化组织整合、更复杂的人力因素，以及总体业务流程。总而言之，技术类项目有以下特点：
• 应用技术创造价值。
• 对技术革新和创新的强烈需求。
• 激烈的竞争、开放的全球市场。
• 资源有限、时间紧迫、质量要求高。
• 要求员工高学历、技能熟练、知识技能涵盖范围广。
• 需要专业的技术知识和能力。
• 需要较强的人际关系处理能力，跨组织、跨文化工作的能力，以及处理组织冲突、权限和行政规范的能力。
• 复杂的项目组织形式和跨部门联系。
• 烦琐的业务流程和复杂的相关方沟通。
• 技术被用于做管理的工具。
• 用技术代替劳动。
• 先进的基础设施。
• 在产品生命周期前期支出较大。
• 项目初期投资较大，并且短期利润率很低。
• 市场变化迅猛，技术和规范都在不断改变。
• 激烈的全球竞争，开放的市场和很低的市场准入门槛。
• 产品较短的生命周期与市场的快速反应速度。
• 需要快速的市场反应。
• 复杂的决策流程。
• 许多合资、联盟和伙伴关系需要处理。1.7 项目经理和部门主管如何协作
PMBOK®指南，第6版
3.4 项目经理的能力
我们已经提到，项目经理必须在一定的时间、成本和绩效下控制公司资源，大多数的公司有六大资源：
• 资金。 • 厂房设施。
• 人力资源。 • 原材料。
• 设备。 • 信息或技术。
事实上，除了资金有可能受到控制（例如通过预算），项目经理并不直接控制任何资源。资源掌握在职能经理或直线经理（我们把他们统称为部门主管。但根据约定俗成的原则，为了上下文的语境，我们大多时候用了职能经理。——译者注）手中，也可称他们为资源经理。因此，项目经理常常就项目全部所需要的资源与部门主管进行协商。当我们说项目经理掌控项目资源的时候，其实际意思仅指项目经理在项目进程中，通过各部门主管掌控分配给其的资源。
如今，项目经理的职能已经得到了升华，转变成一种新的项目经理人。以前，几乎所有的项目经理都是学究式的工程师，他们把项目管理的种种方法当作一个强制的指令，而极少去理解其本质。而部门主管在得知项目经理是为了履行各种流程指令时，就会让相关的部门员工短期内受项目经理直属领导。因而，从结果上看，项目经理是可以控制项目组成员的。
而现在，大部分的项目经理只需要了解技术而无须自由运用技术。而且，现今项目成败的责任由项目经理和所涉及的全部部门主管共同承担。在分责制下，部门主管也要一定程度上了解项目管理，这也是为什么越来越多的部门主管开始考 PMP资格证书，成为注册项目管理专业人士的原因。相对地，项目经理被期待集中一切精力在项目成果上，而不是为项目成员提供技术指导。对所分配的资源进行管理往往是一种直线职能。
另一个重要的事实是对于项目经理来说，他们不仅仅是管理一个项目，更要管理一部分业务，并且需要对项目本身及整个业务做出合理的决策。因此，项目经理必须要懂得经营方针。将来，项目经理可能通过PMI的认证从外部确定，还可以通过公司的组织业务流程从内部确定。
近些年，技术的飞速发展迫使项目经理更加以业务为导向。
基于以上分析可以明显指出，成功的项目管理非常依赖于：
• 项目经理和分配相关资源的职能经理日常关系良好。
• 项目成员具备垂直关系上向部门主管汇报，水平关系上向一个或多个项目经理汇报的能力。
以上两点非常关键。在第一点中，被分派到项目经理麾下的部门员工在专业技术上还是要听从部门主管的指导。在第二点中，向多个经理汇报的员工最重视的还是能管他们工资收入的领导。因此，大部分职员还是仰仗部门主管的鼻息来工作的。
细看下来，在项目管理中是项目经理为部门主管效力，而非反向的。很多管理者没有意识到这一点。他们总是趋向于给项目经理头顶加个光环，在项目完成时嘉奖项目经理，而事实上，有部门主管一大部分功劳，因为他们才是顶着压力为达到项目约束而运用手头资源的人。项目经理只是项目完成的经手人。那么，为什么许多企业如此看中项目管理？
如果项目经理与部门主管关系恶化，项目绝对会变糟。高层管理人员一定要为两者创建良好的工作关系。一个很常见的破坏这种关系的方式是询问：“项目经理和部门主管谁对利润做的贡献大？”项目经理认为他们控制了整个项目利润，因为他们控制着预算。另外，部门主管则认为他们必须根据预算合理地安排人员，在要求的时间内提供资源，并监督实际操作。事实上，垂直线的工作和水平线的工作都为利润做出了贡献。这类冲突可能破坏整个项目管理体系。
高效的项目管理需要管理者熟悉定量工具、专业技术、组织结构和组织行为。
大部分项目经理都了解有关计划、进度和控制的量化工具，但他们必须对全部组织部门的运作有所了解。此外，项目经理还必须熟悉自己的工作内容，特别是职责描述中的权限范围。
组织行为是很重要的，因为处于直线和职能界面上的部门员工发现，他们要对不止一个领导汇报工作：一个部门主管，另外是每一个他们所参与项目的项目经理。管理人员必须提供适当的培训以使员工能够有效地向多个经理汇报工作。1.8 定义项目经理的角色
PMBOK®指南，第6版
2.4.3 管理要素
第3章 项目经理的角色
第4章 项目整合管理
项目经理负责对横跨多个不同部门职能线的活动进行协调和整合。由项目经理进行的整合工作包括：
• 整合构建项目计划所需的各项活动。
• 整合执行项目计划所需的各项活动。
• 整合进行项目范围变更所需的各项活动。
这些整合责任如图1-4所示，项目经理必须把各项投入（如资源）转变为产品产量、各类服务和最终利润。为了做好这些工作，项目经理需要强大的沟通和人际交往能力，同时必须要熟悉每个纵向职能部门的工序和业务，并必须具备与项目相关的技术知识。
PMBOK®指南，第6版
第4章 项目整合管理
一位计算机制造业的高层管理者说，他的公司正向外部寻找项目经理。当问及他是否希望候选人具备计算机的操作技术时，高管说：“你给我一个沟通能力强并且具有协调人际关系技巧的候选人，我将给这人一个职位。我能教某人技术，派给他技术专家辅助他做决策。但我不能教某人如何与他人合作。”图1-4 整合管理
项目经理的工作并不那么简单。项目经理的职责可能不断增加，但没多少职权。这种权力缺乏迫使项目经理为控制公司资源不得不与更高层的管理者和部门管理人员“谈判”。因而项目经理常常被看作正式组织的局外人。
在项目环境中，每件事都好像要让项目经理左思右想。尽管项目组织有专业分工并以任务为导向，但它也不能与传统组织结构分离存在。所以项目经理必须跨越两组织间的樊篱。专业术语“整合”就是来描述项目经理的这种作用的，该作用可被描述为管理以下几种关系：
• 项目团队内部关系。
• 项目团队和职能部门之间的关系。
• 项目团队和高管之间的关系。
• 项目团队和客户组织（包括公司内部的客户和公司外部的客户）之间的关系。
项目经理实际上是一位总经理式的人物，他要了解公司全部的运作。事实上，项目经理比大多数高管更了解公司整体的运作情况，这就是为什么项目经理职位总被当作培训基地为企业储备具有高端能力的未来高管。1.9 定义职能经理的角色
PMBOK®指南，第6版
第9章 项目资源管理
9.3 资源获得
假设项目经理和职能经理不是同一个人，我们可以明确职能经理的特殊作用。这种作用有3个因素：
• 职能经理有责任规定任务如何完成及在哪里完成（如技术标准）。
• 职能经理有责任在项目限定范围内提供充足的资源来完成目标（如谁将完成工作）。
• 职能经理对可交付成果负有责任。
换句话说，一旦项目经理明确了项目的各项要求（例如，什么工作必须做，约束是什么），那么就轮到职能经理负责确定技术标准。大致上除了研发领域，职能经理应该是所处部门公认的技术专家。如果职能经理认为项目经理确定的某部分要求在技术上不合理，那么他有权根据他的专业提出异议，并请求更权威的人士来支持他的观点。
在1.1节中，我们曾提到职能经理控制所有的资源（包括人力资源），项目经理有权要求特殊的人员配置，但最终决定权在职能经理手中。这有助于项目经理理解职能经理的难处：
• 无限度的工作要求（尤其是在竞标时）。 • 预料之外的进程受阻。
• 事先确定的最后时限。 • 计划外的资源缺失。
• 所有需求都有高优先权。 • 计划外的资源中断。
• 资源数量有限。 • 计划外的资源损失。
• 可用资源有限。 • 计划外的人员流动。
• 项目计划的进度有变。
只有在极少数行业里，项目经理可在项目开始时提前从职能经理那里知晓有哪些可用资源。对项目经理来说，能否使用最佳资源并不重要。职能经理无法保证特定人员一定有时间。而且，职能经理还要保证自己负责的那部分项目，在有限成本下按时出成果，甚至有时候，要使用较低技能水平的员工。如果项目经理对分配的组员或资源不满意，他要自己去验证。只有项目经理有证据表明职能经理提供的各项资源实在不可接受，才会向职能经理要求更好的资源。
事实上，任命一个项目经理并不能减轻职能经理所承担的责任和压力。如果职能经理分配给项目经理的资源达不到要求，那么他们都将受到惩罚。有些公司甚至考虑根据绩效增长及对项目经理遵守诺言的程度作为职能经理晋升的标准。
因此，承诺透明化对相关的每一个人都很有价值。
项目管理被设计成由项目经理和职能经理分享权力和职责。项目经理计划、监督、控制项目，相对的职能经理实施资源配置。表1-1说明了这一职责分工。表1-1的例外情况
PMBOK®指南，第6版
2.4.4 组织结构类型是项目经理和职能经理是同一个人。这种情形并不少见，它会导致利益的冲突。如果一名职能经理要将资源分配给6个项目，其中1个项目归其直接控制，那么他很可能将最好的资源留为己用。在这种情况下，他的项目就会在开支方面优于其他几个项目。图1-1 职责分工
PMBOK®指南，第6版
2.4.4 组织结构类型
在盛行向多个领导汇报的项目管理模式中，项目经理和职能经理的关系至关重要。表 1-2说明了项目经理和职能经理的关系并非总能平衡。当然，这与谁对所任命的职能员工有更大影响有关。图1-2 报告关系注：*这种组织结构将在第3章中论述。1.10 定义职能员工的角色
一旦职能经理对产品负责，被他任命的职能员工就有责任完成职责任务。
在大多数组织中，即使被任命的员工同时正在处理几个项目，他们也会有固定路径对其职能经理做汇报。员工通常与项目只是暂时的“虚线”关系，而与职能部门则是长期的固定关系。这使员工在向多人汇报时处于尴尬境地。如果项目经理比职能经理更加了解相关技术，情形会更加复杂。这会发生在研发类项目中。
项目所任命的职能员工应完成以下活动：
• 在项目约束下接受完成指定成品的职责。
• 尽可能早地完成工作。
• 周期性地向项目经理和职能经理反馈项目进展状况。
• 及时汇报问题，让问题显化并快速解决。
• 与项目团队其他成员分享信息。1.11 定义高层管理者的角色
PMBOK®指南，第6版
2.4.2 组织治理框架
在项目环境中，对高层管理者会有不同的新期望，也就是一个新协调者的角色。高层管理者应在如下问题中发挥协调、调节的作用：
• 在项目规划和目标设定中。
• 在冲突解决中。
• 在优先权确定中。
• 作为项目发起人。
高层管理者应在项目启动和规划时对项目近距离宏观协调，但在项目执行过程中应保持一定的距离，除非需要确定优先权和解决冲突。高层管理者在项目执行过程中对项目进行“干涉”，其原因就是高管并没有从项目经理那里获得关于项目状况的准确信息。如果项目经理可以向高管们提供有意义的汇报，那么所谓的干涉也许就会减少甚至消失。1.12 与高层管理者一起工作
在项目管理中，成功就像三条腿的凳子。第一条腿是项目经理，第二条腿是职能经理，第三条腿是高层管理者。如果三条腿中的任何一条折了，凳子就会翻倒。
项目管理的关键点是项目经理和职能经理的协调。在这种整合中，项目经理和职能经理必须彼此平等相待，并乐于分享职权、职责和权责关系。在管理良好的公司里，项目经理不必为资源而谈判，而只需简单地从职能经理那里得到承诺，在一定的时间、成本和绩效下完成所负责的工作。因此，无论职能经理委派任命谁来参与项目达成目标都不重要了。
由于项目经理和职能经理是“平等”的，高管的参与就必不可少，一方面为项目经理提供建议和指导，另一方面也要鼓励职能经理履行诺言。如果高层管理者能够起到这个作用，那他们就承担起项目发起人的角色，如图1-5所示。图1-5也说明了发起人并不总需要在高层管理者中找。项目发起人究竟要由谁来当，取决于项目的经济价值、项目的优先程度和客户是谁。
PMBOK®指南，第6版
2.4.2 组织治理框架
如图 1-5所示，项目发起人的最终目标是在幕后向项目成员提供公司“内部”和“外部”帮助。只要所有的工作流程运行平稳，那么即使没有这些承诺和支持，项目依然能够成功。但在危机时期，背后有“大哥”出谋划策是很有帮助的。
当一个高管被要求做项目发起人时，他有责任做出及时有效的项目决定。为此，他需要及时、准确和详尽的数据。保持管理信息畅通有利于达到这一目的，而那些各自为政互不通气的封闭活动会妨碍高层管理者制定与项目相关的有效决策。
项目发起人没有必要总是仅仅保留在管理高层。随着公司成熟地理解并实施项目管理，项目发起人也有可能会被下放到中层，也有可能转给董事会。图1-5 项目发起人协调图1.13 董事会作发起人模式/项目治理
所有的项目都可能陷入困境。当项目有麻烦时，通常只要项目需求没有施加巨大压力，项目经理在盟友项目发起人的帮助下就可以继续实施项目。
单靠某个项目发起人来解决项目问题，未必能够直接且及时。这时就需要运用有效的项目治理。项目治理实际上就是指制定决策的框架。治理涉及确定预期，确认权责、责任及授权，规范绩效审核等决策。治理还与一致的管理、统一的政策和一定职责内决策权和实施权有关。治理有利于决策及时有效地产生。
虽然项目遵循的企业项目管理方法一样，但项目决策的方法各不相同。治理功能可以独立运作，也可以成为项目管理体系的一部分。治理的设置并不是为了替代项目决策，而是为防止制定不良决策。
以前，治理是由一个项目发起人承担。如今，治理扩大为特设委员会，其中包括来自各方相关方的代表。表1-3介绍了几种不同项目管理团队采用的治理方法。不同项目不同行业，成为治理委员会委员的资格会有相应的变化。治理委员会委员的组成还依赖于各相关方的人数以及项目的性质是内部还是服务于外部客户。在长期项目中，委员可能在进程中有所调整。图1-3 项目治理的类型
对项目和项目集的治理有时会失败，因为人们混淆了项目治理和公司治理的概念。这导致治理委员会的委员们不知道他们承担着什么样的角色。项目治理和公司治理的主要区别有以下几个。
• 一致性：公司治理关注项目组合与总体业务目标的一致性和满意度。项目治理关注监控项目的方法。
• 指导：公司治理提供战略指导，项目治理更偏向于经营指导。战略指导关注项目的成功如何满足企业目标，经营指导则根据项目的范围、时间、成本及功能等预先确定的参数做出决策。
• 仪表板：公司治理仪表板以财务、市场和销售指标为基础。项目治理仪表板则以时间、成本、范围、质量、行动环节、风险和成果等经营指标为基础。
• 委员：公司治理委员会的委员来自较高层管理人员。项目治理委员会的委员也可能包括中层管理人员。
失败的另一个原因可能是项目或项目集治理委员会委员不熟悉项目管理或项目集管理。这就导致了治理委员会管得太多太细。于是“哪些决策一定要由治理委员会来决定，哪些决策可以由项目经理决定”的问题会一直存在。通常，项目经理对确保基准的必要举措有权做出决定。治理委员会则必须有权决定是否批准超出一定金额的范围变更，同时有权调整项目，以保证项目与企业战略目标的一致。1.14 作为计划制订者的项目经理
PMBOK®指南，第6版
第9章 项目资源管理
项目经理的主要职责是制订计划。如果项目计划执行得好，那么可以预想到在项目经理置身事外的条件下，项目自身能够正常运行。当然，这种情况很少发生。只有极少数项目可以在不需要项目经理解决冲突或权衡机会成本的情况下完成。
在大多数情况下，项目经理制定要完成项目的总体框架，而由职能经理（这些是真正的专家）填充项目计划的细节。虽然项目经理不能控制或分配部门各类资源，但是他们必须确保足够的资源来满足项目的各项需要，并非反之亦然。作为项目计划的缔造者，项目经理必须：
• 明确整体任务的定义。
• 明确所需的各项资源（也可能是需要拥有的技术水平）。
• 确定主要的时间截点。
• 定义最终产品或成果的质量目标和稳定性要求。
• 确定测量性能或绩效的基础。
• 定义项目成功的标准。
如果项目经理正确而恰当地处理上述各项任务，那么可以达到：
• 保证各职能部门的组员可以理解他们为实现项目所需的共同职责。
• 保证能够提前知晓由于时间进度计划和关键性资源配置引起的一些问题。
• 尽早发现那些可能阻碍项目成功的问题，以便及时实施纠正方针或重新制订计划从而预防问题或解决问题。
项目经理要对项目的管理负责，所以他们有权制定自己的政策、程序、规则、方针和准则。当然，这些政策方针要与企业的宏观政策相符合。有着成熟的项目管理结构的企业通常采取相对宽松的企业指导方针，因而项目经理对决定怎样控制他们的项目有一定程度的灵活性。
制定项目的管理方针只是项目计划的一部分。高管们必须要么在项目启动阶段与项目经理一起工作，要么在后续时间自己作为人力资源加入其中。不合理的项目管理计划会导致这样的状况：
• 不断更改或制定企业或项目的政策方针准则。
• 不断转移组织责任和可能不必要的结构重组。
• 为获取新知识和技术而需要新的人员配置。
如果这类状况同时在几个项目中出现，整个组织机构将出现大混乱。1.15 项目冠军
公司会鼓励员工提出新想法，如果这些想法被公司采纳，公司将会给予物质或非物质奖励。一种奖励的方式是将这个人评为“项目冠军”。然而，当项目冠军成为项目经理，经常发生项目技术上可行，但最终却失败的情况。
表1-4给出了项目经理和项目冠军的比较。从中可以得出结论：项目冠军会变得过于注重技术层面，忽视管理职责。也许，项目冠军做一个项目工程师比做一个项目经理要出色得多。图1-4 项目经理与项目冠军的比较
这种比较并非说明技术导向的项目经理比项目冠军差，相反，它表明要选择合适的项目经理要从项目的各个方面综合考虑。1.16 项目驱动型和非项目驱动型组织
PMBOK®指南，第6版
2.4.1 概述
在微观层面，事实上几乎所有的组织机构都是由市场、工程或是生产方式驱动的。但在宏观层面，组织机构分为项目驱动型和非项目驱动型。PMBOK®指南中称其为“基于项目”和“非基于项目”，而本书在这里使用“项目驱动”和“非项目驱动”（也叫“业务驱动”）。在项目驱动的组织中，如建筑业或飞机制造业，所有的工作都要个性化处理，每个项目作为一个独立的成本核算单元，有单独的利润报表。公司的总利润直接就是所有项目利润之和。在项目驱动型组织中，项目是企业运营的主体。
而在非项目驱动型组织中，如技术含量低的制造业，利润是通过产品线或职能部门线来衡量的。在这类组织机构中，项目的存在仅是作为产品线或职能部门线的辅助功能，资源分配是以哪些产品线或职能部门最能创收为导向的，而不是以项目为导向。
项目管理在非项目驱动型组织中通常难以实施，原因：
• 项目也许凤毛麟角。
• 并非所有项目都有相同的项目管理要求，也不可能统一管理它
试读结束[说明：试读内容隐藏了图片]