I often meet various bogeyman stories about miscommunication in the software development outsourcing. They are so usual that nobody even questions their one-sided treatment. And almost nobody asks developers what leads to miscommunication because usually it is just too late to ask or no one cares of his or her opinion. So, it’s interesting to take a different track and clarify some typical miscommunication issues which occur in the programming practice from the point of view of developers.
We’ve interviewed 5 programmers and 3 project managers (PMs) from several Ukrainian outsourcing companies to reveal generic issues that lead to miscommunication on a project. Here you’ll find only real people, real stories, and real experience. The opinions of our respondents are at times controversial, possibly because our life is not so one-dimensional and straightforward as some recommendations in the textbooks. However, we hope that these examples will help to understand the causes of miscommunication and how to avoid it in software development projects with a dedicated developer team.
So, let’s consider common situations that a ordinary developer, tester or PM faces quite often. Note that miscommunication issues that emerged due to a poor language command were mentioned only once, though oblique.
Client Side: More Communication Is Never Too Much
Documentation and Documenting
It is very important to talk the client’s language and understand it. There are often-met problems because of incorrect interpretation. For example, the specification can be interpreted differently even not on a lingual but technical levels by programmers and QA. A.U., PM.
Now our client provokes miscommunication by rejecting writing any documentation (even minimal). Because of it we have situations when some functionality should be rewritten for several times because each team member has his or her own vision of how it should work. Hence testers don’t understand clearly how to test as it is not obvious how this or that feature should work and there is no documentation to refer to for respective information. Everything should be discussed and committed. A.G., developer.
Once a client supposed some feature but didn’t reflect it in the documentation. When the feature had not been implemented, he was shocked as it was obvious for him but the team hadn’t even twig. A.U., PM.
Another source of miscommunication is incomplete information. For example, a customer communicates details to one team member expecting him or her to distribute the data instead of making a group chat in Skype or making a mailout. A.G., developer.
My personal experience cues that miscommunication occurs between the customer and the service provider referring a criteria of a job made. That is why I think Fixed Price projects are very often for the loss for both parties. It is impossible to describe all possible requirements to the product validation. So there will be inevitable attempts of interpretation on one’s side.
Some problems with documentation treating were fixed by introducing of BA (Business Analyst), who took a neutral position and developed documentation that was readable and understandable for all sides of the development process. D.F., PM.
Trust and Opennes
There can be obstacles when the client doesn’t trust the team and talks round corners or gives information in portions. Eventually some part of code should be rewritten. Confidence is a must and without it and normal open communication there won’t be high productivity and innovation. A team feels the distrust and uninvolvement so they don’t care much about the result. They just don’t feel attached and responsible about the project outcome. A.U., PM.
Sometimes customers give vague requirements. In my practice there also was an experience of offensive communication that led to the personal conflict and then to a total miscomprehension. D.L., developer.
Clearness and Detailed Explanation
“When the process of communication fails, we can face the following situations:
- The customer gave a task to evaluate and find a way to implement but the team started to develop instead of just sending a report;
- The development team gets to a task with insufficient coordination with the customer during the implementation phase. Eventually he doesn’t approve the chosen solution;
- Sometimes developers start processing an assigned bug though the improvements imply severe functional changes, not approved by the customer.” S.Ch., PM.
In my opinion miscommunication emerges because of lack of discussion of the problem. Idleness, time shortage or poor language skills are the main obstacles to ask for advice: “I see this prob this way and am going to solve it that way and what do you think of that?” Once there was a situation when a developer was implementing a task for two weeks and finally it turned out he made a wrong task. So to avoid miscommunication everything should be discussed with the team or PM. D.L., developer.
Sometimes clients just don’t give weight to user review and / or forget to pass them to the development team, and developers are not aware of the feedback. A.U, PM.
The client may create miscommunication by not wanting to give a detailed and in-time feedback. Eventually after the finalization of the task the client asks to redevelop, and both sides are dissatisfied. A.G., developer.
Once there was a misconception of overtime work. The customer (product owner) put overtimes on every issue without real necessity. For example: A.G., developer.
1). We were put an overtime a week before the release. Though we worked on schedule and should have finished everything in time.
2). Long overtimes demotivate, decrease effectiveness and don’t bring advantage. 2 weeks without any days-off influence the productivity immensely but 1-2 overtime days won’t be noticeable in 1 week distance.
But after communicating these situations with the customer he rejected this approach and we had no overtimes since that time.
Different Approach to Work
I see no problems with language miscommunication, as it is what the team usually fears. Maybe, some issues related to different schedule and approach to work for Russians / Europeans / Ukrainians / Americans, etc. are more important. But these ones are easy to identify, talk about and fix by means of a regular dialog. D.F., PM.
Communicate, communicate, and once more communicate! The more detailed, complete and clear information the team has and better understands project goals and tasks, the better the result is. Regularly provide the team with a comprehensive feedback and don’t abuse of (unnecessary) overtime work. Ensure the communication is bidirectional. Literally – every developer may spot a bottleneck in the task or even entire project. Such notices from developers may play a key role in the project lifetime if they are treated correctly.
Team vs. PM
Oh, there are also PMs that are not effectively communicating the needs of the client to a programming team. For example, such scenarios are possible: One PM is leading negotiations and discussions, and the others are leading the project. Eventually the information is not received comprehensively. A.U, PM.
First of all, miscommunication between the team and the project manager. It’s a pretty sad case if PM is a person who defines a schedule, deadlines, and delivers news to the customer. We have not fixed the problem as it seemed to be kinda personal for the team. It’s weird and wrong but such cases happen. D.F., PM.
Striving to follow Agile development methodology, don’t forget common sense and human nature.
Developers vs. Testers
“Well, we are all different. I would say most miscommunication cases happen somewhere between development and testing and the main reason for that is fuzzy requirements, which could be treated this or that way.
To overcome the difficulty I would suggest the tight collaboration between these two teams:
- In the process of documentation development
- Use QA in the process of architecture / DB projecting
- Use devs in the process of test cases development
Usually, miscommunication of any kind is a big trouble in the project. It could be lack of good management, lack of team building, an invalid software development approach, non defined standards, etc. Each and every case should be analysed and treated separately.” D.F., PM.
Testers are seldom wrong. Maybe sometimes too zealous, but that’s their job and a positive trait. Miscommunication can emerge only because of bad documentation. Testers verify functionality according to specifications and if there’s something omitted or not considered each will figure out which he or she thinks correct. T.M, developer.
My development team is closely communicating with our QA team, as it is supposed when utilizing SCRUM. A feature is developed and tested right away. We receive feedbacks from the testers regarding UX as well and make changes if needed. I like it this way. A.S, Tech lead.
In my opinion, the QA team is a crucial part of the development process and should be considered as an associate in getting any of architectural decisions making. This is not a usual practice, though it has shown its effectiveness, because of their (QA) ability to question everything they see. Sometimes it gets annoying, though correct handling and collaboration of the QA and dev teams could get your product into the best shape ever. D.F., PM.
On the other side, I’ve noticed the opposite practice, the kanban, when developers help testing team in performing of quality assurance works, though it is much less effective.
In general, with a correct approach, the tester is your best friend and helps a lot, no matter if your team works locally or remotely. And don’t try to conflict with them or put development against testing: such an approach is almost surely about to greatly decrease the overall team performance.
Miscommunication at the level “Developer – Tester” is quite costly. To avoid it you should have either detailed and regularly refreshable documentation, or close and permanent communication between developers and testers, involving the latter in the project planning. Your development team must clearly recognize the importance of QA process and consider them as colleagues who share the responsibility for the product.
Communication Tools: Voice Chat (Skype) vs. E-mail
According to Agile-like development methodologies, e-mails introduce a higher communication latency which is not acceptable, hence any prompt topics should be discussed through Skype or other IMs. But! As a manager, I encourage developers to write e-mails to train their skills to express thoughts in a clean and concise way. So some issues are definitely better to decide through mails. A list of topics to discuss should be sent before a Skype conference with the customer and follow-up after it. S.Ch., PM.
I can say for sure that Skype works fine to decide urgent issues but mails always preserve history and work good when there is a big ping with the client. So I’d rather say that really important messages should be e-mailed putting all relevant people in /CC. And Skype only when you have no need to show your manager each client’s word. T.M., developer.
All questions regarding the work should be e-mailed. It is a document to reference and forward. You also have more time to provide an accurate answer. D.L., developer.
“I’d rather describe pros and cons of both Skype and e-mails.
+ Fast reply, through 5 minutes you can discuss issues that could take the whole day
+ Non formal style that simplifies and triggers information interchange
- Not an authentic information source that hardly can be referenced to
+ It is also an off-line information as all the correspondence is saved on SMTP servers. You can forward them if required, so no one can fake the information
+ Allows adding people in CC and even BCC to let them follow the discussion
- Time. I was taught that it is a fine practice to answer an e-mail during 1-2 hours after it came in. But I face the situation when a customer answers during 24 hours or even never
I email things like this:
- Large discussions about architecture, development process that hypothetically will take a lot of time (more than a day) and require several people involved;
- Information letters about new instruments developed, estimates, national holidays, days-off and compensatory leaves, mails that can be answered just Yes or No.” A.G., developer.
Drawing a line, I’d like to emphasize 5 rules to consider when setting communication standards in software development projects (especially outsourcing ones):
- Communicate each item: business initiatives, project aims, financial issues, delivery model, etc. Each technical feature should be thoroughly discussed. If you imply something, manifest it via emails, in documentation, etc. Note that some things may not be obvious to your team.
- Personalize your work. Communicate to team members, tell them a bit more about yourself and find out about them. Make the team members motivated to give perfect quality and results.
- Always provide feedbacks! Feedbacks motivate greatly, even if they are not positive. But don’t blame unless you feel this really helps your project. Developers must understand they have a common goal with you – to make a great product.
- Solve challenges before they become heavy odds. Highlight that you want to know all narrow places straight ahead. Encourage questioning!
- Use e-mail for really important questions to avoid wasting developer’s and your own time on empty and irrelevant talks.
And may all your projects be only successful!
About the Author
Dmitriy Kharchenko is the CEO at Acceptic Ltd, a Ukrainian software development company. The core company’s specialization is creation of complex custom applications, as well as the dedicated developer team service. Acceptic provides high quality programming in Java, .Net, PHP, C/C++: web, mobile, enterprise and business applications.
How to Avoid Miscommunication in Software Development Projects – in Real Examples
Rating: stars out of 5 (based on 9 DZone user ratings)