Teams. It seems like such an obvious part of project life.
Or, is it?
Recently, I’ve been noticing some things about project teams that trouble me.
Here are some descriptions of a team:
- A group of two or more people with complementary skills who are committed to a common purpose and approach for which the team holds its members mutually accountable .
— Katzenbach & Smith, 1993
- People working together in a committed way to achieve a common goal or mission. The work is interdependent and team members share responsibility and hold themselves accountable for attaining the results.
— MIT Information Services and Technology
- A group in which members work together intensively to achieve a common group goal.
— Lewis-McClear & Taylor 1998
Note in the first and third description that a team is NOT just a group. A team’s members are “mutually accountable” and have a “commitment” to a “common” purpose and work together.
Great. So what’s troubling me? I’m seeing more project groups rather than teams.
I”m seeing groups, that are supposed to be teams, parcel out the individual work, have the individuals work pretty much on their own, have weekly meetings (often grudgingly and under protests of wasting time), then doing some kind of periodic collection and collating of the individual work products.
Now, I’m not suggesting that groups can’t be productive. In fact, groups can be more appropriate in certain situations than teams (perhaps you can think of some?).
No, what worries me is that by confusing groups for teams, we are accepting a less effective approach to solving problems and creating value.
In project management classes and in some of my project management consulting work, the participants are assigned work to do in “teams.” I’ve noticed that many of these proto-teams move almost immediately to a divide and conquer approach, coming up with tasks and assigning individuals work. Most of these groups do a competent job. Most are pretty satisfied.
… and then there are those groups that have problems. Can you imagine (remember?) what some of these might be? We can talk more on these problems in later blogs. What I find compelling is that many of these groups with early problems turn out be the ones that excel in the long term.
Perhaps paradoxically, the early problems allowed (forced?) some to confront barriers to team formation.
One of those barriers is what Patrick Lencioni — The Five Dysfunctions of a Team: A Leadership Fable — calls the absence of trust. The divide and conquer approach often does not require a great deal of trust – so long as a basic level of competency is maintained. Why struggle through a barrier if you don’t have to?
Those groups that do confront and breakthrough the barrier, however, often go beyond competency and do extraordinary work. These teams are also more likely to report higher satisfaction and morale. They often note the intensity of interaction as a key contributor to that satisfaction and performance.
… and yet — when asked how common it was to experience this teamwork in their workplace, very few report it to be common. When asked why, lack of time comes up often, as does non-colocated team members.
Are we too often sacrificing the potential of high value coming from true teams in the name of time efficiency? Are we confusing investment for cost?
I’m hopeful we can discuss this more this week.
6 thoughts on “Teams? Why not just have a meeting?”
Pingback: سیاره مدیریت پروژه فارسی » Blog Archive » Teams
If you are going to have a meeting you might want to use these scrappy approaches to making sure it is effective and efficient, even with a tough crowd: Scrappy Meetings that ROARR Rubber pigs, chickens, tractors and koosh balls. Yes, I seriously do use these techniques, even with senior executives, and, yes, they do work.
Don’t have a sense of humor? Then how in the hell are you surviving as a project manager?!!
– Kimberly Wiefling, Author, Scrappy Project Management (soon to be translated by Nikkei Business Press into Japanese – July 22, 2009 launch party in Tokyo!)
Loyal brings up some really interesting points about virtual teams. To make virtual teams work companies need the right (infra)structure and processes in place. Many organizations rush in to create teams without doing the ground work; teams are setup for failure.
I’m glad you posted your thoughts on this topic Alan! This is such a huge problem in most organizations. Trust and communication are big issues particularly in matrix organizations and/or agile environments. I believe a project should be started well to move smoothly. What does this mean ? Use the Project Charter. The Project Charter establishes the project goals, requirements, timelines, issues, risks, as well as roles and responsibilities upfront. Each project member could then prep for a project kickoff meeting based on their roles and responsibilities. The presentation really is just the team members’ approach to their tasks in the project – who they plan to interact with and how. This creates a solid base for the project and its team members. Thereafter, daily scrums or weekly meetings help keep the communication lines open along those lines.
Terrific approach, Anuradha. Charters can form that critical foundation to a good project. Starting well requires some hard work and the process often exposes stakeholder conflicts. Might as well admit it and get started dealing with them. Courage!
Thanks for those great ideas, Loyal. You are so right about virtual teams. I’m thinking that we may be at a point where the communication/collaboration technology available to us can no longer be used as an excuse not to build our teams.
Very interesting topic, Alan. I completely agree with your assessment that groups do not perform as well as teams. As you point out, some elements of the two are the same, i.e., working to a common goal and complimentary skills. The differentiator is indeed interdependence. I’ve seen this manifested in teams where members consult each other on problems or where during project reviews everyone feels comfortable offering and accepting advice for alternative ways to accomplish a task. This does not happen immediately in new teams, but forms over a well-defined series of stages. It is a great experience working on a true team as the “sum-of-the-parts” is indeed “greater-than-the-whole” and great things are accomplished. Groups of people who work independently do not get this benefit of interdependence and tight intermingling of information, ideas and trust.
The model I’ve used for much of my career is the old Forming-Storming-Norming-Performing sequence that all true teams experience. According to Wikipedia, Bruce Tuckman developed this model back in 1965 and it still applies today. Based on his model, I would say ‘groups’ get stuck at the Forming stage as they never get the chance to work interdependently on tough problems to create the tension and intense interactions that cause the next stages to happen.
And, speaking to the reason some people site for the lack of teamwork being a lack of co-location, I can see why this might be blamed. But, it is not virtual teams per se. The prerequisites to achieving a highly effective virtual team are: a strong virtual team leader; the right tools and practice with them; and, perhaps most importantly, a project structure that encourages interactions. People will find ways to cross the virtual barriers to get their jobs done. Besides, having the best people work on a project no matter where they are located generally more than makes up for any inefficiencies of working virtually.
Great topic, Alan!