First published as an editorial for Project Management World Today Web Magazine. Updated here September 2001.

 

Musings Index

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!


Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page