Personal experiences from managing virtual teams
Between 2002 and 2004, I was involved in my company’s effort to establish two development units in Serbia - first one in Novi Sad, then another one in Belgrade. The year before, in 2001, I had been business analyst in a project where we outsourced the software development to a company in Serbia and where the customer was situated in USA.
After we had managed the challenges of that project, we thought; why not establish our own development units down there? We were only around 15 people at my company (situated in Stockholm) back then and it was hard times for consultant firms. We simply saw the establishment of development units in Serbia as an opportunity to cut our development costs to increase our margins, and to be able to continue the development of our content management products. We calculated that we could hire approximately 7 skilled software developers for the same cost as one in Sweden. There was no need of a much more detailed business case than that.
I won’t go into details about the hardships that we faced during this period, but I can conclude that it was a successful endeavor even though I lost my hair and experienced the most stressful period in my life so far. It was one of those experiences that added ten years of experience in only two years.
Anyway, as product manager, project manager and requirements analyst in several projects I learned a few lessons about how to work with virtual teams for software development. Here are a few recommendations if you are up to a similar challenge:
After we had managed the challenges of that project, we thought; why not establish our own development units down there? We were only around 15 people at my company (situated in Stockholm) back then and it was hard times for consultant firms. We simply saw the establishment of development units in Serbia as an opportunity to cut our development costs to increase our margins, and to be able to continue the development of our content management products. We calculated that we could hire approximately 7 skilled software developers for the same cost as one in Sweden. There was no need of a much more detailed business case than that.
I won’t go into details about the hardships that we faced during this period, but I can conclude that it was a successful endeavor even though I lost my hair and experienced the most stressful period in my life so far. It was one of those experiences that added ten years of experience in only two years.
Anyway, as product manager, project manager and requirements analyst in several projects I learned a few lessons about how to work with virtual teams for software development. Here are a few recommendations if you are up to a similar challenge:
- Expect a lot of overhead in terms of project management, requirements and test. Overall, the project will consume a lot more man-hours. Productivity will be significantly lower than if you would run the project at your own location. But since the cost per development hour is much lower, you will still be able to increase margins if the size of the project is big enough (minimum 1000 development hours).
- Ensure that you have a strong setup with a project manager, requirements analyst, test manager and architect at your own location. You then probably need to mirror that setup at the development unit. At least ensure that you have a project manager, lead developer and test manager at the development unit.
- Co-locate the team for a couple of weeks in the start of the project to learn to know each other and find ways to work together as a team. If you use the same team for several projects, you don’t have to repeat it for the next.
- Focus on visuals before text because of the language barrier. Use visual modeling and prototyping to communicate requirements and facilitate an understanding of what the project is to deliver. Use a common notation such as UML for modeling.
- Use tools that make it possible to trace the requirements to design, implementation and test.
- Use an easy-to-use web based issue management tool to define, delegate and follow up on tasks.
- Use a versioning system with branching that can be used for multi-site development.
- Make sure every team member has access to e-mail, IP-telephony and instant messaging and encourage them to use these when needed. But define some basic rules for when and for what to use these - you don't want to have IM conversations going on with each developer all day long.
- Make each developer write a diary (we used e-mail and hadn't discovered that we could use weblogs instead) about what he or she has done during the day and listing any issues they are dealing with.
- Set up a web based developer community (wiki) to share everything from instructions on how to set up development environments to code.
- Use a project workspace with a document repository where the latest version of all project and requirements documentation can be made accessible.
There is not much magic here. The magic you'll have to add to this recipe is the right people. With "the right people" I mean that they must have the right skills and the right attitude. Regardless of what you do of everything listed above, you won't succeed if you cannot get the right people to your team and keep them motivated.