Communication is constant and ubiquitous – something we do with nary a thought throughout our lives. It’s so natural in fact that we tend to take it for granted. After all, when was the last time you engaged in a meta-conversation about the efficacy of a discussion you just finished? Alternatively, when did you last work on improving your lexis or grammar? If you’re like me, it’s been a while. Because our communication styles seem perfectly adequate for our daily personal lives, we tend to focus on more pressing concerns. For a technologist, that likely involves implementing some aspect of a project… and failing. Lack of communication is often the problem.
A Clinic on the river in Benin
Software shops don’t tend to advertise it, but programming and IT are risky business. An IBM study found that nearly 60 percent of projects fail and that human, rather than technological, factors play a dominant role. Miscommunication is among the surest ways to kill a project. Sponsors may be misinformed about progress and withdraw support after subsequent disappointment. Business analysts may misunderstand users’ needs, developers may misinterpret analysts’ requirements, and because software development is often a collaborative endeavor, developers may even misunderstand one another. A lot can go wrong and — statistically — probably will. Our collective communication skills are simply not as good as we’re inclined to think.
The good news is that being aware of the communication conundrum is itself a tremendous step toward addressing it. This was brilliantly illustrated by a recent trip of mine to Benin. I was there as a software developer on the OpenLMIS project, accompanied by my French-speaking colleague and interpreter Nora Phillips. I was also equipped with a French vocabulary limited near exclusively to “croissant,” “crème brûlée,” and “merci.” Despite the language barrier, the opportunity to observe and communicate with our end users was invaluable.
Logisticians are not always sitting at a desk when filling out forms.
I had always been told that the Internet connectivity in Benin was poor, and had interpreted this to mean slow. I quickly found that it’s instead highly sporadic. For a web application like OpenLMIS, this is a critically important difference. Observing it made me reconsider technical approaches made within the software’s code. It even allowed me to propose entirely new real world activities and processes that could be supported by potential new additions to the software. I gleaned a myriad of details about our logisticians as well. For example, they make frequent use of checkboxes that have uncommonly short labels within our forms. Because logisticians tend to do so without benefit of sitting at a desk, our forms are unnecessarily difficult for them to use. The logisticians wouldn’t have known to ask, but as a developer I could immediately see that increasing the invisible “hit area” associated with our checkboxes would cheaply and effectively improve their experience. The list of such examples could certainly go on.
By putting a developer in direct contact with our end users and their environment, our team deliberately added a new perspective and voice to those typically heard within product-requirement discussions. It had obvious benefit and helped nudge OpenLMIS toward the minority of projects destined to succeed. Technical endeavors desperately need this kind of mindset – one that proactively aims to foster communication.
To those who championed the trip and hosted us in Benin: merci beaucoup!