“How do you overcome communication challenges?”
During early talks with a prospect, I was asked how we overcome communication challenges. I immediately thought about the Communications & Reporting Matrix we developed a few years ago and have attempted to refine ever since (see the figure below). It contains quite a lot of detail, yet it still does not tell the whole truth.
Process / Communications and Reporting Matrix
The matrix is basically a grid which captures the communication patterns between the Product Owner – on the client’s side – and the Team Lead / Development Team – on Selleo’s side. A kind of guide with who, what and when. Each time we found something that worked well with a client, we modified the grid, hoping to eventually arrive at a productive framework. We even included the matrix in the Contracts/SOWs signed with our clients. Somewhat surprisingly, after some time we noticed that:
* in practice, we never fully applied the matrix as agreed with the client,
* the actual communication practices differed, often widely, both across the teams and within a specific team for different clients served,
*although we diverted from the template and used varied communication practices, things very often worked well.
Though we still use the matrix, we treat it with an ample dose of scepticism when approached by a new client. This scepticism it does deserve.
The major differentiator behind the practices seems to be the PO’s communication style. Some POs favour written and asynchronous communication, e.g. e-mails and tickets, in the project management tool. We have, for example, served a client who first talked to us only when he came to visit us after months of collaboration. We talk to each other a lot when we are physically collocated, yet teleconferences are virtually absent from our daily interactions. By contrast, other POs are much more comfortable with spoken and synchronous communication. They prefer to teleconference / talk on the phone and sometimes seem to treat e-mail or the ticketing system as a last resort. One of our clients operating at this extreme,even had their corporate VOIP phone installed at our premises to be able to reach us in the way he found most convenient.
How to arrive at an effective communication pattern?
If you are a Product Owner outsourcing software development – know thyself. Understand your communication style and personal preferences in this respect and frankly tell the team about them upfront. If you are developers delivering the services – listen (or read!) carefully from the very beginning. Having found out more about the specific client, tailor the process to fit their style and preferences. By no means adhere rigidly to what you believe works, even if it worked very well in the past.
If you have a predefined process and insist on compliance with it, your approach will appeal to some POs and alienate others. So it can pay dividends to have a process framework but remain flexible with it. If, for examples, you are working with a very busy entrepreneur, who is constantly pressed for time, develop executable tech specs yourself, have them approved by the client and try not to bother them during development; if the client has no time to accept deliverables during a teleconference, record video presentations for the client to review when it is convenient for them. By contrast, if the Product Owner likes to interact verbally, use regular teleconferencing; you can develop their software against higher-level tech specs as the client is available to clarify things along the way.
One might say the vendor’s Team Lead’s style and preferences also play a role. If only because, for instance, the Team Lead copes better writing rather than speaking the client’s language. They in fact often do play a role. They should not though. A good service provider and their people should fit in with the client served rather than the other way round, at least when they are serious about the quality of service they deliver and the customer experience they attempt to ensure.
There is no one universal way which will work for all the Product Owners and their teams. An effective way to communicate needs to be collaboratively discovered by the specific people to work on the project. You may have a blueprint from which to start and which to tailor to suit the preferences of those you deliver your service to. The template may actually capture some of the good practices as well as strive to eliminate the unproductive ones. Still, remember it is just a blueprint – a place from where to start rather than to arrive at. People differ and – if only because of that – there are many ways of arriving at a good solution. And, after all, communication is just a means to an end and not an end in itself, at least in the pragmatic environment of software development.