There's one of those unqualified, unsubstantiated, and pretty much curmudgeon quotes floating around. You know the kind. "It didn't work for me so it can't work for you." It usually goes like this…
"I think it is clear that matrix management is not and does not work, leading me to conclude that it is one of the LEADING CAUSES for the rather abysmal "success" rate of projects in most organizations."
Of course, there are no units of measure here. No technical, business, or operational context or domain. No actual evidence or facts, other than personal opinion and anecdotes – a dangerous approach to process improvement.
So let's see if we can get all this anecdotal "theory" about matrix management to somehow come in contact with reality.
In the manned space flight business and nearly every other DoD, NASA, and DOE domain matrix management is the basis of Integrated Product (Project) Teams (IPTs). See O 413.3-18 as an example for the DOE context. NAVAIR and NASA have similar practice guidance.
http://www.directives.doe.gov/pdfs/doe/doetext/neword/413/g4133-18.pdf
So here's how it works. Let's pretend I'm the Propulsion Engineering Lead (yes it is rocket science).
I'm accountable for the design and development of the propulsion systems for our flying machine. This is critical concept - accountability - that is missed in most programs that go into the ditch. First Accountable, then Responsible. See http://herdingcats.typepad.com/my_weblog/2007/02/responsibility_.html for discussion on the RAM.
I report to the Program Manager - single line of responsibility flows down. But it flows down through the Systems Engineering Lead. I take direction from two people. The PM and the SE. They work with me in a matrixed manner since we're on an IPT organization. Now if they tell me conflicting things - say how much thrust is needed to hold orbit at Mars, then I need to convene a meeting to get this sorted out. Why, because I'm ACCOUNTABLE to make the propulsion system work. It doesn't work, the mission fails.
Now, the PM has bigger role than the SE's. So during the meeting, the SE's will make their points, I'll make my point (all supported by technical data, no opinions allowed here) and the PM will take all this information in and we – as a team - will have CONCURRENCE on the outcome. Remember we're an IPT.
Now, in walks the Safety and Mission Assurance (S&MA) Lead, http://www.hq.nasa.gov/office/codeq/ . And she disagrees with our little decision. So who trumps whom? Well in the manned space flight business S&MA has a powerful role. More powerful than the PM, because certifying launch readiness is a S&MA role, not a PM role. We're back to accountability.
All these accountabilities are defined in the Responsibility Assignment Matrix (RAM). The responsibility, accountability, communication, information (RACI) model drives how the IPTs work inside the matrix. In fact the responsibility part of the RACI is never addressed until the Accountability assignments are made, and then it's up to the accountable person to flow down the responsibilities.
So to attempt to get the theory to come in contact with the reality of how matrix management "can" work. Because that's what real PM is about, the realities of projects.
No doubt there are numerous examples of how to make it NOT work. But that's called a "false premise" argument. Just because you've never seen it work, or have some quotes from a couple of dead guys who say it can't work, doesn't mean it's not working every day on 1,000's of programs. It's proof by anecdote. NOT
It's critical here to look around for places matrix management does work and see if what they do is in anyway useful and applicable to your project environment. Maybe it's not. But that doesn't mean it is generally the case that it doesn't work. In fact just the opposite. If it works someplace else, you have an anecdotal working example. Try and figure out how they made it work. If you can't figure it out, or can't put to work what they figured out – we've found the problem – YOU. Learn from others, don't belief everything you read in 50 year old books. Ask deeper questions. Investigate multiple views. Try to determine if a concept or statement is in fact universal, or just an anecdote of failure in a specific domain.
This is a common mistake of inverting the search for improvement. "Doesn't work for me, can't work for you," is a weak approach to trying to increase the probability of program success.
