Managing Virtual Project Teams

"Our electronic communications may be very slick, but if neither party knows what the other is talking about, you are going nowhere fast."

- Bryce's Law

These are interesting times for managing systems development projects. In the old days (as late as the 1980's), whenever a development project was initiated, it was necessary to form a project team at a centralized geographical location in order to expedite communications between project members. But now we live in an age of electronic communications that provides greater flexibility in terms of allowing workers to work just about anywhere; some are at a central office, some are at home, some are consultants operating off-site, some are overseas in Timbuktu. 

Thanks to such things as collaborative software, the Internet, cell phones, etc., development staffs are as distributive as the systems they are trying to build. Whereas the development staff used to personally know all of the people participating on a project, now it is common for people not to be able to match a face to a name, be it nothing more than a UserID or an e-mail address.

Although electronic communications is useful for instant messaging and exchanging design documents and files, interpersonal relationships are often sacrificed, and this is a vital part of any project. After all, if we do not know anything about an individual, we are less likely to trust and work with them effectively. 

Consequently, Project and Systems Managers ask me for advice on managing virtual project teams for which I offer three suggestions:

1. Identify your cast of characters - for all members of the project team, define the project infrastructure in terms of administrative reporting relationships, along with a personnel roster. Such a roster should identify each person by proper name, nickname, and photo. There should also be contact data (including physical location), the duties and responsibilities of each person, and a brief biographical sketch describing each person. Such a sketch is invaluable for promoting understanding and trust between project participants.

2. Define standard methods, techniques and tools. Since there are conceivably as many interpretations of systems development as there are project members, it is necessary to develop a standard and uniform approach that will result in consistent and predictable results. This means processes (phases of work) must be defined in terms of standard deliverables and review points to substantiate completeness, and standard techniques and tools to be used in the development process. Such standardization eliminates confusion and materially assists the project team in communicating on a common level, regardless
of where they are geographically located.

3. Establish standard and routine project reporting cycles. 

Here, a good Project Management system can be invaluable. At minimum, project status should be reported on a weekly basis. If it is not possible to hold an on-site project review meeting in person, try holding an on-line meeting instead. Internet chat sessions and video conferencing have become very effective in this regards. The only problem though is knowing whether the participants are truly paying attention. A private project blog or discussion group can also be helpful for reporting problems and project status, as well as establishing punch lists and providing a clearinghouse for solutions.

When you think about it, there is actually nothing here that shouldn't be done under normal operating conditions where all participants are on-site and present. Electronic communications simply begs the issue. It also means standard methodologies, like "PRIDE," are just as important today as they were yesterday, perhaps more so. Consider this, without such standardization, offshore programming is not truly feasible. Collaborative software, the Internet, and all of our other communications vehicles are nice, but without an organized and standardized development environment, chaos will inevitably ensue.