今天整理了IT项目组和大型项目管控多年的全面总结和经验分享。项目案例的背景都来自集团层面的大项目管理和项目群管理。类似的项目往往涉及十几个IT软件开发人员，1000多人，相关的交互和集成界面相对复杂。

对于这样的大型IT项目，一个独立的PMO通常负责制定整体的项目管理标准，管理项目的整体计划，并监控进度和质量。

项目群管控01

项目群的关键里程碑必须是每个子项目的关键里程碑,每个子项目的里程碑一定不能和项目的整体里程碑同时设置，尽量提前，这样子项目的里程碑才能提前，在关键链上有一定的缓冲时间。对于最后一个子项目的里程碑到达时间，往往需要留有一定的缓冲余量，没有任何缓存的程序的里程碑往往是一个未完成的任务。

实现大项目群各个子项目之间的交互和依赖关系及其复杂。子项目关键里程碑的难度通常不取决于子项目本身，而是取决于其他几个子项目的外部预依赖性。前置依赖越多，子项目里程碑达成的风险越大。子项目的预依赖也可能对其他子项目有预依赖，从而形成跨项目的预依赖链。依赖链越长，实现子项目里程碑的风险就越大。

项目目标的分解和项目的总体规划与控制是自上而下的，但各子项目的实际任务活动是自下而上进行的，工作量估算是自上而下的。不可控的大项目来源于不可控的子项目本身，不可控的子项目本身来源于不可控的项目团队，最终会体现在不可控的单个项目中。如果整个大项目组的每个人都不能给自己的工作项目和任务规定时限，并按照时限交付高质量的中间产品，那么整个大项目组就会完全失控。

我一直强调，项目群管理和项目管理往往仅仅是辅助，更加重要的是小组本身的工作质量和能力。就像一支没有基本能力的队伍，通过简单的管理、标准化、流程化来解决问题是完全不现实的。

项目群管控的难度往往还体现在跨项目的协同和高效沟通上面,对于单个项目来说，所有的沟通都属于团队内部的沟通，而团队成员可能已经有了一种默契的沟通和一个已经形成的团队词汇。对于项目组来说，各个子项目很难在短时间内形成高效的沟通能力。单个项目可以对自己子项目的里程碑、目标和任务负责，但很难真正对整个大项目组的最终目标负责，这一方面是本身的意识和态度问题，一方面是能力问题.对于一个全球性的大项目，子项目团队成员很难真正掌控全局。PMO也很难，能制定出清晰严谨的规范流程和项目章程，但不深入到每个子项目，还是很难真正掌握全局任务和风险。

大型项目实施过程中，协调存在诸多困难。首先，这必须追溯到整个大型项目或项目组的分解。我们并不了解子项目之间的所有依赖关系和具体协调点，也没有提前针对这些接口和依赖关系制定有针对性的风险应对计划。对于一个完整的子项目，应该由每个子项目经理来识别和处理风险，而对于跨项目间的协同和依赖，则需要由PMO牵头来共同分析和识别风险应该制定相应的风险应对方法并尽早采取行动。

对于单个项目，某个工作任务可能不是项目的关键路径，但它往往是其他子项目的关键路径。对于这种工作任务，需要升级到PMO级别进行重点跟踪。对于子项目来说，他们往往没有这种意识，但是一旦这些任务延期，就会直接影响整个项目组里程碑的达成。跨项目依赖识别、关键链识别和控制将成为大型项目组按计划实现目标的关键。

对于单个项目，如果要求每个项目成员都对项目目标负责，那么对于大项目群而言，则至少需要每个子项目的项目经理对整个项目群目标负责。的这些项目经理应该对项目组的通用词汇有统一的认识，项目经理之间可以高度协调合作，高效沟通，更加关注项目组的整体目标，而不是各自项目目标的实现。

在产品管理中曾经谈到过组合管理，管道管理和资源管理方面的内容，对于一个大型产品的研发往往涉及到多个研发项目和配套项目，因此往往从一开始就需要考虑资源计划，资源分片和跨项目的资源调配和资源池管理。

而对于外部大型项目群，往往涉及到的是不同的合作厂商，那在这种情况下往往很难真正进行跨项目的资源管理，出现的情况往往就是项目有些提前，有些延后，各个项目紧张空闲度完全不同，各个子项目内的资源也很难在项目群级别进行充分利用和最大化。

对于一个大型的项目群，如何保证项目群里面的每个子项目都能够遵循相关的方法，工具，技术，规范和流程是一个相当重要的问题。很多时候回顾这些大项目你会发现，并不是没有组织级的规范和流程约束，而是每个子项目在执行过程中出现偏差，对于组织级不能只制定规范流程而不管最终规范流程的执行和管控。

正是基于这个原因，对于大项目群的管理需要采用进一步的矩阵式结构，纵向和横向要完全结合。纵向关注的是项目本身的目标，而横向关注的是跨项目共性的阶段和过程统一。对于大型软件项目群而言，类似需求组，UI/UE组，架构组，平台技术组等都是需要考虑横向贯穿和统一的跨项目协同团队。

对于大项目群而言，PMO往往对于项目成败起到很关键的作用，在这里不是简单的项目章程，规范流程的事情，而更加重要的是风险和管控意识的问题。PMO能否将事情跟踪到落地，各个子项目能否高度地配合PMO整体目标，PMO能否高效的协同各个子项目团队才是最重要的。

关键链管理方法在项目群管理中同样适用。关键链是考虑了缓冲和资源约束而找寻到的项目关键路径。因此谈关键链则重点始终脱离不了缓冲和资源约束两个重点。在思考大项目群的关键里程碑的时候，必须要思考到各个子项目对应的关键里程碑，并且在各个子项目结束处预留相应的接驳缓冲，在整个大项目群里程碑处预留相应的项目缓冲。同时对接驳缓冲根据子项目各任务间的前置依赖关系进行分析缓冲可能存在消耗的风险点，并制定有针对性的风险应对计划。

项目群中的多重层级结构将直接导致跨项目沟通协同的效率问题，沟通的失真问题。这也是前面提到的需要在纵向结构上面增加横向的跨项目协同联合团队的原因。一个是加强规范过程的落地，一个是实现高效的沟通和协同。

项目群管理中的两个重点，一个是跨项目的沟通协同问题，一个是跨项目的任务前置依赖问题。大项目范围管理的两个重点，一个是各个子项目项目范围和边界问题，一个是项目间的依赖，协同和集成问题。在项目范围梳理的时候，必须要考虑由于分解为多个子项目后带来的后续项目集成的工作量和难度。

大项目管控01

对于项目群和大项目管控是我前面做了初步说明，特别是对于大的项目群管理其里面的复杂度可能会远远超过你的想象，只有真正实践过才能够积累实际的经验和教训。

那么在IT领域，一个项目经理，究竟需要具备什么样的技能和经验，才能够真正将一个项目群或大项目管理好，这里面的关键点究竟在哪里？

首先我们强调比较多的就是项目经理必须具备技术背景，简单点来说就是项目经理需要是从一线一点一滴实践慢慢提升上来的，有实际的需求经验，技术开发经验，包括某个垂直行业和业务领域经验。这些内容都不是简单的理论，而是需要长期大量实际项目的实践积累，只有这种实践你才知道真正项目在建设和实施中存在哪些风险和关键点，如何在项目计划和执行管控的时候进行预判。

技术背景需要到什么程度？

个人觉得还是用胸有成竹这个词比较合适，即一件事情应该怎样做，如何做，用什么方法做，可能会遇到什么风险和问题等都非常清楚，那么我们的技术积累基本就是到位的。而要达到这水平项目经理基本在生命周期的各个阶段，岗位角色上面的水平都能够达到80分左右的水平，而是是自己真正亲自实践锻炼过程，知根知底，那这样的技术背景在做项目计划和风险识别的时候就会起到关键的作用。

对于项目管理中的做计划，我也一直强调它不是简单的求解一个标准方程式，而是真正需要你亲自实践和证悟过，用你的经验积累知道下次应该怎么做，而不是简单的WBS分解和计算关键路径。

其次，要真正把一个大项目管理和执行好，80%以上的工作都是围绕人展开的，在团队内部是招人，用人，培训和激励人；而在外部则是复杂的干系人管理和协同。一个管理者的重点是管理好人，包括他自己，那么要管理好人最重要的就是知道如何招募和组建一个核心团队，同时通过后续团队建设和培训使其具备足够的战斗力和执行力。你会有大量的时间都花在人的培养上，团队建设上，大项目要成功一定是依靠整个团队集体力量，而不是单个人的努力和付出。

对于人的管理重点本身又在于如何使得公司和团队额述求和个人的述求达到一种最佳的平衡状态，其次就是真正做到人尽其才，发挥每个人的最大价值。要达到这个目标你就必须清楚地知道每个人的真实需求，每个人实际的性格特点和做事风格，以及每个人当前真实的技能水平和擅长的工作。只有上面的都做到的，你才可能做到为团队每个人分配最适合他们的工作，并时刻激励他们成长。

最后我觉得最重要的仍然是风险意识和风险管理，一个好的项目管理者时刻都在思考可能遇到的问题，预判可能存在的危机，及早的规划和计划PlanB等事情。任何事情如果都能够做到未雨绸缪，那么在项目执行过程中就不应该存在任何问题，及时出现问题我们也有B计划去快速解决掉，那么项目不成功都难。

项目管理或计划的本质就是时刻的预判和识别风险并提前解决和应对的过程。

对于风险的应对，最容易的就是缓解或减轻，而最难的就是受外在环境约束只有接受风险。特别是大项目建设中，经常会出现大量外在条件依赖，这些依赖都直接影响到项目的成败，而这些前置依赖我们却很难真正将风险或问题控制在自己手中。即使这样，我们很多时候在项目计划和执行中，仍然会争取各种可能的方法，去推动外在依赖问题的解决。

简单来说就是一个好的项目经理会做两类事情，一类是自己可以解决的风险，那么重点就是预判和减轻，而对于外在无法解决风险，即尽量采用各种措施方便别人而减少对自己的麻烦。特别是对于第二点，需要真正做过大项目管理和实施，才能够真正体会其作用。

大项目管控02

管理项目本身有时候又是管理客户，即在信任的基础上建立和客户的长期合作伙伴关系，你和客户不是简单的甲乙买卖双方关系，而是一种合作伙伴。要做到这点对项目经理相对不容易，即项目经理不是单纯地完成合同执行和收款，而是在关键点真正会考虑客户的利益做好客户服务，只有这样这种合作才可能长期。

你帮助客户解决实际的问题，客户一定会给你合适的利润，如果没有利润那么这种客户本身也不是优质客户。

对于大项目的执行和管控，项目经理本身就应该有一种极强的责任感，一方面是不辜负了客户的信任和期望真正交付有价值的成果，一方面是进一步梳理公司和个人在客户心目中的品牌形象。现在越来越多的客户也意识到了，项目选择不是简单的选择品牌响的大公司，而是真正的选择团队和选择人，只有乙方组建的靠谱，项目最终的成功执行和交付才真正有保障。

周期性执行的工作事务和项目本身的工作任务要分开，对于团队中的每个工作岗位角色都应该做到这点。否则很容易将有明确目标的项目任务变成周期性的重复工作，而最终失去了目标压力。对于周期性的工作则更多的是养成一种工作习惯，并提升整个团队的执行力。

在考虑整体项目计划的时候，应该优先考虑项目和外部干系人，外部其它项目之间的分工边界和职责矩阵，其次才是考虑项目内部的角色分工，资源安排和进度计划。如果是对于项目内部引起的项目延期我们很容易进行解决，但是由于外部制约引起的延期如果在前期没有进行风险识别和预判，那到了后期就很难处理。

对于咨询和实施类项目，进度即成本，因为一旦进度延后一定后投入更多的人天工作量，而多投入的人天全部是成本的投入和增加，对于人力成本本身又是整体项目成本的大头。同时对于这类项目我们看到，在进行资源规划和进度计划安排的时候，尽量保证不同角色人员投入时间的连续性，如果不连续，那么人员的空闲时间就很难被其它项目高效利用，也间接增加了整个产品线和团队的成本。

项目可视化仍然是项目管控的一个重点，而对于项目范围，进度，质量，成本投入，资源安排情况等都是可以进行可视化的内容。这个在我博客很早的《可视化项目管理》一书的读书笔记中已经有过详细的说明，同时我们也看到对于SCRUM敏捷项目管理方法论中类似看板管理的方法都可以借鉴和使用。

项目执行周报，月报等，哪些是客户真正希望看到的内容，哪些又是我们希望让客户看到的内容一定要分清。对于整个项目执行的进度状态等一定是需要反馈的，而对于项目整体风险，问题，需要客户协助的点则是我们需要时刻让客户知道的。而不是等项目执行已经出现了大问题才反馈给客户。

及早的让所有投入的资源都有事可做，是我们在进行WSB分解和任务安排的时候必须考虑的问题。只有这样才能够更好地提升资源利用率，并完成无前置依赖并可以提前完成的工作任务。

大项目管控03

对于项目群管理和项目管理的区别，其核心的一个点就是原来单项目内部的协同会变为多项目间的协同和依赖，在管理单个项目的时候，很多协同和接口属于内部沟通和协调的事情，而变好为项目群管理候你会发现这些都变为项目间的接口和协同。原来内部接口间不规范和不标准的地方全部会被暴露出来，同时沟通和协同的难度也成指数级增加。

对于大型项目群，大型项目经理必须熟悉整个项目群涉及到的各个子项目，各个阶段和生命周期。这类大项目经理往往有能力一开始就自顶向下的制定项目计划，即先从整体项目目标要求，制定较粗的里程碑计划，在里程碑计划中就已经很好地进行了接口和集成设计，考虑了各个项目间的协同和依赖关系，在这个大目标评审通过后再由各个子项目经理进行进一步的单个项目计划的详细分解和安排。

当然如果大项目经理对整体项目群不熟悉，也可以先由各个子项目经理提供比较粗的里程碑计划，然后大项目经理根据里程碑计划来安排顶层的项目群整体计划并组织评审。不论是哪种方法，大项目经理都必须重点考虑各个子项目间的关联和依赖关系，包括后期的协同和集成。

项目群管理和项目组合管理是不同的，项目群管理本质还是一个大项目，只是里面分解为了多个相对独立的子项目。而项目组合管理更多的是偏战略和决策层面，考虑如何基于目标要求选择最合适的多个项目组合。对于项目群中各个子项目相对独立，这里面包括了目标独立，资源独立，项目执行和管控独立，输出独立几个方面。正是由于这种独立性将各种内部依赖转化为了外部依赖。

在大项目管理中，除了日常单个项目管理需要考虑的内容外，增加了资源管理，依赖协同和边界管理，同时会进一步增强多项目间协同的问题管理和风险管理，即在大项目管理中实际的单项目管理工作仍然是在子项目经理完成，而大项目经理更多的则是上层的多项目监控和资源管理。

如上面所说，很多人会认为大项目经理往往不进入到单项目管理细节，那么是否对项目经理的技术背景和经验要求就不高？更多的是项目管理标准和规范方面的执行和监控，沟通协同和汇报。但是实际情况是大项目经理更加需要懂技术，而是需要懂更加全面业务域和技术域的技术，只有这样你才能够更好的和各个子项目经理沟通，同时也发现子项目执行中的潜在风险和问题。要知道遇到那种报喜不报忧，将问题藏着掖着的情况还是很常见的。