Managing Distributed Teams - Lessons Learnt
I have been involved in several big software development projects that used distributed international teams. Many of those projects were on the track of failure, till lessons were learnt and things were changed. It is not uncommon for such projects to be over budget and off track in terms of features and timeline. So, here are some of those issues I've noticed:
1. Total ignorance of the potential issues with distributed teams: Managers and team leads often don't spend any time discussing the potential issues that could arise because of the distributed nature of the team. They are over confident that every thing would work just fine, so let's jump into it and make it work. If other companies are doing it, why can't we ? In a few weeks, the reality hits them, invariably, like a slap on the face. Then they look for scapegoats, make everybody's lives hell and screw up the project.
2. Not having an offshore manager with onshore experience: A person who doesn't have a social security number can never fully understand why SSNs are kept in secure databases. So the leader of your offshore team, must have experience working in the country where the software application would be used. Besides features and requirements, there would be a million cultural, communication and process issues that would arise with offshore projects. So if the team doesn't understand what you are talking about, you are in trouble. No amount of documentation would help in this case. You need somebody who has worked in your country/company/team to act as the liaison with your offshore team.
3. Using old school PMBOK waterfall nonsense: Innovative software company all over the world have moved away ( or are moving away ) from the traditional waterfall project management and the overhead associated with the PMBOK methodology. If you use such old school process for managing a distributed offshore projects, you projects are practically doomed. Before it hits you, your projects would be damaged beyond repair due to lack of regular feedback, lack of quality and other factors. So you must use an Agile approach. Keep the feedback loop as short as possible and put your product in front of users frequently. Minimize the documentation overhead and process overhead. There are enough risks with an offshore engagement as it is, you don't want your project management process to make things worse.
4. Not having a project management process at all: I've already recommended an agile PM approach above. Must mention that lack of any project management process would kill an offshore project too. Don't think of project management as a way to keep tabs on people. Think of it as a way to facilitate smooth development, to lay out clear priorities, to detect problems earlier, to handle major challenges by breaking those down into chunks and to empower the team in general. In an offshore project, laying out clear priorities might be one of the most important aspects of project management. So find a way to do that. I've used the in-house priority scores and similar scores used by software such as RallyDev.
5. Starting offshore engagement with a major projects ( vs a smaller low risk project ): If your company has no experience with distributed/offshore engagement, and you start on that with a big and major project, that project is going to be in trouble. Start the offshore engagement with a small low risk project, learn your lessons and then think about offshoring bigger projects.
6. Not having quality measures in place: You must have code quality measures in place. All the common sense things that good software developers advocate ( automated code quality checks, continuous integration, code reviews, architecture reviews, frequent performance tests, unit testing etc ). are even more important with distributed/offshore projects. People in offshore teams might have a totally different understanding of quality than you do. So you need to make the expectations and the process clear from the beginning.
7. Not treating offshore teams with respect: Yes, this happens often. Errors are blamed on the invisible offshore teams, offshore guys are always expected to be available for meetings, their holidays are not respected, enough guidance and training is not provided and unnecessary delivery pressure in put on them. Remember offshore guys are humans just like you, they make mistakes just like you and they are probably working harder than your onshore team. Also remember, offshoring was your idea. So treat the offshore guys with the same respect and patience that you would grant to your onshore team. You probably need a bit more patience to deal with offshore teams. So keep that in mind, otherwise things would backfire.
8. Not getting involved in the selection of offshore team members: Often onshore managers have little control over the team members that are selected for the offshore work. At other times, managers just take offshore vendors on their word. I think that is a mistake. You should consider the offshore team as an extension of your onshore team and pay attention to the skills and experience of the offshore team members. Training and mentorship can sometimes overcome the skills and knowledge issues, but you often won't have the luxury to train or mentor offshore teams members. So it is even more important that you evaluate their profiles and if possible interview them, before hiring them to build your products.
There are more things.....I'll add those gradually.
1. Total ignorance of the potential issues with distributed teams: Managers and team leads often don't spend any time discussing the potential issues that could arise because of the distributed nature of the team. They are over confident that every thing would work just fine, so let's jump into it and make it work. If other companies are doing it, why can't we ? In a few weeks, the reality hits them, invariably, like a slap on the face. Then they look for scapegoats, make everybody's lives hell and screw up the project.
2. Not having an offshore manager with onshore experience: A person who doesn't have a social security number can never fully understand why SSNs are kept in secure databases. So the leader of your offshore team, must have experience working in the country where the software application would be used. Besides features and requirements, there would be a million cultural, communication and process issues that would arise with offshore projects. So if the team doesn't understand what you are talking about, you are in trouble. No amount of documentation would help in this case. You need somebody who has worked in your country/company/team to act as the liaison with your offshore team.
3. Using old school PMBOK waterfall nonsense: Innovative software company all over the world have moved away ( or are moving away ) from the traditional waterfall project management and the overhead associated with the PMBOK methodology. If you use such old school process for managing a distributed offshore projects, you projects are practically doomed. Before it hits you, your projects would be damaged beyond repair due to lack of regular feedback, lack of quality and other factors. So you must use an Agile approach. Keep the feedback loop as short as possible and put your product in front of users frequently. Minimize the documentation overhead and process overhead. There are enough risks with an offshore engagement as it is, you don't want your project management process to make things worse.
4. Not having a project management process at all: I've already recommended an agile PM approach above. Must mention that lack of any project management process would kill an offshore project too. Don't think of project management as a way to keep tabs on people. Think of it as a way to facilitate smooth development, to lay out clear priorities, to detect problems earlier, to handle major challenges by breaking those down into chunks and to empower the team in general. In an offshore project, laying out clear priorities might be one of the most important aspects of project management. So find a way to do that. I've used the in-house priority scores and similar scores used by software such as RallyDev.
5. Starting offshore engagement with a major projects ( vs a smaller low risk project ): If your company has no experience with distributed/offshore engagement, and you start on that with a big and major project, that project is going to be in trouble. Start the offshore engagement with a small low risk project, learn your lessons and then think about offshoring bigger projects.
6. Not having quality measures in place: You must have code quality measures in place. All the common sense things that good software developers advocate ( automated code quality checks, continuous integration, code reviews, architecture reviews, frequent performance tests, unit testing etc ). are even more important with distributed/offshore projects. People in offshore teams might have a totally different understanding of quality than you do. So you need to make the expectations and the process clear from the beginning.
7. Not treating offshore teams with respect: Yes, this happens often. Errors are blamed on the invisible offshore teams, offshore guys are always expected to be available for meetings, their holidays are not respected, enough guidance and training is not provided and unnecessary delivery pressure in put on them. Remember offshore guys are humans just like you, they make mistakes just like you and they are probably working harder than your onshore team. Also remember, offshoring was your idea. So treat the offshore guys with the same respect and patience that you would grant to your onshore team. You probably need a bit more patience to deal with offshore teams. So keep that in mind, otherwise things would backfire.
8. Not getting involved in the selection of offshore team members: Often onshore managers have little control over the team members that are selected for the offshore work. At other times, managers just take offshore vendors on their word. I think that is a mistake. You should consider the offshore team as an extension of your onshore team and pay attention to the skills and experience of the offshore team members. Training and mentorship can sometimes overcome the skills and knowledge issues, but you often won't have the luxury to train or mentor offshore teams members. So it is even more important that you evaluate their profiles and if possible interview them, before hiring them to build your products.
There are more things.....I'll add those gradually.
posted by Vikas Phonsa at
3:45 PM
0 Comments
