今天整理多年IT项目组与大型项目管控的回顾总结与经验分享。项目案例背景均来自于集团级大型项目管控和项目群管理。类似的项目组往往涉及十余名IT软件开发人员和千余人的项目组，相关的交互和集成接口相对复杂。对于此类大型IT项目，往往由独立的PMO负责制定整体项目管理标准和规范，对项目进行整体项目管理和进度质量监控。1.项目集管控项目集的关键里程碑必须是每个子项目的关键里程碑。每个子项目的里程碑不得与项目的总体里程碑设置在同一时间点。可以尽可能提前，让子项目的里程碑可以提前，关键链上已经有一定的缓冲时间。对于最后一个子项目的里程碑到达时间，往往需要预留一定的缓冲余量，没有任何缓存的程序里程碑往往是无法完成的任务。一个大程序组的各个子项目之间的交互和依赖是极其复杂的。一个子项目关键里程碑的实现难度，往往不取决于子项目本身，而是取决于多个其他子项目的外部依赖。前期依赖越多，实现子项目里程碑的风险就越大。一个子项目本身的预依赖也可能对其他子项目产生预依赖，形成跨项目的预依赖链。依赖链越长，子项目里程碑实现的风险就越大。方案目标的分解、总体方案的规划和控制是自上而下的，但各子项目的任务和活动的实际执行、工作量的估算是自下而上的。大项目的不可控性来自子项目本身的不可控性，子项目本身的不可控性来自项目组的不可控性，最终会体现在单个项目的不可控性上。如果整个大程序中的每个人都不能给出自己的工作项目和任务，并按时限交付高质量的中间产品，那么整个大程序就会处于完全不可控的状态。我一直强调的是，项目集管理和项目管理往往只是辅助，更重要的是团队本身的工作质量和能力。就像一个没有基本能力的团队，通过简单的管理、规范和流程来解决问题是完全不现实的。项目群管控的难点往往体现在跨项目协作和高效沟通上。对于单个项目，所有的沟通都属于团队内部沟通。团队成员本身可能有默契的沟通和长期形成的团队词汇。对于节目组来说，短期内很难在各个子项目之间形成高效的沟通能力。单个项目可以对自己子项目的里程碑、目标和任务负责，但很难真正对整个大程序组的最终目标负责。这一方面取决于自身的意识和态度，另一方面取决于自身的能力。对于一个全球性的大项目，子项目组成员也很难真正做到掌控全局。PMO也很难。PMO可以制定出清晰、严谨的规范流程和项目章程，但不深入到每个子项目，仍难以真正控制总体工作任务和风险。在大型项目的实施过程中，我们会发现很多协同上的困难。这首先要追溯到整个大型项目或程序组的分解。这些接口和依赖关系制定了有针对性的风险应对计划。对于内部子项目，各子项目经理应识别和应对风险，而对于跨项目协作和依赖，需要PMO牵头共同分析识别风险，并提前制定相应的风险应对办法，早点行动。对于单个项目，某个工作任务可能不是你项目的关键路径，但往往是其他多个子项目的关键路径。对于这类工作任务，需要提升到PMO级别进行重点跟踪。对于子项目，他们往往没有意识到这一点，但一旦这些任务被延误，就会直接影响到整体项目里程碑的达成。跨项目依赖关系的识别和关键链的识别和控制，将成为大型项目群按计划实现目标的关键。对于单个项目，如果要求每个项目成员对项目目标负责，那么对于一个大的项目群，至少要求每个子项目的项目经理对总体项目目标负责。这些项目经理应该对程序的常用词汇有统一的理解。项目经理可以高度协调合作，高效沟通，能够更加关注项目的整体目标，而不是单个项目目标的实现。2.项目管理与控制在产品管理中，提到了组合管理、管道管理和资源管理。一个大产品的研发往往涉及多个研发项目和配套项目，因此往往需要从一开始就考虑。资源规划、资源分片和跨项目资源分配和资源池管理。对于大型的外部项目组，往往涉及不同的合作厂商。在这种情况下，往往很难真正跨项目管理资源。经常出现的情况是项目提前，有的延期，各种项目紧张。可用程度完全不同，各个子项目内部的资源也难以在程序层面得到充分利用和最大化。对于一个大型项目，如何保证项目中的每个子项目都能遵循相关的方法、工具、技术、规范和流程是一个非常重要的问题。很多时候回过头来看这些大项目，你会发现，并不是没有组织层面的规范和流程约束，而是每个子项目的执行都存在偏差。对于组织层面，不能只制定规范过程而忽略最终规范过程的执行和控制。.正因如此，大型节目组的管理需要采取进一步的矩阵结构，纵向和横向必须充分结合。垂直关注点是项目本身的目标，而水平关注点是项目间通用的阶段和过程的统一。对于大型软件项目组，相似的需求组、UI/UE组、架构组、平台技术组都是跨项目协作团队，需要考虑横向渗透和统一。对于大型项目组，PMO往往对项目的成败起着关键作用。在这里，不是简单的项目章程和标准流程的问题，更重要的是风险和管控意识的问题。PMO能不能把事情跟踪到位，各个子项目能不能高度配合PMO的总体目标，PMO能不能有效协调各个子项目的团队才是最重要的。关键链管理方法也适用于项目管理。关键链是在考虑缓冲和资源约束的情况下找到的项目的关键路径。因此，在谈关键链的时候，永远都离不开缓冲和资源约束这两个关键点。在考虑一个大程序的关键里程碑时，需要考虑每个子项目对应的关键里程碑，在每个子项目的末尾预留相应的连接缓冲区，在整个的里程碑处预留相应的项目大程序缓冲区。同时，根据子项目任务之间的前置依赖关系分析连接缓冲区，分析缓冲区潜在消耗的风险点，制定有针对性的风险应对方案。节目组中的多级结构将直接导致跨项目沟通协调的效率低下，以及沟通失真的问题。这也是上面提到的我们需要在垂直架构中加入一个水平的跨项目协作团队的原因。一是加强规范流程的落实，二是实现高效沟通协作。项目集管理有两个重点，一是跨项目的沟通协作，二是跨项目的任务前置依赖。大项目范围管理的重点有两个，一是各个子项目的项目范围和边界问题，二是项目间的依赖、协作和集成问题。在梳理项目范围时，需要考虑分解成多个子项目对后续项目集成带来的工作量和难度。3、大型项目管控我对项目群和大型项目的管控做了初步的讲解，尤其是大型项目的管理，其复杂性可能远超你的想象。经验教训。那么在IT领域，项目经理需要具备什么样的技能和经验才能真正管理好一个项目组或者一个大项目呢？这里的关键点是什么？首先，我们更强调项目经理一定要有技术背景。简单来说，项目经理需要从一线实践一点一滴逐步提升，具备实际需求经验和技术开发经验，包括在某个垂直行业和业务领域的经验。这些内容不是简单的理论，而是需要大量实际项目的长期实践积累。只有通过这种实践，才能知道在实际项目的建设和实施过程中存在哪些风险和关键点，在项目规划和执行控制预测中如何去落实。技术背景需要到什么程度？个人觉得用“认真”这个词比较合适，就是做一件事，怎么做，用什么方法，可能遇到什么风险和问题。那么我们的技术积累就基本到位了。要达到这个水平，项目经理在生命周期的每个阶段基本可以达到80分左右的水平，工作角色的水平在80分左右。相反，他真正地亲自实践了培训过程并且了解基础知识。然后这样的技术背景用于项目规划。它将在风险识别中发挥关键作用。项目管理中的规划，我一直强调不是简单的解一个标准方程式，而是真的需要自己去实践去体会，用自己的经验知道下次要做什么，而不是简单的WBS分解并计算关键路径。其次，要真正把一个大项目管理好、执行好，80%以上的工作都是围绕人展开的。在团队内部，涉及到招聘、用人、培训和激励；而在外部则是复杂的利益相关者管理和管理。协同作用。一个管理者的重心是管好人，包括他自己，所以管好人最重要的就是懂得如何招募和组建核心团队，同时通过follow让他们有足够的战斗力和执行力-up团队建设和培训。你会花很多时间在人员培训和团队建设上。一个大项目的成功，必须靠整个团队的集体力量，而不是一个人的努力和付出。人的管理的重点是如何在公司报表和个人报表之间取得最佳平衡，二是真正做到人尽其才，实现每个人价值的最大化。要实现这个目标，你必须清楚地了解每个人的真实需求，每个人实际的性格特征和做事风格，以及每个人目前真正的技能水平和擅长的工作。只有做到以上几点，才能把最适合的工作分配给每个团队成员，时刻激励他们成长。最后，我认为最重要的是风险意识和风险管理。一个好的项目经理总是思考可能出现的问题，预测可能出现的危机，提早计划和计划PlanB。如果一切都能未雨绸缪，那么在项目执行过程中应该不会出现问题。即使出现问题，我们也有快速解决问题的B计划，所以项目很难失败。项目管理或计划的本质是始终预测和识别风险并提前解决风险的过程。对于风险的应对，最简单的是减轻或减轻风险，但最难的是仅在外部环境的约束下接受风险。尤其是在大型项目的建设中，往往存在大量的外部条件依赖，直接影响到项目的成败，而这些前期的风险或问题我们很难真正控制在自己手中-依赖性。即便如此，我们在项目规划和执行中也时常争取各种可能的方法，以促进外部依赖的解决。简单来说，一个好的项目经理会做两类事情，一类是自己可以解决的风险，那么重点是预测和缓解，对于外部无法解决的风险，也就是尽量采取各种措施，方便别人，减少别人。给自己添麻烦。尤其是第二点，你需要真正去管理和实施大型项目，才能真正体会到它的作用。4、大型项目控制管理项目本身有时也会对客户进行管理，即在信任的基础上与客户建立长期的合作伙伴关系。你和客户不是简单的甲乙买卖双方关系，而是一种伙伴关系。项目经理做到这一点并不容易，即项目经理不是简单地完成合同的执行和收款，而是真正在关键点考虑客户的利益，做好客户服务工作。只有这样，这种合作才有可能长久下去。如果你帮客户解决实际问题，客户一定会给你合适的利润。如果没有利润，那么这种客户本身就不是优质客户。对于大型项目的执行和控制，项目经理本身应该有很强的责任感。一方面，不辜负客户的信任和期望，交付有价值的成果。另一方面是进一步梳理客户心目中的公司和个人。品牌形象。现在越来越多的客户也意识到，项目选择不是简单的选择大公司、品牌好，而是真正的团队和人的选择。只有乙方是可靠的，项目的最终成功执行和交付才是真正有效的。保证。重复出现的工作问题和项目本身的工作任务应该分开，这应该针对团队中的每个工作角色来完成。否则，很容易把目标明确的项目任务变成周期性的重复性工作，最终失去目标压力。对于周期性的工作，更多的是养成一种工作习惯，提升整个团队的执行力。在考虑项目总体规划时，应优先考虑项目与外部利益相关者、其他外部项目之间的分工和责任矩阵，其次是项目内部的角色分工、资源安排和进度安排。内部项目造成的项目延误，我们解决起来容易，但外部约束造成的延误，如果前期没有识别和预测，后期处理起来就很难了。对于咨询和实施项目来说，进度就是成本，因为一旦进度延后，就必须投入更多的工作量，而额外的工作量都是成本的投入和增加，而人力成本本身就是整个项目成本的大头。同时，对于这类项目，我们看到，在规划资源和调度安排时，要尽量保证不同角色人员所花时间的连续性。间接增加了整个产品线和团队的成本。项目可视化仍然是项目管控的一个重点，项目范围、进度、质量、成本投入、资源安排等都是可以可视化的。这个在我博客的早期书《可视化项目管理》的阅读笔记中已经有详细的解释。同时，我们也看到了SCRUM敏捷项目管理方法论中类似看板管理的方法可以借鉴和使用。项目执行周报、月报等，哪些是客户真正希望看到的内容，哪些是我们希望客户看到的内容，要分清楚。必须反馈整个项目实施的进度和状态。对于整体项目的风险、问题、需要客户协助的点，我们需要时刻让客户知晓。而不是等项目执行出现重大问题再反馈给客户。让所有投入的资源尽早有事可做，是我们在进行WSB分解和任务安排时必须考虑的问题。只有这样，才能更好地提高资源利用率，完成没有前置依赖、可以提前完成的工作任务。5、大型项目管控中项目集管理与项目管理的区别，其核心点在于，原来单个项目内部的协作，将变成多个项目之间的协作与依赖。在管理单个项目时，很多协作和接口属于内部沟通和协调，而当它变成项目管理时，你会发现这些都变成了项目之间的接口和协作。原有内部接口之间所有不规范、不规范的地方都会暴露出来，沟通协作的难度也会成倍增加。对于大型项目，大型项目经理必须熟悉整个项目所涉及的每个子项目、每个阶段和生命周期。此类大型项目的管理者往往具备从一开始就自上而下制定项目计划的能力，即根据整体项目目标的要求，制定出一个粗略的里程碑计划，并且接口和集成设计得到很好的贯彻在里程碑计划中，考虑到各个项目之间的协同和依赖关系，在这个大目标审核通过后，各子项目经理将对各个项目计划进行进一步的细化分解和安排。当然，如果大项目经理对总体方案不熟悉，各子项目经理可以先提供一个比较粗略的里程碑计划，然后由大项目经理安排顶层总体方案计划，并根据里程碑计划。无论采用哪种方式，大项目经理都必须关注各个子项目之间的关联和依赖，包括后期的协作和集成。项目集管理不同于项目组合管理。项目集管理本质上是一个大项目，只是分解成多个相对独立的子项目。而项目组合管理更多的是在战略和决策层面，考虑如何根据目标需求选择最合适的多个项目组合。程序组中的每个子项目都是相对独立的，包括独立的目标、独立的资源、独立的项目执行和控制、独立的输出。正是因为这种独立性，才将各种内部依赖转化为外部依赖。在大项目管理中，除了日常单一项目管理需要考虑的内容外，增加了资源管理、依赖协作和边界管理，同时多项目协作的问题管理和风险管理进一步加强，就是在大项目管理上。单项目管理工作大部分还是由子项目经理完成，而大型项目经理更关注上层的多项目监控和资源管理。上文提到，很多人认为大项目经理往往不深究单个项目管理的细节，那么是不是对项目经理的技术背景和经验要求不高呢？更多的是项目管理标准和规范的实施和监控，沟通协调和报告。但实际情况是，大项目经理更需要懂技术，更需要懂更全面的业务领域和技术领域技术。只有这样才能更好的与各个子项目经理沟通，同时发现子项目执行中潜在的问题。风险和问题。要知道，报喜不报忧、隐瞒问题的情况还是很常见的。
