Matrix Management is Not the Root Cause

I was reading Ralph's post, Whose Fault Is It?, and I realized that if you don't know enough about management, you can misunderstand the root cause. Ralph's example is of defects in an iteration and how they were not detected early enough because the acceptance criteria were missing. The criteria were missing because the testers and the domain expert were not available because they were also on other projects. I was surprised to see the reason for people on multiple projects be “matrix management.” But I can see why technical staff thought that was the reason.

The real reason is that the managers are out to manage *their* efficiencies of staffing all the projects. The managers are not out to optimize the organization's throughput. (I don't know this organization, but many of my clients have been in this position.)

Matrix management–itself–is not the evil. Multitasking is the evil. And the root cause is a lack of project portfolio management.

In PPM, you don't commit to a project unless you can staff it. Fully. Period. No half-staffing. No 1/4 of this person and 1/3 of that person etc to make 1 FTE (full time equivalents). There is no equivalent for one person fully committed to a project.

Remember that, the next time your manager asks you to work on more than one project. “Which project am I fully committed to?” is a reasonable question.

Managers, if you feel the need to assign people to multiple projects, ask your manager which project is most important. Staff that one. Now ask about the next one. Stop staffing projects when you run out of people.

When managers optimize their work at their level, they are (almost never) doing this out of maliciousness. But if the organization rewards them for sub-optimal optimization, how can they not take advantage of it?

6 Replies to “Matrix Management is Not the Root Cause”

  1. Johanna, what you say is true (as always) as far as it goes. However, where matrix management is used, particularly in an environment that PMI in its candor refers to as a “weak” matrix, each functional manager is more or less free to pursue his or her (or their individual boss’s) priorities. These may not be the same as the organizational priorities. Therefore, I do not believe that matrix management is compatible with aggessive project portfolio management. Multitasking is doubtless a major problem, but we may be in a cart or horse situation here. Management by projects cannot sustain either functional or matrix organization well.

  2. I very much understand what Dwayne and Pawel are saying, but they don’t address the real question. The problem is not the inability to say “no” but not knowing how to say “yes, but.” As Johannna suggests, we need to order projects by priority and not exceed our capacity at any one time. Working on several projects simultaneously extends all projects and negatively impacts the quality of work.

    Emergency situations are much rarer than one thinks, and usually result from poor planning and/or poor risk management – managing in crisis mode. The best way to handle emergency situations is to ensure that they don’t happen. In some organizations, everything is “extraordinary.”

    If an organization is small, it just means that they can do fewer or smaller projects. There is nothing inherent about the size of the organization that requires multitasking or risk taking. The worst organization I ever saw for multitasking was one that had over 2,000 IT employees. The best was one that had six employees.

  3. The inability to say “no” to some projects is what I see as the root of evil here. Some people simply want to please everyone. It kills them to say “no” to anyone. Those people should not be placed in a decision-making position.

  4. I think you generalize too much. First, a project can be completed with different number of people involved. Sure, deadlines will differ but so very often deadlines are not the most important part of the project.

    Second, you sometimes face emergency situations when you need to find a group of people to exercise particular task which wasn’t planned in any way.

    Third, if you work for small organization you (as a decision-maker) can face a situation which is “to be or not to be” kind of story. I guarantee you people will take the risk even when they can’t say they’re completely ready to do so. They’re entrepreneurs after all.

    Of course I agree multitasking should be avoided whenever it is possible. I agree “full time equvalent” is not an eqivalent for a person commited to a project. As far as nothing extraordnary happens you should live without those. However saying definite “never” or applying “evil” label is oversimplifaction.

  5. I can’t fully agree with you, Jim. Actually each of situations I’ve given as examples happened in environments I’ve worked in.

    If you have strict SLAs with big customers which costs you much in money and even more in reputation each of high-priority issues they submit is an emergency situation. And you can’t predict when some error in 3rd party library would appear when system is in production for 2 years already.

    If you work for small (20-30 people) organization and you have a chance for taking really big project for mobile operator company won’t resign just because you need 15 people for the project and you’re able to afford for mere 8. You’ll do everything what is possible, including multitasking, to take the deal. That’s your chance to grow.

    I’ll stress once again: I don’t try to defend multitasking. The only thing I’m trying to say is you should’t have orthodox and definite take on that. I can think of examples where I could sacrifice much more than that.

    And yes, I think multitasking should be avoided.

  6. I think something often overlooked is that sometimes, assigning certain people to a project full time causes them to multitask just as much if not more than being assigned to multiple projects. If someone is filling multiple roles in a single project, that person will be multitasking. If they are doing similar activities across multiple projects, they are multitasking, but does the context switching of the different projects outweigh the context switching of performing different types of activities (requiring different skillsets, capabilities, etc.) on a single project? Full time project assignment also seems to ignore the fact that in a lot of organizations, some resources have capabilities that would be more valuable if spread across multiple projects. Seems to me there should be a balance of dedicated resources and specialty resources on any project.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.