Your product might be late. Your product might be of subpar quality. Even worse, your product might not arrive at all, or there might not even be a product.
All of these are potential endings to product development founded upon bad communication. Let’s look at a few cases from our latest project and see the (potential) damage done when things were communicated poorly or not at all.
Listen to the expert! Nah, it’ll be fine…
THE ISSUE: There were no development and staging environments set up. Instead, we were working with the client’s production database, however not directly, but our requests were being sent to a clone of the live version. This clone was then supposed to mirror and sync with the actual production database, but we were never sure of the directions of this mirroring and syncing mechanism.
WHAT WAS COMMUNICATED: Even though most of the team brought this up as an issue, the expert for testing functionalities (our QA) raised this several times, especially to the client arguing that it will be nearly impossible for him to do his job properly. The client wasn’t concerned about this at all. He ignored most of the complaints and simply reassured us that there was nothing to worry about and that it would all be ok.
THE DAMAGE: Our QA never knew what would and wouldn’t be reflected onto the production environment. Thus, he couldn’t figure out if the feature we developed wasn’t working or if it was just the client’s environment being out of sync again. His testing capabilities were limited too since he was afraid of tampering with live users and their data. Consequently, the frontend team had to go back and forth and work on features that were supposedly finished months ago. This did not bode well for the quality of the solutions and the codebase nor for the team’s morale. Oh, and lots of time and money were lost, obviously.
Distance doesn’t separate people, silence does.
THE ISSUE: The project is a dashboard application. The client wants a quality-of-life feature that automatically remembers the latest dashboard each user used, so that every time they log back in, they are redirected to where they left off. The optimal solution for this feature is to have the last used dashboard saved on the backend. The client never mentioned if this feature was available on his backend and we never asked. Instead, we put our heads down and got to work.
WHAT WAS COMMUNICATED: The client insisted on this feature, emphasizing its importance and the development team complied. Outside of that, nothing else was communicated. We went in blindly and the client never even considered our obliviousness.
THE DAMAGE: We managed to develop a second-rate solution where we saved the latest used dashboard to the user’s local storage. And, this worked fine when there was only one user using a single PC. However, the moment our QA and client started testing this feature with various accounts on the same PC, all the user data conflicts emerged and bugs surfaced. We tried our best to make it work with fixes upon fixes, however, the limit of this local storage feature were reached. We threw up our hands in the air and proclaimed that nothing more could be done.
However, one team member, while fiddling with the client’s live version of the dashboard, noticed that this feature was working flawlessly on his part. We immediately investigated this and found out that he had his own backend solution for this, which we desperately needed. So, we jumped ship and documented and adopted this solution right away. Unfortunately, all these fixes and silence cost the project lots of development time and money again.
I Just Called To Say I Love You…
THE ISSUE: In order to avoid going back and forth between finished features and/or components, which can quickly burn out your development team, a deal was struck between the client and the development team that the client should sign off on each feature and/or component and how their solution was envisioned (design-wise) before the development team gets to work. However, the client would sometimes go completely silent for days on end.
WHAT WAS COMMUNICATED: Again, nothing. The client failed to inform us that we would be out of touch with each other for days, which also meant that the client couldn’t respond to our pleas for approval. In fact, the client couldn’t respond at all, so we had no idea what was going on.
THE DAMAGE: Development time (and money, of course) was lost on debating which feature or component should be developed next without the client. Obviously, our choice wasn’t always correct, which meant that every time the client was unsatisfied with our solutions, we had to go back and redo them, which cost even more development time and money. This also sometimes left a bad taste in our mouths when we were starting up work on a new feature or component.
Communication works for those who work at it
Even though we set up some pretty good ground rules with the client regarding communication, sometimes this failed us. Or, in all actuality, sometimes we failed to meet the standards we had set for ourselves.
This is proof that even a team of professionals and a financially invested party could not deliver completely on their promise, resulting in some damages, which could have been avoided.
However, the important thing is to start mitigating the damages by looking for open discussion and solutions, fixing the communication gaps, and keeping the communication channels open.