Dominique Stender Good software is only the beginning

Successful offshoring part 3: Preparation

In this third article in my series on successful offshoring I will discuss the preparation of a project that involves a team at a co-location and present several steps to ensure a smooth start.

I give you some measures to keep the project on track and inform you about early warning signs.

If you missed the initial articles which handled the added complexities of time(zone) management, or the second one talking about the role of the coordinator, I recommend you click one of the the links and start there.

Preparation

You will want to make the project as well prepared, clear and free of uncertainties as possible. Yes, you always try to do that even when you're not offshoring. Here you have to try even harder.

The communication overhead in a co-located project is incredibly high to begin with. A week more spent on clarifications will save you a lot of trouble, time and hence, money.

Just remember: Your offshoring partner did not sit in those workshops with your customer. They are not on the phone with the customer. You know a lot more than your partner from offshore. It will be impossible to give them all the info you have but make sure you try real hard. Have a formal kickoff meeting (with physical presence!) and a workshop or two in the beginning.

Start face to face

It is a very good idea to bring your project manager, consultant and coordinator to the co-location for a couple of weeks during the start of a new project. A reasonable time frame is six weeks for a multi months project.

Make sure your management / consulting team arrives at the co-location a few days prior to kickoff to have enough time to settle down, get rid of jet lag and initial health issues due to change of climate, hygiene and food.

Plan time for the teams (main office and co-location) to get to know each other on a personal level. Go out at least once before kickoff. Dinner, bowling, cart racing... almost anything goes.

Setup checklist

Of course, there also should be enough time to set up the working environment prior to kickoff. Verify and re-verify everything. This includes but is not limited to

• the required documents are on location, in the correct language and up to date
• development environment is functional
• a revision control system such as Subversion is set up, accounts are configured, known and working
• a bug tracking system is set up, accounts are configured, known and working
• a deployment system is available and visible from all locations
• a mailing list is generally a good idea
• for long term projects setting up a wiki makes perfect sense
• hand out lists of phone numbers with every person on the project being on the list
• do the same for the instant messenger of your choice
• make sure the offshore team sits together to facilitate mouth-to-mouth communication
• a few webcams are great to keep the team(s) connected and personally involved

Focus

In an ideal world the project manager and consultant of a project are assigned to it to one hundred percent and do not have any obligations outside of that. If you can achieve that, perfect. In fact, you should try real hard to achieve that if you start a new project at a co-location.

A not-so-ideal world results in project manager and consultant being involved with more than one project. This is the common scenario. During the start phase of a new project in an offshore location this imposes a great risk. The return flight is booked and changing it brings a lot of complications, so time is incredibly precious. Make sure your manager / consultant pair has no other obligations during the time they spend offshore with their team.

Here's a simple trick to ensure no one intervenes while you as a manager or consultant are in the offshore office: Be on vacation. At least officially. Do whatever is required as per your company's process to be on leave. Assign a vacation replacement. Inform your (other) customers. Make it very clear to the colleagues of the other teams that you will not be available except for disaster recovery. Stick to it.

Structure your communication

Even with small teams it is quite easy to end up with a communicational mess. I mean a situation where everyone is using instant messaging, mail, the bug tracking system and the phone simultaneously. The results: Information becomes redundantly stored in multiple communication channels. Only a part of the team is informed. Efficiency goes down.

Spend some time in the beginning of the project to craft a communication diagram. Develop the diagram together with your team to make them involved in it. The diagram has to have two design objectives: First and formost it has to streamline and unify communication. Second, it makes communication transparent.

Maybe it makes sense to assign a 'communication lead' from within the offshore team. That'd be the person that centralizes all statuses, issues and clarifications and takes the initiative to resolve them with the main office. If you're doing Scrum, that'd be your offshore ScrumMaster. The benefits are several. One, there is one person offshore who has the global picture. Two, the other offshore members can continue working (on other tasks) while issues are resolved. Three, for the management / consulting / coordination team in the main office the communication becomes much more efficient and less redundant.

The second start - remote

So now your project head has spent a couple of weeks at the co-location and the project started well. The communication is clear and efficient. Things run generally very smooth when your manager / consultant pair take flight and leave for the main office.

Be prepared for an immediate slump of efficiency.

It's easy to wrongly assume that things will continue to run as smoothly as they did initially, when face-to-face communication was the norm. Reality is that they probably won't.

Be on the lookout for a general reduction in communication. There is no save assumption that this would be ok. Instead, communication should go up, both in frequency and duration. If it doesn't, find out why as soon as possible and remove the impediment.

Do not believe that a team member who does not communicate is productive. Maybe he is, but chances are that he is stuck.

Mind those time zones. Ensure that any clarifications, issues and problems in the offshore project are resolved before you involve yourself in local projects.

Summary

The list of topics to cover under 'preparation' is endless. Largely it involves communication. Be aware of the fact that you will not be able to fully know what is going on at the other location and have tools and measures in place to compensate for that.

I'm sure I didn't cover every aspect. If you're stuck at a certain point or you've encountered different issues than the ones I discuss above, use the comments to inform me and my readers! For a more personal discussion feel free to get in touch with me through the contact form.

Related Posts:

• Successful offshoring part 2: The coordinator
• Successful offshoring part 4: Independence
• Successful offshoring part 1: Time management