Matrix

Organizing Around Teams

Several years ago, I was working with a client who was obsessed with keeping resources (in this case, people) 100 percent utilized. The client boasted that he had a strong matrixed organizational structure and everyone was a member of multiple teams working on multiple projects. When I came on board, I noticed that people were spread extremely thin between the projects. There was a lot of work being performed but very little was getting done. How can you make real progress if you have multiple managers asking you to deliver that high priority something for them? How can you make real progress if you have to constantly shift gears and go in different directions? In theory, having a matrixed organization sounds really great. Resources can potentially be utilized up to 100 percent. In reality, the goal is not utilization of a resource. The goal is throughput and delivering something of value. In the end, having a matrixed organization made people busy but it did not make them more productive. Perhaps managers felt more productive because they essentially had more people to manage. But again let me stress, the goal is not to manage people. The goal is to deliver something of value. When I did my original assessment, there were two common complaints. First, team members didn't know who to take direction from. Two, team members never seemed to have time to just focus on one thing and get it completely done.

Status quo organizes teams around projects

  • Projects are initiated
  • We beg, borrow and steal, looking for the right people to work the project
  • We pull a few hours from here and a few hours from there
  • Everyone is "fully utilized" by working on several projects at the same time
  • When the project is completed, we release some portion of each person’s hours back into the pool and start again
  • Endless resource-management frustration

Bring the right projects to the right teams

  • Teams focus on one or two projects at a time and get them done quickly
  • Management prioritizes projects and queues them up for the appropriate teams
  • May need to move a few people around but hopefully not many and not constantly
  • Much of the resource management problem goes away
  • We also get fewer simultaneous projects, more focus, and more speed of delivery

Once we got people grouped into several (cross-functional) teams and then collocated in team areas, we actually started making deliveries on projects. The PMI would define this reorganization as being projectized. But, let us not forget that this is about the teams and creating an environment in which they can deliver value.

Organizing around teams allows you to estimate, plan, and deliver at a more accurate level of granularity.

 

Defining Organizational Structure

organizational influence

Over the last 15 years, I've seen a lot of interesting ways an organizational structure will influence a project.  I've worked in projectized, functional, matrixed, and even composite environments.  These terms of management are interesting to me because I had to understand the definitions as part of the PMP exam.  At my last engagement, ironically, my boss went so far as to use Wikipedia to get the definition for Matrix Management without realizing I was one of the contributing authors to the page.  Personally, I would prefer to use the PMBOK.  I've noticed quite a few people have modified the Matrix definition on Wikipedia.

Today I was reading the PMBOK (I'm strange like that) reviewing differences between the 3rd and 4th editions.  What I noticed were definitions (in the glossary) for each organization structure with the exception of composite.  Composite, by the way, is new to the 4th edition.  Perhaps PMI will take notice and add it at a later date.  Below you'll find figures and definitions of each.

projectized
functional
matrixed
Composite

Responsibility Assignment Matrix

As a graphical depiction of a more detailed perspective of responsibilities, the responsibility assignment matrix should reflect assigned responsibility by functional role for key project deliverables.  An example of roles detailed below could include (1) Project Manager, (2) Project Sponsor, (3) Implementation Manager, (N) Team Lead

Project Deliverables Role 1 Role 2 Role 3 Role N
WBS 1.15.10.1300 - Project Charter E A C I
WBS 1.15.10.1301 - Project Schedule E A,C A I
WBS 1.15.10.1302 - Project Budget E A,C E I
WBS 1.15.10.1303 - Status Reports C C A E
Legend E = responsible for execution (may be shared) A = final approval for authority C = must be consulted I = must be informed

I use this matrix in a few of my project artifacts, to include the Lessons Learned. You can download a free copy here

Irony

The other day my superior asked me to take on responsibility within the department in a way that conflicted with my original role.  Back in October 2007, I was hired as a functional manager.  A few months ago, the department hired its first project manager.  Our department never defined itself as projectized, functional, or matrixed.  Because there were no PM's, I knew my role was clearly functional and so was the organization.  The management team knew I had a lot of experience in project management and recently asked that I start managing deliverable as a project manager while still acting in the role of a functional manager.  I explained that there would be conflict, if I indeed agreed to do that.  I was then told the department was now "matrixed".  I politely clarified by adding that upon hiring "a" project manager, we were a weak matrix.  All of the power still rests with the functional manager(s) and the project manager is merely acting as a facilitator.  I added if they wanted the project manager(s) to hold a majority of the power, that is known as a strong matrix.  There was silence.  The response was, "then we want our organization to be a strong matrix". A few days later, we had a team meeting.  My superior brought me and my team into the conference room and handed everyone a printout from the Wikipedia website for Matrix Management.  I was silent as he attempted to explain to the team that they should now be getting direction from the project manager(s) and that I would be working in a more supporting capacity.  They all looked a bit confused so I walked over to the white-board and offered an illustration of what model we were and what model he was proposing.

What I didn't tell them (or my superior) was that I am one of the contributing authors of the Matrix Management definition page on Wikipedia.