This article is a result of my conversation with different people about problems of the offshore development and my own experience in this area. The early variants of the article were written in Russian. Some parts were translated into German. This texts were subject of discussion with different software managers and specialists. Some questions were debated in the news-group Relcom.Comp.Softwere-Eng.
In this paper I use a term "the separated project". I call a project to be separated if
The main sign of such project is the complexity or high price of the direct continuous conversation between separated participants and a necessity in such conversation. Most of the offshore projects are separated.
The theme of offshore development is complex. One short article cannot decribe it fully. Different projects have own features. I have collect here a number of common mistakes. Usually people understand what they need to do to avoid this mistakes, but they mean they haven't time or money or anything else to make things in a right manner. As result the same mistakes are repeated again and again.
Below I describe how to avoid the most frequent and worst mistakes from my collection. Some rules are more applicable to a customer, some to a developer, but information is useful for both.
The rules are bound in two sections. The second is a collection of technical errors. This was only one subject of early variants of this article. Many discussions about separated projects have shown that the main cause of projects' falls are not technical errors and not the experience of the staff. The article begins from management and marketing mistakes.
This rule is the most important. It is clear, but this kind of mistakes is very frequent. Choose a partner right. Pretty visiting-cards, high-sounding names and wonderful plans are of no importance. The partner must be reliable. Even the managers of the partner firm have brilliant technical knowledge, they need experience in the project management, product management and firm management. In the other case there are no guaranties that the partner firm will be stable and the project stuff will be good motivated and stable too. This is even more important as financial situation.
Management is a complex work. Don't trust it dilettantes. Of course don't trust it fools. Even you have no choose, choose the partner. It's more reasonable to refuse a not reliable project than lose money and time.
In case you decide not to work together with one partner, you have two possibilities:
- You may dismiss the project and change the marketing strategy.
- You may find the right partner. In this case you need to change the strategy of the search for a partner.
The market of offshore development is big. The main difficulty is that potential partners cannot find each other. The ground of such situation is in the differences between software development markets in different countries and in the differences between search strategies of potential partners.
The targets of your partner must be congruous with yours. Partner must have his own part of risks. For you is wise to avoid a situation, where your partner can get the same in case of project's success and in case of project's crash. Your firm must be not only a possibility to get a lot of money without hard work and any risks.
In the other situation you have no hope that your partner will do his part of work. If one may do nothing, he usually does nothing. This kind of mistakes is very frequently in projects for one customer. He gives money and decides that this is all he need to give. Sometimes he even won't discuss a software he need to be developed. Of course the result of the project is not what he expected. He demands to make changes but won't precisely describe them. When he gets a new outcome the situation repeats again. As result money and time will be lost and the project crashes.
The targets of the people working on the project in the partner firm must be congruous with yours. The connection between the staffs from both sides must be created. The people must get the feeling that they are one team even there are many kilometres between them. They must be motivated in the project's success and ready to work together. If they aren't, the project is going to crash.
Money are important method of motivation but not single possible. An employee may be unsatisfied not only with his salary. He may not trust management or may value project as hopeless. If he is not motivated in the project's success, he is not motivated in the success of his colleagues and he won't give them any help.Each project may have opponents in the partner firm. You need find them as quickly as possible and guard your project from such people. More clever is to change their mind. Of course intrigues couldn't be used in this situation. Only the distance is enough to make them ineffective.
The myth that each developer may be replaced is a widespread mistake. You would get many troubles in case you mean this is true. There are many people that couldn't be replaced. This is important for separated projects which have usually more risks then ordinary. Your firm and your partner firm must do all needed to make the project's staff stable.
For any not very big firm a total documentation and formal organisation is not profitable. This means you couldn't have the whole project's information kept in the documentation and the project won't be easy to understand for people, if they didn't work in the project team. It's complex also to find an adequate specialist that may replace the left one. Even in case one team member leaves the project you need motivate him to translate his knowledge to the colleagues.
All processes in a partner firm are to be hidden from you. You need not forget that the information you receive from the partner firm may be not complete and not precise. Any attempt to intervene in an internal processes without complete understanding could cause very bad results. In additional you shouldn't forget that such intervention frees your partner from the responsibility for the project's results.
Even in case your employee works inside the partner firm, you have no guarantees that information you receive is enough. In this situation your employee works not in your firm and lives in another place. If he has good relationships with people from partner firm, he is going to take their interests into account. If he don't do it, he is going to be in isolation.
Remember: You had choosen right partner. You mean your partner is reliable. Consequently there are no reasons to meddle in his work. Let him take responsibility that he can manage. In case he cannot manage, no any attempt to command in such distance could help. This is one other reason to choose right partner and to give him help he needs. You must give your partner right target and right motivation in the result. This is the best you can do in separated project.
Of course you need check the work of your partner. The reasonable method is to divide project in stages. Each stage should be not longer as two months. The targets of each stage must be precise defined and the results should be rewarded. Try to go from one victory to the next one. Errors must be corrected, but don't try to find a scapegoat.
Try to get all the information you need. Don't rely on ``obvious facts''.
At the first sight this is elementary, but the facts show that here could be many mistakes. The differences between cultures may be clear and may be not. Stereotypes may not work in one other culture. For instance one may forget by planing that holidays are on different dates.
The offshore development is bound with risks. Even in case a partner firm looks as absolutely reliable, any unpredictable things are always possible. Each project may crash. Try to distribute risks so that the disaster in one project wouldn't be disaster for the firm.
It's reasonable to start with a small pilot project and with a number of different partners. First verify that everything works proper then invest a lot of time and money.Don't forget to explain your partner that the question about co-operation would be solved after the end of a pilot project. In the other case you may mislead your partner and lose your good name.
This section contains the most important technical problems you must solve in an offshore project.
Even all modern Internet technologies cannot help to make a separated project similar to work in one building. Informal information flow is very important and request a direct conversation between project members. Neither telephone nor Internet can really replace the direct conversation between project members.
We consider commercial projects for which the development time is important. In case an intensive conversation is needed, any attempt to use Internet and telephone demand much more time as a direct conversation.The second problem is that the emotional reaction of the person you're talking to is not clear. This leads to difficulties in the co-ordination and understanding. Of course such difficulties don't reduce development time.
At least one project member from each side must work a week in the partner firm together with foreign partners before start of the project. This is one possible way to develop a proper conversation mechanisms for the future.
Also important is the possibility to make informal contacts. A lack of partner's personality plays always negative role. A short description given by the colleague who had worked with this person could be more helpful as a long conversation per e-mail.
It's difficult to make a good conversation mechanism right from the beginning. If project members have no experience in the co-operation, they cannot develop a valid information flow in a short time.The main problem at the first time is the ``agreement of dictionaries''. One term may have different meanings for different people. This differences must be understood before they become a ground for incorrect decisions. The best method to solve this problem is a direct contact.
By the time of the direct contact the quality of the information flow must be checked. If any lacks in the understanding are found when the people come back, it would cost much more time and money.
E-mail is not enough for daily work too. At least telephone calls are needed. Don't forget to plan them.
It's reasonable to prepare all needed documentation and send it to the partner before a direct contact. This could save time, make the direct conversation more effective and form archives for the future.
All that may be documented should be documented. If something is clear by the direct conversation, it may be forgotten where the possibility to ask questions is less. Something that seems to play no role may be very important in the future. Documentation can help save all details.
The weakest point in an offshore project is the process of the information exchange between separated participants. It must be strict defined for each side who is responsible for information flow. It is important to make a need of information flow as little as possible. A formal interface between two separated teams must be standard and reliable.
The information flow must be planed and documented
The principles and organisation of the information exchange must be considered beforehand. A main task is to make it as reliable as possible. During the project the quality of the conversation between separated teams must be checked and documented. It must be periodically analysed and changed or improved according to project's needs.
Any well planed information flow in a separated project may lead to chaos if the project conditions change. Conversation protocols must be documented. All of the project members should know the organisation of the information exchange. For instance it's reasonable to keep in the project documentation answers to following questions:
- Where one may find particular information?
- Who must receive notification about particular events?
- Whom may one ask special questions?
If such information cannot be found in the project documentation, a lot of time will be wasted.
It's reasonable to analyse periodically the process of the conversation. Very important is the information about errors and mistakes.
The reliability of the information about the connection between separated teams is very important. It's better to encourage a true information about errors, than punish the person made this error. This helps much more to make future work better.
If information flow is too big, this is a sign of errors in the project planning and in the conversation planning. A direct meeting between teams' members is obligatory. Errors must be found and plans must be corrected.
The moderator
One person from each side must be responsible for the information exchange. This is only one possibility to control the current state of the project. The moderator supervises information flow and keeps documentation. He is responsible for archives of the conversation too. The moderator shouldn't be a project leader, but should be a competent person.
Different archives could be administrated by different persons, but one should know which information could be found where. As rule all technical archives must be accessible for all project members.
The moderator should define rules and protocols of the conversation and of the documentation. He must know what is the subject of discussion at the moment and what are subjects of each archive. In case there is no one person who knows about all flows of technical information, the process couldn't be under control.
The moderator of the project may charge somebody with a conversation about some particular problem. Important is only the absence of parallel flows of the same information and the presence of one responsible person for each information exchange.
This person holds responsibilities of a moderator for a part of information flow and keeps archive of it. After the end of the discussion he gives archive to the moderator of the project and writes a short description. This must consist of descriptions of all discussed variants, a final conclusion with complete substantiation and all other opinions, if any participants of the discussion had them.
The minimisation of bounds between project's parts
The parts of the project which are to be developed in different teams must be as independent as possible. The separation of the project in a number of sub-projects must be well defined.
One person from each side must be responsible for the co-ordination of project tasks. He must control compatibility and solve conflicts.
The formality
Specifications, interfaces, documentation, tests etc. must be formal. This can make the project more reliable.
In the other case important information may be lost or not correct understood by the partner side. Very frequent mistake is when one partner develop not that is needed for another.The formality must be a result of a discussion between all project members. In the case it is introduced as a standard from the top management, it can't be reasonable and helpful for team members.
CASE tools
CASE tools may be helpful, but only if both sides have any experience using them. Incorrect using of CASE increases problems.
A CASE tool file can hold more precise information as a header file. In any cases one can send fax with the scheme of classes, but sending a CASE tool diagram is better.
Software Configuration Management
If a software is developed by separated teams a Software Configuration Management (SCM) is obligatory. If any work files could be changed by both teams, a standard for code changes must be developed. In case two different changes cannot be made in one work file simultaneously, the delays may be a day and longer.
One person from each side must be responsible for SCM and for corresponding tools. He is responsible to solve all conflicts in this area.
The process of Software Configuration Management, code standards and co-ordination between teams must be well defined and proved. Errors in the SCM can be very expensive.
A process of preparation of the documentation must be well defined and organised. What may be documented should be documented. In the other case the information flow cannot be well organised and the cost of the project is transferred in the stages of integration and testing. As result the common cost rises, the quality is low, deadlines are missed.
The product specification
Product specification must be ready before the start of the product development. At least a precise description of the future product functionality should be written. Specification must be discussed by both sides. Partners must agre on the final version. Very important it is if one partner defines the project task and another realises them.
This kind of mistakes is very frequent in small projects. Partners don't make any formal specification. One describes in common words what he wants. The other thinks, that he has understood what the product should be or even means that he knows better needs of the partner. As result a quite different product is to be developed.
The documentation must be written in English
The documentation must be written in English right from the beginning. English must be the language of program comments, file names, names in the source code, such as function names, class names, variable names etc. The usage of slang must be reduced. It's better to use simple English and well known professional terms. Each document must be clear for any specialist knowing English.
If one document is written in a language which is not understandable by the other partner, it must be translated. Usually such document will be translated with a big delay or may be not translated at all.Even if one doesn't want to hand over a document the situation may change. One team had used not very polite comments. At the end of the project the management decided to give the source code to the partner. Of course it gave orders to remove all terms of abuse. As result most important comments were simply deleted.
All of the project members must know English. If one doesn't know, the need to use English in the documentation is a good stimulus to study it. In all cases to spend time to study English is better as lose it due misunderstanding of the foreign partner.
You must spend time and money for education and training. The better knowledge and experience the staff has the more effective its work is.
Team members must have enough time to learn to work together with foreign partners. In case any education is necessary, it must be done. All project members must have educational equipment and time to study and to get practical experience.
In all cases one side must understand the other. If for the project are necessary any knowledge in special area, at least one member of each team must be competent. In the other case one side cannot understand the other. The possibility to explain any complex thing to a amateur without direct contact is low.
It is reasonable to begin with small pilot project. This is a good possibility to test project plans and to give the staff enough experience. Pilot project must be made by most qualified specialists. In the future they are going to be experts.
All changes in the project must be made by strict defined steps. This is only one method to analyse grounds of mistakes or improvements. If the situation changes quick, it's difficult to refuse wrong new things.
Any technical possibilities for an informal contact between members of the project should be made. This may be a black board system or a mail-list.
Any subjects of the discussion could be possible. A dialogue about sport or music may help to understand a foreign person much more than all formal meetings.
In case the partners are in different time zones, very important is the time interval when a workday in one firm has begun and in the other hasn't finished. It's reasonable to give for this time a high priority for the conversation with the partner firm. Any work that may disturb the process of the information exchange must be planed for some other time. In particular situations the work time could be shifted to make the interval of common presence maximal.
If this interval isn't used the delay between question and answer may be a day. As result a lot of time would be lost.
There are many other more specific rules, that are important for separated project. The rules described above are the most common and are based on the analyse of the most frequent errors.
Of course in case you follow all the rules from this article, you haven't get a guarantee of the project's success. Each project has its own features and an analyse of the concrete situation is oblivious. In case you have good reasons you may not follow any of the rules. You need only not forget about probability of the mistake and avoid it in one other manner.
I would like to thank Andrey Khavryutchenko, Petr Unruh, Aleksej Donskoj, Juri Katz, Igor Levko and Sergej Druchin for their valuable help, comments and criticisms. I would also like to thank all those involved in discussions about the offshore development in the news-group Relcom.Comp.Softwere-Eng