In
response to the post “Collaboration Techniques for Moving Ideas & Decisions Forward” a reader on our Facebook page recently asked “How do you reconcile
between keeping everyone involved and keeping the team small?”
Highly
empowered and effective teams are the key to compete in today’s world of high
technology processes, six sigma quality and continuous innovation. We all have
roles in our organizations but it is the power of teamwork that makes our
endeavors successful. It takes everyone working together on a common goal to be
successful in Lean. Teams are the engines that deliver successful process
improvements.
Smaller
teams are more efficient than larger teams. Smaller teams means being nimble, flexible
and hungrier, which help them to be more customer oriented than larger teams
and organizations. Small and stable teams over a period of time, develop the
togetherness and bonding which large teams can seldom replicate.
Communication
and coordination overhead rises dramatically with team size. In the worst
possible case where everyone on the project needs to communicate and coordinate
with everyone else, the cost of this effort rises as the square of the number
of people in the team. That’s such a powerful effect, in fact, that a large
team couldn’t possibly hope to achieve the goal of everyone coordinating their
effort. But a small team could.
Smaller
teams have lesser decision lags, act faster, are quicker to change and provide
a good breeding ground for innovation. It’s easier for the smaller teams to
look in 'one' direction and communicate effectively than it is for any large
group. Also, there's less of pointing fingers, no working in 'silos' and
'escapism', given the small size of the team, which brings in more accountability
and ownership. All of this produce more value to the customers, better
profitability for the organization and more purpose for the people involved.
Getting
the buy in from those who are not participating on the team is important for
sustaining the improvement. When you are
part of team you are involved in the solution.
For those who are not we need to make them aware of the improvements the
team is making. If you don't they will
naturally resist the improvement.
It
is the job of those on the team to share with those who are not. For instance
perhaps you have a multi shift operation and you have an operator on second
shift participate on the team. It would be their responsibility to share what
the team is thinking and the solutions with their second shift colleagues. Any
feedback from their colleagues can be brought back to the team meetings for
consideration.
Also,
at the end of the team activity there should be a readout to a larger audience.
This presentation helps to document and spread the knowledge to the area
affected as well as others. Some times this can also take the form of an A3.
Many organizations even share these visually in their facility for all to
see. And of course there should be some
standard work coming out of the improvement to train everyone to the new way.
Keep in mind this is the new standard and not the standard forever.
The
last thing I would add is that this concern for involvement only occurs when
the activity is large. As I have said
many times Kaizen is not about big events but rather small continuous
improvements. In this way small improvement is less disruptive and easier digested.
While
we can’t involve everyone in every activity because of efficiency and
practicality the methods above can be used to keep them informed. Smaller teams
are more efficient but we also know there are many sizes of improvement
activities along the Lean journey. Communication and education are the single
best levers for change the speed of improvement. So the best I can offer is to keep learning
and deducing to practice with an eye for improvement.
Tim,
ReplyDeleteGreat post. Where did you come up with the cost of the coordination effort rising as the square of the number of people in the team?
Dan, A study done by consultancy QSM in 2005 looked at 564 information systems projects done since 2002. (The author of the study claims their data for real-time embedded systems projects showed similar results.) They divided the data into “small” teams (less than 5 people) and “large” teams (greater than 20 people).
Deletehttp://www.qsm.com/blog/2012/part-ii-small-teams-deliver-lower-cost-higher-quality