Keeping multisite projects on track

Managing a project can be challenging even when all the team members are in the same building. But when they’re spread across several time zones, communications can easily falter—and bring down the entire development effort with them. Avoid watching your multisite effort crumble by following these simple steps.

Single point of contact
The key to success when managing remote teams lies in planning well and establishing a clear division of labor. With this division comes complete accountability for all of the deliverables from the remote team. Designate a team leader at each site who will serve as the single point of contact for that site. This person should produce a status report to keep the project manager apprised of the team’s progress.

Keep the communication engine well oiled
Another key to successful multisite management is to keep the remote team in the loop with planning decisions and meetings. Nothing can sour long-distance working relationships more quickly than letting the remote team feel they haven’t been included in planning sessions or notified of decisions.

To avoid that scenario, you need to put an effective communications strategy in place from the outset. One approach is to create a project Web site where teams can check regularly updated status information. A shared network folder would also work for communicating schedule updates and the like. E-mail with project file attachments would also do the trick.

No matter how you choose to convey information, one consideration is paramount. Everyone must understand that the information being conveyed is an accurate depiction of status and is not sugarcoated. The worst thing that can happen on a multisite project is that teams don’t remain up front about their status. It can be tempting to pretend all’s well when the lead project manager isn’t on-site, but covering up minor problems can quickly escalate and derail a project.

Take advantage of time differences
A time-zone difference between teams can initially be frustrating, but in certain cases, it can actually work in your favor. Depending on the time difference, teams in different locations can work essentially around the clock.

I once partnered with a team in Germany that worked on a discrete subsystem of a project for which they had particular technical expertise. As they developed hardware and software during their workday (the wee hours of our morning), we were able to verify their design during our workday (and their evening). By the next workday, they were able to review our feedback, and we could take advantage of a small time overlap to discuss any questions that they had.

This exchange also worked very well during the testing phase, since they were able to test and give us feedback. Our engineering team was frequently able to investigate problems and provide feedback or answers for them by their next workday.

A real-world example
I’ve had both good and bad experiences managing remote projects. One experience started badly but became positive in the end. The project involved working with a consulting firm that my project sponsor had hired before my company’s development team was put into place. As a technical manager, I was charged with learning what the consulting team was doing and then building my team and transitioning the work back to us. The consulting firm was none too eager to lose the work and didn’t exactly bend over backwards to share project-related information.

To combat this unwillingness to communicate, my team had to work closely with theirs, spending blocks of time physically with them in order to learn and partner on the work. They were located 1,200 miles away in an expensive city, so travel expenses quickly ate into the project budget. We tried to have them colocate with us, but the development environment was located at their facility, as was the brain trust. To facilitate the transfer of knowledge, I had each member of my team partner with a subject matter expert (SME) peer on the remote team. The few weeks spent working side-by-side, with the SME acting as a coach, helped create a good working relationship.

Eventually, my team learned enough to assume the lead role for major pieces of the work and took on functional areas of responsibility. We were then able to use the consulting firm in a supportive rather than lead role, and eventually they were completely rolled off of the project.

On a broader level, we were able to develop a sound communications and status reporting structure that made this a successful experience. By keeping the consulting firm involved in the weekly project status meeting, we were able to keep our finger on the pulse of activity and overall progress.

Another factor in the transfer’s success was good planning with a clear division of work, which included a well-developed schedule with clear responsibilities. In addition, having the regular status meetings and occasional face-to-face meetings, particularly in the early stages of the project, helped us build good working relationships.

Conclusion
While there is no surefire management approach to keeping multisite development efforts on track, open channels of communication make a world of difference. By maintaining a single point of contact at each location, you can keep each team informed and the project focused. And, if you work across time zones, you may be able to put that time difference to use to help you increase productivity.