弱矩阵下提升项目经理的影响力，完成强矩阵项目经理之事

（一）弱矩阵型组织

本词条缺少概述图，补充相关内容使词条更完整，还能快速升级，赶紧来编辑吧！
弱矩阵组织(weak matrix organization)形式是矩阵型组织的一种形式，类似职能式组织形式的一个极端。在这种组织形式里，项目可能只有一个全职人员，即项目经理，项目成员不是直接从职能部门调派过来，而是利用他们在职能部门为项目提供服务。
弱矩阵组织结构，基本保留项目的职能组织结构的大部分主要特征，弱矩阵组织的应用但在组织系统中为更好地实施项目，建立相应明确的项目管理班子。项目班子由各职能部门属下的职能人员或职能组所组成，这样针对某一项目就有对项目总体负责的项目管理班子。然而，在弱矩阵组织结构中并未明确对项目目标负责的项目经理，即使有项目负责人，他的角色只不过是一个项目协调者或项目监督者，而不是一个管理者。
弱矩阵组织保留了职能型组织的许多特点，项目经理的角色更像协调人员而非一个管理者。
对于技术简单的项目适合采用弱矩阵型组织。主要是因为：技术简单的项目，各职能部门所承担的工作，其技术界面是明晰的或比较简单，跨部门的协调工作很少或很容易做。

（二）案例：弱矩阵组织结构中项目如何开展

某大型企业希望年底前完成生产管理系统的开发工作，该项目由企业IT部门完成。该项目的组织结构是弱矩阵组织，组织结构与权力关系简要描述如下：
0层：部门老总(职能经理兼名义上的项目经理)
1层：科室经理
2层：真正的项目经理;技术经理
3层：开发人员。
具体情况：
1、层科室经理拥有所有资源的调配权，2层项目经理与科室经理不和;
2、层项目经理与2层技术经理关于项目技术实现方面的意见不统一;
3、项目团队在未与用户沟通需求的情况下就开始概要设计;
4、项目无成本管理、质量管理和风险管理;
5、用户期望的项目范围与项目团队计划年底实现的范围不符;
6、项目经理随时有可能被0层部门老总抽调到其他项目上，对该项目的精力有限。
问题，如果Z在这种情况下被临时任命为项目经理，如果将该项目扶上正轨。

分析：先对项目进行预估其成功的若干资源和风险，利用项目经理身份和领导进行充分沟通，索取这些资源。若资源要不到，至少让领导知道在现有情况下，项目可以做成什么样子，取得和领导在资源不足情况下项目成果交付的共识。

分析：在项目启动之前，项目经理应该制定非常详细的人力资源管理计划， 沟通管理计划，成本控制与质量保证控制计划，风险评估与反应计划。 所有这些计划是项目管理计划的一部分。 职能经理（科室经理）应该是批准项目管理计划生效的签字人之一。当科室经理签字之后。科室经理必须履行合作支持的职责。在沟通管理计划中， 定期开会汇报工作情况是其中主要内容。项目经理在定期会议中设确定项目开发的成果符合用户标准与需求，分享客户反馈与项目团队。项目开发经理对项目产品或者服务的大纲必须认可（以签字的形式）然后再领导团队开发。 就不存在“货不对板”的问题。沟通是项目经理工作中主要任务。

分析：在弱矩阵组织结构中， 项目经理并没有多少调配人力资源的权力。职能经理（在这里叫科室经理）拥有人力资源调配的权利。
在项目启动之前，项目经理应该制定非常详细的人力资源管理计划， 沟通管理计划，成本控制与质量保证控制计划，风险评估与反应计划。 所有这些计划是项目管理计划的一部分。 职能经理（科室经理）应该是批准项目管理计划生效的签字人之一。当科室经理签字之后。科室经理必须履行合作支持的职责。在沟通管理计划中， 定期开会汇报工作情况是其中主要内容。项目经理在定期会议中设确定项目开发的成果符合用户标准与需求，分享客户反馈与项目团队。项目开发经理对项目产品或者服务的大纲必须认可（以签字的形式）然后再领导团队开发。 就不存在“货不对板”的问题。沟通是项目经理工作中主要任务。

分析：1、建立项目团队，事先与高层领导沟通存在的困难，充分利用领导的参照力；
2、多向2层请教；
3、及时与1层人员汇报好消息，争取资源；
4、与0层人员保持良好沟通。时不时搓一顿
这主要就看你怎么运用领导力了 

  

分析：1.首先得弄清项目背景.即该项目在0层,1层眼中占多大比重?
2.得打通一层,毕竟他对所有资源有调配权限,对该项目需要他给资源.工作归工作,个人感情合不合放在一边.不行得找0层协调处理.必须要满足项目的资源要求.
3.要明确一种项目实现的方式: 采用瀑布/敏捷/RUP 等等. 得在组内统一认识,哪一步该做什么事情.
4.确定好项目范围及计划.

分析：1.与部门老总沟通，确认可以做的事情，
2.与客户沟通，确认需求，
3.与科室经理沟通，统一认识，制定项目管理计划，形成签署文件，
4.其他的看具体情况操作

分析：1.强化项目沟通管理，任何一个组织中，沟通都是最重要的。包括与客户的沟通（项目范围、需求信息等），同时包括内部沟通与科室经理及技术经理的沟通。
2.加强项目需求管理，需求不清晰的情况下做后续的工作，变更是无可避免的事情。
3.加强项目计划管理、及目标管理，明确每个事情的时限、目的。

分析：首先在弱矩阵组织形式的项目中，技术经理(项目经理)的权利是比职能经理小的，在这种情况下，技术经理(项目经理)是既无人权(调动人员/资源)也无财权(成本)。只能管理进度。在这种情况下，技术经理(项目经理)需要充分发挥沟通、人际关系、个人魅力来和职能进行进行谈判，以能够从职能经理或者其他项目获得本项目需要的资源。
如果还是不能解决，就需要向高层或者发起人求助。

分析：1 制定项目章程
明确项目的目标,对项目输入有充分的了解；明确责权,需要项目经理明确自己有哪些权力,资源可以利用，特别是要分清楚与职能经历之间的合作分工关系；识别干系人,对项目开展过程中相关的干系人进行识别,充分了解他们的需求。
2 制定项目开发管理计划
做好项目的范围管理，收集分析需求，在此基础上，创建WBS；
做好项目的进度管理，根据制定的WBS及其它信息，明确需要开展的各项开发活动，排列好各项活动的先后顺序，估算所需的资源、时间等，制定可行的开发计划；
做好成本管理，估算和制定项目预算；
规划项目、人力资源、沟通风险质量管理；对可能存在的风险进行分析，并制定相应的应对措施；
做好采购、干系人等。
3 协调各方，做好项目的执行工作
在项目开发过程中，指导和管理项目的各相关工作；实施质量控制，明确项目团队中的成员，做好沟通协调；
落实好采购、干系人管理。
4 做好开发过程的监控
监督好项目的执行过程，必要时实行整体变更控制；
确认项目范围；控制好范围、进度、质量、风险、沟通、采购的控制；管理好干系人；
5 收尾

分析：1、项目目标请部门领导协调，统一项目组思想；
2、做好事前控制，发布项目组内部成本管理计划、质量管理计划、和风险识别矩阵；
3、加强客户沟通工作，必须在充分沟通的情况下完成概要设计和需求说明书

分析：1、与科室经理不合是个人人际关系的问题，只能私下沟通，增加感情。声明公私分开，工作内容还是做到目标一致，利益一致。
2、充分尊重技术经理的意见及权威，完全听取意见后再发表你的看法，给技术经理充分思考的时间，还要告知利弊及影响。
3、必须要求产品部明确需求，进行业务分析会，大家对需求理解一直并同意接受需求。
4、具体项目具体看待。
5、范围不符，重新调研，重新计划，但需确保产品的大体方向不偏差，符合产品规划以及市场定位。
6、必须判断项目的优先级，产生的价值，然后再分配项目管理时间。并需要和干系人充分沟通。

分析：第一，该公司的成员分工及职责不明确，高层应开会讨论并定义工作内容；
第二，项目经理应起到项目操作的控制性，宣导并规划项目的实现性；
第三，缺少公司文化和精神核心，导致员工间缺乏凝聚力

分析：1.范围，成本，风险，质量无一考虑在内，这是一个完全失控的项目
2. 首先需要指定项目经理，再按正规项目管理流程去重新开展此项目，之前的活动只能看成是沉没成本了。

分析：关键是统一思想，我们也是弱矩阵，项目经理权力很小，部门经理掌握所有资源，项目开始时，项目经理与部门经理才沟通好，确定项目目标是什么，就是这个项目的重要性有多大，以后碰到资源冲突的时候，轻重缓急，项目经理心中有数。另外就项目计划和资源计划与领导达成一致，项目进展时多沟通，确保按计划完成，对于不确定项目，一定要多留Buffer,要不然就会把自己给逼死。

分析：注意几点。
首先，不管什么项目，一定要有相应管理规范。对于项目的3个目标成本和质量（先不考虑风险）的管理一定要有。
其次，记得没错的话，弱矩阵中项目经理通常叫做项目联络人，其主要的工作就是传递任务和收集进度，协调相互管理。那么此项目的项目经理也应该在沟通协调方面加强。
最后在弱矩阵中，项目经理（协调人）本身职责和权力所限，很难调动和约束人员，那么在项目执行过程中，一定要明确指定项目计划和加强过程产物监控。不好做的话，多组织会议吧，找主管领导在场旁听，或者多群发邮件吧。给上面多传递点声音

分析：首先，解决冲突，对于项目干系人不和是阻碍项目发展的不利因素。是否可以根据实际问题减轻或者转移冲突。对于团队中，团队建设以及有效的沟通尤为重要。
第二，积极主动的收集用户需求
第三，根据组织过程资产参考或者指定成本、质量以及风险管理计划
第四，查阅项目范围说明书，或者分析为何用户期望范围与团队计划实现范围不符。满足用户期望。
第五，查阅人力资源计划，或者与职能经理谈判获取人力资源

分析：我认为这个项目最大的问题是责权不明。项目干系人有意见分歧是正常的。但在这个项目里，科室经理、项目经理、技术经理互不隶属，且有各自的关注点。
在弱矩阵组织里，行政地位较低的项目经理很难与科室经理抗衡。
可行的一点是，项目经理与科室经理、技术经理、团队成员进行正式的会议，并讨论项目执行中的相关问题，用会议纪要的形式记录达成一致的内容和不能达成一致的问题以及各方意见。将会议纪要以邮件或汇报的形式，向更高一层的领导汇报，请求定夺。

（三）弱矩阵项目管理实践：提升项目经理的影响力

案例：某一制造型A企业，产品具有生产周期长、跨部门沟通需求大、后期安装仍需跟客户进行大量的跟踪、协调服务工作等特点，原先采用的是职能式组织架构，但随着业务发展，公司内部深切感受到了职能式组织架构造成的部门壁垒高，跨部门流转慢，项目周期不可控等缺点。因此，公司成立了项目管理部，设立项目经理岗位，负责对材料采购、产品生产直至后期安装等工作进行全面负责，从而组织架构也就变成了矩阵式。

然而，项目超期严重、各部门各自为政、项目质量与成本不可控等问题并未得到根本性的解决，问题究竟出自哪里呢？

【解析】
尽管该企业的组织架构做了调整，但是矩阵式组织架构大致分为“强矩阵”和“弱矩阵”两种，目前变革后的A公司采用的是弱矩阵式的项目管理架构。
所谓的弱矩阵组织结构，是基本保留了项目的职能组织结构的大部分主要特征，但在组织系统中为更好地实施项目，建立相应明确的项目管理班子。然而，弱矩阵组织架构下的项目负责人并非严格意义上的项目管理者，而是一个项目协调者或项目监督者。
判断组织架构属于“强矩阵型”还是“弱矩阵型”，最主要的依据是项目经理与各个职能部门经理是如何分享项目的控制权和资源的调配权。
在弱矩阵型的项目组织中，项目经理对项目成员的薪酬、绩效评估、晋升的影响力极其有限，甚至基本无影响力。
在A公司里，项目经理的现状更多地是将各部门估算的工作计划整合成一份大计划，并设置一些项目里程碑进行宏观管控。当跨部门工作产生冲突或项目进度受到影响的时候，项目经理负责出面沟通与协调，重点在于保障各部门之间的接口对接顺畅而已。
项目经理更多地是起到提醒督促的作用，而非真正意义上的项目管理职责。由于项目组成员不属于项目经理协调，各个成员还是更多听从部门经理的安排，在应对突发事件或临时变更的时候，项目经理往往会感觉到有心无力。
由于组织架构造成的项目执行力不足之外，项目经理的胜任力不足也是重要因素之一。
项目管理部作为新成立部门，对其定位、工作重点以及项目经理应该具备的能力素质没有清晰的界定，同时对项目经理的激励引导不足。
总而言之，当前A公司面临的问题可以归结为“项目经理影响力不足”，这也是弱矩阵型项目管理实践中普遍存在的问题。 

【解决对策】
影响力的来源主要有以下几种：
职位影响力：
通过升职、授权、改变组织架构等方式实现。
优点：短期可执行性很强
缺点：没有其他影响力的配合，会“口服心不服”的现象
专业影响力：
知识丰富程度以及解决问题的能力。一种自然的影响力。
优点：从心里信服、尊敬，影响力稳定持久
缺点：需要大量精力时间投入，短期可执行性弱
资历影响力：
经验、资历对他人造成的影响。也是一种自然影响力。
优点：效果比较稳定和持久
缺点：没有任何捷径可循，只能通过时间的积累，短期可执行很弱。
情感影响力：
通过建立良好的人际关系对他人造成的影响力。也是自然影响力
优点：被影响人主动、自愿地配合工作，持久稳定，但不如专业和资历影响力。
缺点：主要依靠管理者情商，而情商的提高非常困难，短期可执行非常差
品格影响力：
通过优秀的品格为大家树立榜样，赢得大家信任。
与情感影响力相同，品格影响力一旦定型，很难通过后天的努力进行提高或转变，因此短期可执行性非常差。
品格影响力非常重要，可以说是一个人是否有真正的自然影响力的必要条件;如果一个人没有品格影响力，那么他将无法赢得他人真正的信服与尊敬。

【关键举措建议】
1.调整组织架构，增加项目经理职位影响力。项目管理部直接向总经理汇报，比其他部门高半级。同时，项目经理在实际工作中注意多利用“工作协调单”、“备忘录”、“会议记录”，选择邮件抄送等书面方式开展工作，给其他部门带来良性压力，便于工作开展。
2.完善制度流程，明确跨部门接口。从公司发展角度，通过制度流程明确界定相关部门权责，有助于公司运营更加顺畅、高效；另一方面完善的制度流程能减轻项目经理的协调工作量，减少项目经理与其他部门起冲突的可能性，便于项目经理利用情感影响力。
3.加大授权力度，提高项目经理对项目成员的利益影响。建议给予项目经理对其项目成员的间接绩效考核权。

（四）以弱矩阵项目经理之力，行强矩阵项目经理之事

作为项目经理，大家应该都清楚组织结构的类型包括职能型、项目型及位于这两者之间的各种矩阵型结构。不同的组织结构影响资源的可用性和项目的执行方式。在一个弱矩阵型组织中，项目经理通常只是一个联络员或协调员的角色，不能亲自制定或推行决策。
不能决策，自然就不能充分体现价值。怎么办？
作为项目经理，改变组织结构怕是不现实的，但是，能否以弱矩阵项目经理之力，行强矩阵项目经理之事呢？能的。具体怎么做？两个字，借力。

首先，向外借老板之力，让老板替你“打工”。
把老板作为资源，说服老板支持咱自己的决策，让老板作为项目的名义负责人，发起项目。以邮件的形式做项目信息沟通，监控进度。老板永远是邮件的主抄送人，适时的请老板在邮件里发言，支持项目实施。
具体如何操作呢？举两个例子。
第一个例子：
我们公司有一个USB虹膜模组，一直定位成供客户做功能验证的demo，未考虑过产品化。一个项目契机，我参考其它产品的设计，想到了一个可以让这个虹膜模组向产品化迈进一大步的方案，建言老板实施。老板觉得方案不错，来了句：“可以试试”。
带着老板的口谕与硬件部总监简单沟通了实施方案，觉得可行。一封正式邮件给到硬件部总监，请其安排实施，再让老板给指示一下，老板一封确认邮件，这个事情就启动了。
事实证明，我在这个虹膜模组产品化上的决（tui）策（dong）是正确的。后来又推动了一次升级，完成产品化。后续刚好有一个项目需要批量采购这个虹膜模组，因为前期的产品化积累，为顺利实施这个项目并最终拿到订单奠定了基础。作为项目经理，自己的价值自然得到了公司的肯定。
第二个例子：
我们公司有虹膜应用云服务，我希望通过实际的项目积累云服务类项目的实施经验。另外，也希望因为自己的推动形成公司的过程资产，为以后实施类似的项目奠定基础，体现出自己的价值。因此，一直希望推动公司开发一整套虹膜移动终端与云服务器交互的APP，实现基于虹膜移动终端做虹膜数据采集、认证功能。
因为实施其它项目的契机，需要用到云服务，于是借机跟老板提出开发一整套虹膜移动终端与云服务器交互的App，但是直接被否掉了。因为公司实施虹膜应用云服务项目的模式是，将云服务器API接口和虹膜移动终端的基础SDK交付给客户，由客户自行完成虹膜应用软件开发。
在积累经验、体现自身价值的需求的驱动下，在合适的契机，我又尝试了几次，终于有一次老板被说动了，来了句：“也行，那你做一个吧”。
有了这句话，紧接着我就发了一封邮件，指定一个产品经理，讲明开发APP的目标，让产品经理定义产品，设计原型。邮件同时发给老板，请老板做指示。老板回复邮件，让产品经理支持做一下，OK，事情启动。
让老板替你“打工”就是这样简单，在老板的支持下，自己的决策得以实施，形成的一个个过程资产，就是自己的价值所在。敢于决策的项目经理，就像亮剑里的李云龙一样，老板用起来也会很顺手。
当然，这种借力的方法，有一个愿意授权、愿意成全下属的好领导很重要。
其次，向内借个人影响力，让协作者愿意合作。
影响力可以来自专业力和亲和力。
如何打磨专业力呢？多维度学习行业知识，形成自己的专业力，让协作者信服，从而愿意合作。以我从事的虹膜识别行业为例，对虹膜成像系统的清晰理解，对软件开发关键活动的清晰认识，让自己比开发更懂成像系统，比图像工程师更懂软件，从而形成自己的专业力。
如何打磨亲和力呢？通过一些日常的“礼尚往来”，传递自己的亲和力，与协作者建立互助关系，为合作增加助力。我的一些做法是，在没有项目经费的情况下，帮忙安卓工程师们买点他们开发经常使用的安卓线、TypeC线等耗材，帮忙买个百度网盘的超级VIP账号，帮忙处理一些项目上产生的报销等。这些看似没什么的行为，效果还不错，为合作增加了助力。
借力，就是我“以弱行强”的方法，你还有什么更好的方法呢？欢迎你留言分享，一起过过招吧。