平衡矩阵
本文是我们的“从战壕”集合的一部分。 它描述了在使用矩阵项目管理环境的组织中实施企业项目管理 (EPM) 的人面临的挑战。
若要下载本文的 Word 版本，请参阅 平衡矩阵：白皮书。
若要查看更多文章，请参阅 “从战壕”白皮书。
平衡矩阵
在项目管理圈子中，我们往往经常谈论矩阵管理环境。 矩阵管理并不是什么新事物。 它已成为几乎所有高科技组织管理的事实标准。
矩阵管理的想法来自70年代初的管理思维。 J.R. Galbraith 为我们提供了 1971 年关于该主题的首批出版著作之一，讨论如何结合组织和职能责任。 当时的现行管理环境是分层的。
组织是强大的部门领导统治的巨大孤岛。 这非常有效，直到有多个项目必须跨多个部门才能完成。 30多年来，项目经理和协会（如项目管理研究所）一直推广“项目化”矩阵的概念。
在投影矩阵中，我们为组织建立了第二个轴线，并向管理项目的组织的这一部分赋予一些责任。 结果显示一侧的组织部门和项目经理将项目或产品交付到另一侧。
为什么要在谈论企业项目管理时谈论这一点？ 因为此模型已成为几乎每个 Microsoft EPM 解决方案部署的基石。 如果现在正在部署 Project Server，则肯定会在旅行中遇到此模型。 矩阵管理模型有一些例外，在完成本文之前，我将讨论这些模型，但只要我们关注技术组织，它就足以说明它接近通用。
如果现在正在处理 Microsoft EPM 解决方案部署，你会发现组织处于以下状态之一：
没有矩阵
组织完全基于孤岛。 每个部门负责人都像管理大组织的子公司一样管理自己的部门。 预算通过部门以分层方式向上汇总， (想到组织图) 。 启动项目时，即使其他部门可能需要资源来完成项目，也会在每个部门内完成。 如果项目无法使用管理部门的资源完成，则外部资源将作为部门间请求进行协商。
实际上，在你尝试管理这样的项目之前，这听起来并不太糟糕。 如果几乎每个项目都需要部门间资源，则无法确定组之间的优先级。 任何部门负责人都没有动力放弃对其自身资源的优先控制权。 放弃这种权力是反直觉的，所以任何无法在单个部门内完成的项目都会受到影响。
此外，当我们与比部门主管高一级的高管交谈时，普遍的哀叹是，他们无法获得任何资源容量规划。 这完全有意义。 没有跨部门结构来聚合资源容量规划所需的信息，也没有激励每个部门负责人提交此类分析所需的集中优先顺序。
在这种情况下，我们很可能发现不是一个，而是多个项目办公室-每个部门一个，彼此之间很少合作。
将 Microsoft EPM 解决方案部署到此类方案中需要对如何同时调整组织进行一些思考。 通常，我们接到这类公司的电话，要求我们做不可能的事情。 培训数百甚至数千名用户，安装 Project Server 并在几周内投入生产。 预期是，由于公司购买了集中式企业项目管理系统，因此组织将立即排队并作为集中式矩阵环境运行。 这是一个昂贵的幻想。 不可避免地，我们必须与高级管理层讨论如何改变组织。 对于希望仅仅购买软件足以让每个人都做出改变的承诺的管理层来说，这通常不是好消息。
我们通过制定集中式项目管理办公室和集中式项目管理程序的计划来启动此类项目。 Project Server 从中间开始缓慢引入。此类项目需要 12 到 24 个月才能让整个组织最终参与，这种情况并不少见。 我们刚刚在延迟了 21/2 年之后重新启动了这样的项目，而他们自己创建了一个 PMO。
有一个平衡矩阵
当这种情况发生时， 这是伟大的， 但不幸的是， 这是相当不寻常的。 保持平衡矩阵需要不断调整和谨慎。 但是，当我们找到一个平衡的矩阵时，我们也可能找到一组高度演变的过程、定义的角色和一个过程，每个参与者都很清楚。 将 Microsoft EPM 解决方案部署到此类组织是最佳方案。
有一个矩阵，但它是不均衡的
这是迄今为止我们面临的最常见情况，它非常有意义。 矩阵模型包含一些固有的冲突，因此我们经常发现该矩阵要么加权到具有弱 PMO 的部门，要么加权到具有弱部门负责人的 PMO。 或者 (，这是迄今为止最具挑战性的) 我们发现，矩阵的权重是一些部门，而不是其他部门和一些项目经理，而不是其他部门，因此很难获得组织中的重心。
在这些环境中部署 Microsoft EPM 解决方案意味着执行一些清单和发现工作。 在哪里建立了成功的流程？ 进程在哪里失败？ 哪些工作在集中项目管理级别，我们可以利用它来部署 Project Server，而哪些不是？
在这些类型的部署中，我们需要非常小心地选择要首先部署的 EPM 解决方案的元素以及要部署到谁。 在这种情况下，分阶段部署方法至关重要，因为大爆炸方法在这里几乎永远不会成功。
矩阵挑战
对于那些只知道矩阵结构化组织的人来说，你甚至可能不去思考这是一个好的结构还是坏的，或者想想这种管理是强项还是弱项。 矩阵组织存在一个根本的挑战，许多人甚至没有质疑：它是设计冲突。 该结构建立了两股对立力量：部门负责人和项目经理。 当然，我们永远不会大声说这一点，但只是看结构就不言而喻了。
部门负责人的目标是注意部门中的工作人员。 他们希望确保员工是高效、熟练、满意的员工。 如果我们把组织留给部门负责人，我们最终会得到训练有素的员工，不是过度劳累，而且薪酬很好，但生产不多。
项目经理的目标是注意项目的交付。 他们希望确保项目尽可能快速、低成本地完成，同时保持项目开始时定义的范围和质量。 如果我们把组织留给项目经理，我们最终会很快完成一些项目，但随着我们以完成项目的名义烧毁员工，员工将大量流失。
矩阵组织的想法是，在这两股力量之间建立冲突将愉快地平衡组织在生产力和员工满意度之间。 不过，前提是部门主管和项目经理最终都和彼此一样强大。 当然，挑战在于人不是被创造的平等的。 总会有一些项目经理比另一个更有经验的项目经理：一些部门负责人比下一个更熟练。
这种缺乏平等使矩阵在第一天就失平衡了。 仅仅意识到这个例外是一个平衡的矩阵组织通常足以让 PMO 和组织者考虑如何维护秩序，这可以是一件好事。
获得完美的平衡并不像确保努力确定组织项目和人员陷入困境那么重要。 使矩阵环境工作的工具始终相同：流程和通信。 熟练的实施者可以确定对组织很重要的流程和过程。
放弃矩阵？
不是每个人都是矩阵组织的粉丝。 在过去几年中，许多商业领袖都表示，也许矩阵组织的想法不是最好的计划。 “将人员分成专门的项目团队，”他们说，“你会为此感到更高兴”或“组织项目，在每个部门内工作，并将其交给部门负责人。有关此内容的详细信息，请查看 Rob Enderle 的这篇文章，了解认为矩阵模型应该停用的人。
在我最近访问过的许多组织中，我看到矩阵模型向一个或另一个方向倾斜，每种情况导致我提出的建议在如何部署 Project Server 和 Microsoft EPM 解决方案方面略有不同。 如果没有集中式 PMO，这将成为我的第一个建议。 我让一些组织与我联系，说他们想要使用 Project Server 只是为了降低许可证成本，但无意一起工作。 这没什么意义。 集中式企业项目系统的整体理念是将数据汇集在一起进行分析和显示，以便一起管理项目。 如果你无意执行此操作，请坚持使用单个桌面许可证。
在某些组织中，矩阵模型已被回归孤岛思维所取代。 当经济发生重大变化或外部刺激时，这种事情就可能发生。 当面临压力时，一些经理会以任何可能的方式争取生存。 我最近看到几个大型组织，部门负责人成功地将 PMO 及其人员描述为“冗余项目资源”，并游说将控制权归还给部门主管。
此类更改的结果与预期效果完全相反。 诚然，成本在短时间内下降，但那些工作是通过较短、更便宜的项目提高效率的人的效率损失往往在一段时间后反弹。 不过，对于大型组织，可能需要几个月甚至一两年时间才能实现这些影响。 同时，矩阵会崩溃，Project Server 的功能可能会受到抑制。
在更进步的组织中，新的重点是PMO，并对其能力的新发现尊重，甚至可能，在面临挑战的经济时达到新的权威水平。
还原 (或建立) 平衡
对于正在或即将进行 EPM 部署的用户，以下是你遇到的矩阵管理环境需要考虑的一些事项：
首先，查找矩阵中每个轴的流程和角色定义。 在进行面试时，寻找流程如何使组织更有效率，而不是更官僚化。 在看待角色时，请注意项目管理界经常谈论的经典“没有权力的责任”挑战。
如果你是从头开始的，你仍然可以在分层结构中找到可以采用的进程，这些流程对你很有价值。 如果可以在某个部门中找到整个企业可能采用的现有流程或过程，那么确认流程的来源会立即获得两件事：第一，一个部门中有一个不需要部署的进程。 它已被通过。 其次，在努力创建矩阵的第二轴时，你可以最终获得一个大盟友，其中涉及的部门负责人可以看到证据，表明你不打算放弃部门已经完成的所有工作。
如果你正在创建跨部门的流程，并且你必须，那么请考虑让那些可能感到被剥夺了自在的人参与。 例如，我最近正在协助一个组织，该组织必须创建跨部门资源容量规划流程。 不用说，部门负责人并没有对此想法感到欣喜若狂，因为他们觉得他们将失去对自己员工管理的某种程度的控制。 我建议成立一个项目组合指导委员会， (成员中包括那些将确定项目优先事项的部门负责人) 。 部门负责人不会觉得权力被从他们手中夺走：相反，他们将被纳入新的权力结构，以做出跨部门决策。 以这种方式工作，将那些本来反对 EPM 部署的人纳入其中，从而偏向了 EPM 部署的一个具有挑战性的方面。
最后，考虑对部署进行“精简”，并通过在层中工作来建立集中过程，而无需过度干预。 例如，我们正在开发一个矩阵在组织上非常强大的项目。 PMO 还处于起步阶段，大力反对组织结构并不理想。 建议不要从单个级别开始资源管理。 相反，组织会将资源管理部署为一个集中式流程，其中极少数用户直接附加或作为部门向 PMO 的使者附加。 资源将全部定义为泛型，目标不会是驱动每个员工启动的单个任务级别。 相反，PMO 将开始执行资源容量规划，方法是确定未来时段的聚合资源挑战，然后将问题移交给部门负责人进行管理。 我们预计，随着时间的推移，部门负责人将要求自己更广泛地推动 EPM 部署，以减轻他们自己管理资源冲突的工作。
总结
无论你是作为其他人的顾问部署企业项目管理，还是在自己的组织中部署自己的 EPM，你几乎肯定必须面对矩阵组织的挑战。 保持矩阵平衡是 EPM 和 EPM 系统（如 Microsoft EPM 解决方案）成功的关键挑战之一。
关于作者
Chris Vandersluis 是总部位于加拿大蒙特利尔的 HMS Software（Microsoft 认证合作伙伴）的总裁兼创始人。 他拥有麦吉尔大学的经济学学位，在项目控制系统自动化方面拥有30多年的经验。 他是项目管理研究所 (PMI) 的长期成员，并帮助创立了 Microsoft 项目用户组的蒙特利尔、多伦多和魁北克分会 (MPUG) 。 克里斯撰写的出版物包括《财富》、《重型建筑新闻》、《加拿大计算》杂志和PMI的PMNetwork，他是《项目时报》的常任专栏作家。 他在麦吉尔大学教授高级项目管理，并经常在北美和世界各地的项目管理协会职能部门发表演讲。 HMS Software 是 TimeControl 面向项目的计时系统的发布者，自 1995 年以来一直是 Microsoft 项目解决方案合作伙伴。
可通过以下方式联系 Chris Vandersluis： chris.vandersluis@hms.ca
若要阅读 Chris Vandersluis 与 EPM 相关的更多文章，请参阅 HMS 的 EPM 指南网站 (https://www.epmguidance.com/?page_id=39) 。