10 tips for communicating with external developers
Many startups decide to cast their IT projects to external developers. Ten tips on how communication can fold despite distance.
Much of the outsourced IT projects that are given to agencies, service providers or freelancers, fails. For budget or time frames are exceeded or the desired functionalities are not provided. Overall concerns between 50 and 80 percent of all IT projects, such as from the chaos Manifestos the Standish Group or from studies of smaller consulting firms shows. A main reason for this are communication problems with the developers. Ten tips to overcome:
1) Selection of the developer
To ensure good communication, the selection of suitable developer is important.There are vendors who conceal their weaknesses in certain technologies – or overestimate. Therefore, one should consider exactly who you’re getting into. The following questions should be answered for:
- If the developer has the necessary experience in the required technologies?
- If the developer trustworthy?
- Has he worked with customer’s own size?
- Are expectations regarding time, budget and functionality of the project clear?
- Can the developer to show his approach in a manner understandable to the client, so there are no misunderstandings?
2) Requirements Analysis
The requirements to be described as well as possible before the start of the project. Failure to do so will often take some time to clear that was working in the wrong direction. Although it is not always all requirements predetermine exactly, but help the following steps:
- specify requirements in a document
- Break down the requirements in this document by functionality. For example, the client can describe the most important part of functionalities. This may require, for example, in the form of user stories outsourcer.
- edit the document until the developer and the founding team have the same understanding of the project. This can happen, for example, a Google Doc, in which the customer inserts his online information and the project manager and the developer can be relatively the same time proposed for questions and comments.
3) Flexibility
Buyers and developers should remain flexible in the project. The client must remain open for how the project will ultimately look in detail; the developer should be prepared to dodge to other technologies and tools.
Excessive rigidity on both sides of the project can derail. Innovative solutions can not always be implemented as you have imagined it at first.
4) Technology is easy – people are hard
Often is not the technology the problem. In most cases, created over time a certain distrust of the developers. The reason is often in it because it is not clear why more time was spent on a task, as planned. This ultimately increases the cost. However due to its conflicts arise.
On interpersonal communication may fail entirely. Therefore, one should keep these soft factors in mind and possibly look for solutions.
5) Accepts responsibility for the project
After handing over the project documentation, the client mentioned frequently in the assurance that the requirements have been correctly received by the developer. Here it is important to take responsibility for the project. Even if you do not understand completely as an entrepreneur, the technical side of the implementation, you can agree to communicate regularly and quickly to get the first version. Thus, the founder of the whole once test.
6) Change requirements and documentation
In almost every IT project will eventually clear that the requirements have to be amended in order to provide ideal value for users. Too often, however, these change requests are poorly documented and communicated, which leads to higher cost in the communication.
At the same time change requests should be kept as low as possible. The advantages are deadlines and budget targets unachievable. Other functionalities or changes can be also implemented in later versions. Here must be weighed, what is really important.
7) Be available for questions
Some questions must be answered quickly, otherwise the developer can not continue working on the project. This in turn puts the deadline further into the future. Therefore someone should be responsible in the founding team for such questions of developers. It is important to take responsibility for decisions, not dodge the questions and not to assign blame for an aberration the developer.
8) Realistic timelines
Instead of the founding team of the developer should specify the time for completion. Only he will be able to assess the duration correctly. This is important as unrealistic timelines can cause a developer implemented suboptimal solutions.They then perhaps the desired functionalities, however, are unusable for the future (not performant code unwartbare solution and the like).
9) Involvement remain
Over time, diminishes the desire to continue to be heavily involved. By contrast, the founding team should actively proceed with themselves. A good way to do this is to ask, for example, after the access to the project management tool of the contractor. In it you can log in from time to time and find out the status. In addition, you should contact the developer regularly and ask about the progress.
10) Communication with developers abroad
Many founders venture the step abroad, in order to implement the development of their product. The likelihood that the project might fail. After the usual difficulties, there is cultural differences and the distance.
usually the work culture but is no different. Nevertheless, because of the distance is often created mistrust and uncertainty, when the communication is scarce. In Asia, for example, questions must be asked so often, so that a simple yes or no answer is not possible and you get detailed descriptions of the situation. The reason for this is that a yes or a no there can have a different meaning than in Western countries. One reason is that a no is there interpreted as a denial of the person. The separation between the factual and the person behind it is there is not as clear as it is for example in Germany.
It helps to take the time to understand the basics of the culture of the contractor and maybe even invite the team to Germany or to visit it abroad.
Conclusion
Communication with external developers should not be underestimated. If possible, you should set up their own internal team and set as a complement to external assistance. So make sure founders that they keep track of what is being developed and they can manage their projects better.
If a team for reasons of cost should not be realistic, then you should make a strong involvement and close communication.
Image: Ana Barateiro / Getty Images
Shortlink:
Posted by
Recent Comments