Go to...

Organizing Around Teams

teamsSeveral 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 they had 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.

In our Enterprise Agile Workshop that we offered this last Friday, we explain how organizing around teams allows you to estimate, plan, and deliver at a more accurate level of granularity.

HT: LitheSpeed Enterprise Agile Workshop
HT: You can also read this post on the LitheSpeed blog!

About Derek Huether

I'm Vice President of Enterprise Engagements at LeadingAgile. I'm super focused on results. But I also take the hand waving out of organizational transformations. I come from a traditional PM background but I don't give points for stuff done behind the scenes. The only thing that counts is what you get done and delivered. Author of Zombie Project Management (available on Amazon)

2 Responses to “Organizing Around Teams”

  1. June 20, 2011 at 7:18 pm

    This totally makes sense and sounds very easy. In big companies reality looks though very different. People have lots of daily business that maybe has piled up over time. I would love to hear more about how to use scrum in an enterprise. Maybe you could devote a post or two to that topic: Scrum in big companies for non software engineering projects.

    • Anonymous
      June 22, 2011 at 1:43 am

      I could probably devote a few posts on Enterprise Scrum, but not all at once. We presented 8 hours of material on the subject the other day at the workshop. There are certainly challenges that arise when you mix tactical and strategic goals. That challenge becomes more visible the bigger your enterprise.

      On the topic of Scrum in big companies or non-software engineering projects, you should seek out works of Jeff Sutherland. I heard Jeff speak a few months ago at an APLN meeting. He talked about using Scrum in big companies or government. Here’s a recent interview

Leave a Reply

Your email address will not be published. Required fields are marked *