Is Project Teamwork Overblown?
Teamwork is a very popular topic in the project management conference and consultancy
circuit. Just put the word "Team" in your title and you'll be sure
to draw a crowd. Why? Because the majority of people like and want to get along,
enjoy the camaraderie of togetherness and naturally think of team work as fun.
And of course, there is no lack of material on the subject, having been a part
of mainstream management research and popular writings for decades — well
before the serious study of project management.
So it is relatively easy to concoct a session about teamwork and team building,
throw in "project" and "project management" a couple of times
a lo, we have yet another lecture on the subject. But does this sort of thing
add value? Mostly not. For real value, try Vijay Verma's landmark book series
"The Human Aspects of Project Management", especially Volume Three
— Managing the Project Team", Project Management Institute, 1997. Verma
conducted an extensive literature search and applied his project management experience
to what he found. These books are a must-read for anyone who wants a thorough
understanding of the human aspects of project management.
So, what's the problem? According to the theorists, team work
depends on a group developing understanding, trusting and being comfortable with
one another. And this takes time. In fact the theorists further submit that there
are no less than five stages of team development characterized by: "Forming;
Storming; and Norming" before the team settles down to satisfactory "Performing",
then followed by the project-inevitable "Adjourning". And this is to
say nothing of communication to make it all happen. If the project calls for
a grand unified and prolonged effort, as in construction, then such a process
is essential
However, there are many areas of project management application,
especially in IS/IT projects, in which tasks of very limited lifespan are performed
by different groups forming and disbanding with a high degree of frequency. Under
these conditions there really is no time to settle down into a classic team working
mode. Moreover, with virtual teams communicating by the ubiquitous and too-easy-to-propagate
Email, often consuming several hours each day of each member's productive
time, the whole team building exercise may well be counterproductive. Internetet
communications, even video-conferencing, are poor substitutes for face-to-face
personal interactions.
Verma provides a "Checklist for Selecting the Right Team Member"
(Source: John Adair, Effective Team Building, Gower, UK, 1985) posing a number
of questions. These include: "Is the person technically competent?"
"Will the person work closely with others in decision making and problem
solving?" And, "Does s/he have a sense of humor and a degree of tolerance
for others?" These questions fall under the headings Task, Team and Individual
attributes respectively. But this exercise tends to elevate the concept of team
building and teamwork into a "silver bullet" — a magic solution
to all project problems.
The management world has a sad history of "magic bullets"
which all go through a depressing cycle of enthusiasm, reality, disappointment
and ultimately discredit. Far be it that "teaming" should suffer the
same fate, but the reality is that teams are not always the right answer to a
problem. The first question to ask should be "Do we really need a team for
this task?" If the problem really is totally new, and likely to change before
the project is finished, then maybe a team is needed.
But if this is not the case, a better question to ask about
a potential project candidate is "Can this person provide the answer?"
Maybe the person does like to work alone, maybe they don't get along with others,
and maybe they don't have a sense of humor, but then, maybe they are more productive
that way. Some highly skilled individuals are not good team players, they are
just singularly focused. So, the real issue is: "Can this person be managed
to produce results?" If the answer is "Yes", all else is secondary.
By all means develop a project plan at the start of a project using the best
input from available project members. If done properly and efficiently (see Issacon
#1061) this in itself
will develop a team spirit. But in the last analysis, especially at the project
task level, the object of the exercise is not to hold a tea party but to get
an item of work delivered!
|
