We talk a lot on the Ghyston blog about things you can do to make the most of your software project, ranging from technical knowledge to practical planning. The one crucial thing we haven’t really covered is the act of talking itself. Great communication is all too often an afterthought, something we assume will just happen organically or just gets improvised as the project unfolds. When you are running a lengthy, complex software project, it’s absolutely critical to make regular planned communication between all stakeholders a non-negotiable.
Get to know each other
As with any healthy relationship, the development team and the client need to build rapport, and that means regular communication in a mode that is appropriate. We don't bandy around words like 'team building’ lightly as we know it strikes dread into even the most gregarious of souls, but when you are beginning a new relationship there really is nothing like spending time together. If sitting in a circle passing a rainstick around isn’t for you, perhaps consider a period of time where you are co-located for a week or two; even something as simple as sharing an office for a period of time can really help to build bonds. Use it as an opportunity to answer some fundamental questions about how communication is going to work as the project progresses.
Of course it’s probably not practicable nor desirable to spend every working hour together for the duration of the project! So agree early on what communication methods are going to work for you and agree timescales at the start.
Choose your channel
At Ghyston we use three main channels of communication:
Email is something we are all familiar with, perhaps too familiar, so it’s important to recognise its limitations as well as its merits. Email is great for details, allowing somebody to really delve into any finely detailed specifics. Our PMs use it like a newsletter, sending out weekly status emails containing high level summaries on issues that are pertinent to the key stakeholders for the week ahead.
While it’s useful to have an electronic paper trail to refer back to, there is a danger with email that thoughts are misunderstood or tone misconstrued. Rather than trying to clear things up through endless lengthy email discussions, why not sign off with an invitation to speak about things? Face to face or telephone conversations are the best way to nip any ambiguity in the bud and keep the tone friendly.
Instant messaging (IM) can be perfect for small questions. Ironically for a system whose USP is its speed, in our experience responses using this medium are often anything but instant. If the two people involved are enthusiastic users of Microsoft Teams or Slack, then it can work really well. However, for those not used to working with (IM) it can be easy to ignore leaving the other party waiting a long time for a response.
Phone and video calls are still your best bet for things than need a really urgent response. We often pick up the phone in combination with another method, for example shortly after emailing some in-depth documents. You can then focus the other party on what’s important and explain the nuanced details while they digest the printed information.
Even if other methods of communication are working, our PMs still swear by their weekly status phone calls with clients. These are brief, no more than half an hour and offer a forum to report on status and bring up any issues. You don’t need to go into too much detail on any one issue during these conversations - just flag up anything major and book a separate call or meeting to deal with it in isolation.
Who you gonna call?
The question remains though, who should be doing the talking? Many companies shy away from letting clients speak directly to developers and leave the PM to act as intermediary. It is sensible to have a single point of contact, particularly when working with large teams, but there is something to be said for a certain level of direct access. This might work best in small meetings where different personnel can be on hand to answer questions that fall specifically within their remit.
To interrupt or to not interrupt, that is the question
Developers and managers work to different schedules. PMs are used to short, regular time slots, and are generally happy being disrupted at different points throughout the day to take an unplanned call. A developer on the other hand typically works in periods of half a day and may need to build momentum before they really get going. So an unexpected phone call may mean they have to start all over again once the conversation has ended. To get the most out of our developers we recommend scheduling meetings in advance and find that a natural break such a lunch works well.
Working out what communication is going to be effective is just as important as planning the project itself; good communication prevents misunderstandings, saves time, stress and ultimately money.
