Reason Number 5:
Pros: It saves energy. While you work at home you don’t waste time and effort for traveling.
Cons: It wastes energy. When you have to travel, you waste a lot more than if you worked in the same country and in the same office.

Where is the problem? Why these guys think so differently upon the same situation? My answer is very simple. The very definition of the “distributed team” they use is different.

When I ask myself the question “What does a distributed team mean?” I divide it into the following questions:

1. How distributed is the team? If the team works in the same town and they don’t work constantly in the office but instead they work at home I believe it really saves money and energy and this kind of distributed team works effectively because they don’t spend time traveling, they use their own computers and they only need a good internet connection to do their work (especially if the team doesn’t need any other special technical equipment). But if the team is disbursed through the globe then it might not be cost-effective at all. Especially if there are long time differences and there is a need to meet face-to-face frequently.

2. How often do they need to meet? It depends on the nature of the project. If the project is a more R&D-oriented then it would require more frequent meetings, which is not good if the team is dispersed. On the other hand, if the work is more routine and there aren’t much things to discuss, it wouldn’t be a problem that the team members work at different locations and meet rarely. But nobody said that the structure should be fixed all the time! If you are allowed to play creatively with the budget, you may find that the best way is to gather the team for a short time in one place, do the brainstorming and the research, make all the decisions and then split them back so everyone can work from their location for the next period. Later, you can bring them back again if necessary. You just have to make your calculations and to judge the effectiveness of the team working together and working from their homes or local offices.

3. How urgent is the project? If the project is some kind of a “Death march” it is obvious that the distributed team wouldn’t be able to handle it right. You need your team to be with you all the time so you can keep their motivation and work energy at high volumes. But if the project is well-planned and it allows people to work with a normal pace, a distributed team may be a more effective solution since it wouldn’t require a “management pressure” on the team members.

I strongly believe in the effectiveness of the distributed teams where the people are not far away from each other and the nature of their work doesn’t require them to meet too frequently or to respond urgently to user requests. It is difficult to manage such a team but if you do it smartly you can make your project more profitable. but before you decide should your team work at one place or at different locations, ask yourself these questions and judge carefully.

You may also find these posts interesting:

• Project Management 3.0

But in a while, after reading his post and the article he cites I started to realize that there is nothing new under the sun – it’s just a new, fashion name for the thing we already know.

Obviously, the version numbers 1.0 and 2.0 were created by the agilists. To put it roughly, PM 1.0 refers to the classic or heavy methodologies in project management. They focus on large projects, large budgets and big teams. Ugly Gantt charts, many stakeholders, horizon and beyond timelines and (note!) expected failure! PM2.0 respectively has only positive characteristics: small teams, made of smart and motivated people (does it mean that the large projects are performed by dumb people?), fast pace, feedback, responsiveness, etc.

It smells like a religious war from very far and isn’t worth mentioning. As Glen Alleman says in his blog Herding Cats, if you want to show the advantages of the agile methodologies you shouldn’t compare it to Waterfall because “Waterfall is dead, dead, dead“. The modern version of the “classic” PM approaches like PMBOK and Prince2 also embrace change and calling them “heavy” or “rusty” is not relevant anymore.

What caught Bas’s (and mine) attention is the idea of “Social Project Management”. As he states:

The Project Management style, and the supporting tools have to be “social”, and now more then ever. The project landscape is turning mobile, multi-cultural, 24×7, highly distributed and in ever flux.

But this situation will increase the risk of getting into some social “booby” traps and he points out the three most important ones:

1. Communication trap: proper understanding of what the other stakeholders need in the project;
2. Trust trap: letting go of control and hoping people still do what they are supposed to do;
3. Isolation trap: no sense of belonging to the project through geographical, cultural and timezone differences.

This is the Project Management 3.0 and the real challenge for it will be a social one. According to Bas, this is the place were social software can help a lot. Not only in collaboration but more in building a sense of community, enhance trust and stimulate open communication.

You can read his entire post here.

You may also find these posts interesting:

• Krishna Kumar Did An Interview With Me On Software Development
• Top-down Planning – Good or Bad?
• The Pros and Cons of Distributed Teams
• Project Management and Hiking
• The Recommended Weekly Readings (2007-08-18). Project Management