reporting on the current state and the feel of the team by being inside. I've found that good software is usually produced by people who complement one another. A hundred Java developers aren't the right mix if none of them can write and manage requirement statements or has the right design skills.
I have seen a lot of project plans, many of them documented using a work-breakdown structure (WBS). Some of those plans were so detailed that actually doing the task was faster than the planning process. Project managers can monitor those milestones on paper and can execute the escalation routine if deadlines of activities are not met. However, at that point in the project it is too late, because the risk has already materialized into a problem. A WBS works well in manufacturing, where input and output parameters are better understood. In software engineering, a plan has to be more flexible and more adaptive, for a too detailed WBS eventually fails.
In a similar approach, I have looked at many project status reports that indicated "on time" and "on budget," with "high morale" among the team members. Talking directly to the team members gave me the totally opposite picture. How successful do you think a soccer team would be if the coach didn't show up for training sessions and received the team's results and performance from the local newspaper?
Conclusion: Forecast local developments.
Media and Communication
Before telephones and Web-casts existed, people needed to be in the same room or write letters to each other in order to communicate. Bringing people together at the same time, in one location, and writing, stamping, and delivering mail consumed quite some time. In other words, you needed to say something important and resources weren't to be wasted.
Today, with people and information at your fingertips, such a time commitment doesn't seem necessary. Electronic media even allows virtual meetings, sometimes with simple nicknames. This anonymous collaboration is very popular and successful for a variety of reasons. However, I personally believe electronic communication best complements conventional meetings held in person. The isolation caused by those technologies can create a distance between team members and the project.
When people physically meet, a team appears. Picture yourself among others in a roundtable meeting. Some participants don't have the time to actually make it to the meeting and instead decide to dial-in via phone conference. In almost all of those meetings I have been in, the people in the room interacted more, discussed, and shared laughs, whereas the participants on the phone seemed more like outsiders. Body language is a very important piece of human communication, but we shouldn't forget the pre- and post-meeting communication-exchanging handshakes, sharing personal stories in the elevator while going to the meeting, and mingling after the meeting when leaving the meeting room. Sound familiar?
Electronic communication is not limited to the professional life anymore. People may find their partner for life online, but they usually meet before they get married.
Conclusion: Humans need human interaction.
The scenarios in Part I have presented some challenges in software engineering in general, and they exist even if projects are not executed offshore. In Part II, I elaborate on these topics and discuss the challenges when projects go offshore.