项目管理之强矩阵弱矩阵
强矩阵弱矩阵
1. 先来谈谈什么是矩阵型组织
按照职能划分的纵向领导系统和按项目（任务或产品）划分的横向领导系统相结合的组织形式。这种纵横交叉的领导系统构成了矩阵结构。矩阵型组织已广泛运用于行政组织和其他组织。
优点：矩阵型组织的优点是把职能分工与组织合作结合起来，从专项任务的全局出发，促进组织职能和专业协作，有利于任务的完成；把常设机构和非常设机构结合起来，既发挥了职能机构的作用，保持常设机构的稳定性，又使行政组织具有适应性和灵活性，与变化的环境相协调；在执行专项任务组织中，有助于专业知识与组织职权相结合；非常设机构在特定任务完成后立即撤销，可避免临时机构长期化。
缺点：组织结构复杂，各专项任务组织与各职能机构关系多头，协调困难；专项任务组织负责人的权力与责任不相称，如果缺乏有力的支持与合作，工作难以顺利开展。专项任务组织是非常设机构，该组织的成员工作不稳定，其利益易被忽视，故他们往往缺乏归属感和安全感。
2. 按项目经理权力大小及其它项目特点，矩阵型组织分为弱矩阵、平衡型矩阵和强矩阵。本次主要讲弱矩阵和强矩阵。
（1）弱矩阵：公司由各个部门组成，各个部门各施其职，按部就班，都有自己的主管，绩效由各个部门自己管理。
弱矩阵组织中的项目经理的角色更像协调人员而非一个管理者。对于技术简单的项目适合采用弱矩阵型组织。主要是因为：技术简单的项目，各职能部门所承担的工作，其技术界面是明晰的或比较简单，跨部门的协调工作很少或很容易做。
（2）强矩阵：
在强矩阵组织中，具有项目型组织的许多特点：拥有专职的、具有较大权限的项目经理以及专职的项目管理人员。项目经理的权限大于部门经理。对于技术复杂而且时间相对紧迫的项目，适合采用强矩阵组织。
而强矩阵适合产品难度比较大，一个部门不能完全理解一个产品，只有多个部门一起互相合作才能保证产品的质量，群策群力才能使产品完善（比如一个新产品，客户只给了大概的的需求，这个时候需求部不能完全理解产品，开发部也不能完全按需求做出东西等）。
一般公司规模比较小，一个部门的人员往往要夸部门做事情，部门与部门直接没有明显的界限，部门绩效都和软件产品及销量直接挂钩。一损俱损，一荣俱荣。
1. 案例介绍（转）：扯皮
以前我在一个国企，做一个比较大的项目（号称下一代系统），参与这个项目的人员达到200多人（哈哈，够大吧！），有需求部，开发部，DBA部，测试部和售后部等。
我发现这个公司每到开会的是经常因为一个小问题互相在会上扯皮，开发说需求文档写的不清楚无法实现，需求说开发无能，测试说开发不够仔细，开发说不能重现bug等等。总之不停的扯皮，各个部门不停的发牢骚都觉得自己干的很辛苦但还是被别的部门抱怨。
其实这个大公司的通病，尤其是体制内大公司的通病。因为我们部门不归你们部门管，我说你们部门有问题最好你们部门去改，我们部门就尅闲着了。呵呵。地区人都知道！
后来我从这家公司跳出来到一个小公司，发现这样的问题还真是少了，几乎没有互相扯皮的事，大家都你问我，我问你和谐的在一起工作，我到不是说这个小公司有多好，而是说这个问题在小公司挺难复现的。相信大家应该有点共鸣吧！
心得体会：后来想了一想，其实原因就是大家没有坐到一条船上！其实一个项目由好多部门完成，理论上大家是一个利益共同体，但是在制度上并不是利益共同体。说白了，对你的伤害不会造成我的伤害，人不为己天诛地灭。记得当初我从这个国企离职的时候领导问过我，对项目有什么想法，有什么改进措施，其实大家都知道有问题，但是想改正这个问题却变的很难。但仔细想想似乎也有办法，就是想尽办法无论在制度上还是在利益上都要把他们能成利益共同体，
比如开发和DBA之间出现矛盾，开发让DBA做一个表，DBA说不给做，让开发从别的表中去join这些数据，开发说这样做影响程序效率，再说开发一般sql语句不是很熟练，想这样做比较费劲，于是乎互相僵持不下。
我在想如果我是领导，我会把他们捆绑成利益共同体，遇到这样的问题，我会把开发和DBA叫过来说：我不管谁对谁错，我给你们一个星期来搞定这个事情，搞不定你们这个月的奖金别拿，搞的定你们这个月的绩效，我会给你们每个人加一分，如果提前完成加2分。（难道这个问题真的那么难吗？， 当然不是，是因为他们不在一条绳子上，所以不会去关心别人怎么干。我相信如果他们通力合作最多2天就搞定。）
其实这样做有点象韩剧里的男女主人公，第一集里他们各自的性格和职业完全不同，应该说是绝对不会有交集和成为朋友的可能，但是到了最后一集他们结婚了，呵呵，神奇吧，就是因为中间的那些集里他们俩被迫成为利益共同体，谁离开谁都不行，为了利益最大化，他们必须在一起，而且必须合作。
好了，就写到这里了，这只是我个人的一点感想，不能用对错来诠释，只能代表我看问题的角度
案例2：如何在强矩阵项目中做好部门经理
我现在是一个部门的部门经理，手下有三个以上的项目，人员二十多人，多数参与项目中。项目由项目经理负责。项目经理是公司竞聘或者任命，与我没有多大关系。人员和业务也许跨部门，由于项目经理在哪个部门，基本管理也就放哪个部门。
由于是强矩阵，项目经理有很大的权力，并且直接向公司负责，人员调配项目经理说了算，我届无权干涉，项目奖也没有我的份、但如果项目搞砸了，项目经理一拍屁股走人，多半是部门经理的收拾乱局，并且如果项目经理再说部门经理不支持。那后果很严重。
所以做好部门经理为项目经理负责就是一个难题
我经常告诉我的文员，做好管理，实际对我们是做好服务
做好服务，说简单很简单，但如何做好就有学问了。
第一就是项目经理不愿意干的我们干。项目经理没有时间招人选择人，我们帮他选，没有时间报销我们做，只要我们能做的都帮忙。
第二提前想好项目经理可能哪些没有做好。早做提醒。该做报表了，该组织会议了，等等
第三对项目经理不擅长的事，代劳。比如报销、采购、评审等等对外的协助或者帮着做
第四促进团队健康发展，对项目经理指使不动的人员协助肘思想工作，调离等
结论：PM应该有考核权或者有考核权重
PM应该有一定的考核权利，可以是PM全面考核，也可以考核放在部门经理季度考核但由PM提供素材、发言权。无论那种考核基本点是一致的，即部门经理主抓考核则PM会在其中有考核权重，项目经理主抓考核那么部门经理会定期考核员工(通常是季度考核)、年度排名以用于调薪。
项目经理有考核权之外，还可以有项目奖金，PM可以用奖金的杠杆调动部门经理临时的调整。结果很显然，项目成员会主动解决PM和部门经理双方的要求。对项目来说奖金要拿，对部门来说工资要涨，工作自然能消化掉。更重要的是，这个过程项目成员得到了类似项目经理的锻炼。
