Best Communication Practices We Use To Keep Our Clients In The Loop

There are many best practices for efficient communication in software development out there. The most hip frameworks for building digital products, Scrum and Kanban, offer some good fundamentals for development teams. They recommend things like daily standups, sprint plannings, reviews, and iterations to establish a feedback loop between product owners, developers, and clients. Those can be very helpful and, by all means, we often use them to our advantage.

Understanding those rules and recommendations and building on top of them has proven to be most beneficial for improving information flow and therefore increasing our clients’ happiness.

As we work with different people on projects of all shapes and sizes, it’s impossible to follow just one particular way of doing things. But after eight years of working as a remote team for multiple businesses, we’ve established some best communication practices that will work as a solid basis for other agencies.

Communication with Sales

A smooth communication process establishes trust and that’s critical for the existence of any business. Obvious as it sounds, you must work toward it since day one. Since the very first email and phone call. At this stage, our account managers stick to a few rules:

• Keep the response time to the initial message below 24h
• Make the potential client feel that we care about their success by asking meaningful questions
• Meet face-to-face with the client as quickly as possible
• Provide an estimate for the project fast, with relevant comments explaining the numbers
• Stay in touch and get to know the client better, even if there’s no update from the team
• Use business language instead of tech lingo, so that everyone’s always on the same page

During the sales process, we also try to introduce key people that will handle the work, like business analysts, tech leads, and project managers, so that the client gets the clearest picture of how our collaboration will look. 

But the role of our account team doesn’t end there. We want to keep it personal, so during regular status calls your account manager will ask how things are going business-wise. Not just for the sake of keeping you talking, though. It happens that your future plans and growth influence the development work on our side. Conversations like these allow us to adjust our work accordingly and help you out if we can.

The last thing here, which stems from one of our core values—embrace responsibility and be honest—is to keep it real. No BS just to win the project.

Best Communication Practices in Software Development

Let’s say you’ve gone through the sales process and the first impression exceeds your expectations. You got an estimate, met the business analyst, maybe even grabbed a beer with the account manager who led you through the process.

All those things won’t matter if everything falls apart once the sales process is done, and you’re left with no idea as to where you stand.

As a software development company, we are in the long-term relationship business. If we won’t be able to convince our clients stick with us, we’ll have to invest much more in sales and constantly hustle after new projects. The same applies to our clients, who usually want to find one reliable partner to mitigate the risks stemming from starting a new collaboration.

So what can we do to make our clients happy?

The first step is, obviously, to deliver quality software according to established deadlines and standards. The second is smooth communication. And I believe that both those things go hand in hand.

Navigating the project well is the defining characteristic of a reliable software development company. When they run transparent communications and are straightforward in saying the toughest things, the clients assume (correctly) that they’re in good hands. There will always be some deviations from the established plan. There will always be unexpected issues with this or that feature. It’s how you handle them that makes a difference.

Keeping a client in the loop during the good and the bad proves that you will do your best to keep the client abreast of everything, even it that means going through something you’d find personally uncomfortable.

Unfortunately, there are just too many examples of this being done badly. Businesses prefer to downplay problems, blame their shortcomings on circumstances, go silent, or go so far as to lie about project status. And I’m sure that any client wants to know what’s going on, especially when things aren’t exactly going well.

Our project management team drew up a couple of cardinal points in that we stick to when doing outsourced software development work with a client. Here’s what we do, and what basically anyone in any software agency can, to build trust and keep clients in the loop:

1. Establish a Plan for Communication

The first thing a project manager should do when the project starts, is to organize an introduction call and establish what kind of communication the client expects. There’s no one-size-fits-all solution, as too many factors come into play here—Is the client a technical person? Is the product critical for their business? How many decision makers are involved in the process? During this call, the following aspects should be talked through:

• Client expectations
• The responsibilities of both the client and the team
• The kind of meetings that will be held and their frequency (standups, plannings, demo, status meetings, etc.)
• Who the decision makers are
• How Slack will be used
• What other tools will be needed

2. Introduce the Client to All Project Tools

Project management tools can be tricky and their setup may vary from one project to another. Therefore explaining how the Jira or Trello board will be used is very important, even if a client had some prior experience with those tools.

To make sure our work follows their vision, we want the clients to be highly engaged. Therefore we mention the client in tickets, engage them in backlog creation, and make them responsible for moving a task from “acceptance testing” to “done” as a final step before we call it ready.

Tools we use in our daily communication. 

3. Make It Constructive

We don’t want to make a thirty-minute call one hour long just for the sake of talking. It’s your PM’s role to be as accurate and objective as possible and move straight to the point.

This happened. We expect such results based on existing evidence. We believe this is the best solution and we will solve the obstacle. This is what it means for our timeline.

This is especially important if something unexpected happened in the project. There’s no point in playing the blame game in such cases. There’s also no point in trying to spin a bad thing into a not-so-bad thing, as it will definitely backfire eventually and damage our credibility in the long run. It’s crucial to explain the circumstances, say what’s true, talk about next steps, and deliver according to promises. Such an approach increases the client’s confidence in the team and their handling of difficult situations in the future.

4. Keep the Communication Open for the Team

If it happens that a client has something to discuss with one of developers, she’s obviously entitled to connect on Slack or schedule a call with him. Yet, in such cases, a developer is obliged to pass the context to the whole team for the future reference. A PM will always encourage to keep the whole communication on a project’s channel as all technical discussions may affect others’ work.

5. Translate Tech Into Business Language

Every project has its tech lead who is responsible for technical decisions (unless that responsibility lies with the client) and who explains tech solutions and logic behind them to the whole team and the client. For a non-technical entrepreneur, though, it may remain meaningless as he may not speak the same language as programmers do. It’s then the PM’s job to translate it into business terms and explain what follows. It’s important to double-check whether the client understood the reasons behind the decision and its effects on the project.

6. Don’t Fixate on Agile Development

The Agile methodology provides a set of rules that help deliver successful product. Not all of them apply, however, to outsourcing software development to some external team or to all kinds of projects. So our approach is to know all the rules and then “break” them according to the project’s needs.

For example, in one of our projects we’ve been working in iterations, with Jira software, acceptance tests, standups, and all that stuff, but the budget for the project was fixed. Which means that after every sprint we summarized how much we’ve spent in comparison to primary assumptions. Not very Agile, but we agreed that it’s simply the best solution for the project.

 

All the rules and guidelines enhance our predictability, something that our clients expect and rely on. Our system essentially boils down to being honest and flexible, to learning the preferences of our business partners, using our knowledge and experience, and adapting successfully to shifting circumstances. Remember this: investing your time in a clear communication process yields high returns—especially in the early stages of a collaboration.