We can already safely assume that geographical latitudes and time differences won’t stand in the way of co-operating with a remote software development team. We also know what to focus on for that collaboration to start in the first place. Now it’s time to take a look what can be done to minimize any risks of working with remote developers.
Name and discard your fear
It’s good to classify your fears. Sometimes it’s enough to ask a few questions that will help you verify whether there’s really anything to be afraid of. Here are some possible issues that might come up (and our ways of dealing with them).
“I fear that I’ll lose control over my remote software team”
You need to check the following:
- what are the potential partner’s references?
- does the partner accommodate for regular meetings – to present the results and to plan the subsequent stages of the project?
- does the team deliver tools for work progress analysis and time reporting (even precisely to the minute)?
- is it guaranteed that you can opt out of the collaboration after a trial period (2 weeks, for example)?
- is the speed in which the partner will react to the client’s prompts and requests marked out in the agreement?
“I fear we’ll have communication problems”
Videoconferences, e-mails and chats aren’t everything. Always pay attention to those issues:
- can the team implement their solutions ASAP, even in the middle of the night?
- will they adapt their meeting hours to your expectations?
- can your partner spend some time in your HQ to work by your side and get to know your business a little better?
- a dedicated project manager on the partner’s side or an adequately trained supervisor in the client’s HQ will also limit any communication issues that might come up.
“I fear that I’ll have difficulties in controlling the budget”
The matter of budgetary control is still the focus of many debates. Usually, two voices can be heard – those of Fixed Price fans and Time&Material supporters. Market experience allows for betting on the latter approach, which allows for more possibilities – but these are worth exploring further…
“I fear that I will lose control over the form of the project”
Involving the customer in planning the consecutive stages of the tasks and progress presentations is one thing, but their actual influence on functional changes is another. It’s worth to get to know your future partner and make sure you’ve got these things down:
- does the potential partner put emphasis on the creation of prototypes? What’s their quality?
- does the partner understand your business, trying to be a consultant, and not only a contractor?
“I fear that the team won’t handle the product’s future development”
Your product will – in time – require expansion or technological changes. You should do an early check to see if the partner has experience in dealing with long-term co-operation.
Other important issues include:
- the technological specialization of the team,
- the skills and abilities of developers who can be available immediately,
- estimated time in which the partner can create the new team,
- procedures ensuring a continuity of work in the project (such as senior developers supervising the juniors. Fresh and original ideas can be yet another benefit).
And one more thing.
You can’t forget that you and your hired crew are playing for the same team. You’ll all want to grow and face new challenges. This should make you sleep easier already!
I’m waiting for your questions, including your lists of fears that I could, perhaps, try to deal with in the future.
Author: Michał Wiśniewski