I recently sat through a remediation meeting with a customer.

They had a list of complaints, some valid and others less so, but one theme kept coming back around:  “We don’t have enough visibility. We can’t communicate properly with the client.”

On the face of it, that didn’t quite make sense.  We speak to them every single day.  There are regular scheduled calls, status reports, and emails. So there is no shortage of contact.

And yet, clearly, something wasn’t working.  There was a gap between the frequency of communication and the effectiveness of communication.

Visibility isn’t volume

One of the traps we fall into as project teams is assuming that talking regularly often equals being transparent.

It doesn’t (as I found out!).

You can have daily calls and still leave your customer unsure about:

• What’s actually progressing, and how
  
• What’s uncertain or at risk
  
• What decisions are pending
  
• What might change next week
  

If all they hear is activity without context, they’re left trying to infer meaning, particularly if they are not the subject matter experts.  From their point of view, lack of visibility makes them look ineffective to their customer, even if work is genuinely happening behind the scenes.

The temptation to hold things back

There’s another, less comfortable layer to this.  We had been intentionally holding things back at times.  Not out of bad intent, but out of experience.  We’d seen firsthand that draft ideas, early technical schemes, or provisional options had passed straight on to the end-customer, unfiltered, without caveats, and suddenly we’d found ourselves committed to things that were never agreed.  Things that later turn out to be technically unworkable, risky, or simply not the right solution, and it was often difficult or impossible to reverse out of without upsetting the client.

So we’d become cautious.  We’d waited until something was “safe” to share.  We polished things, we qualified artefacts internally, all to try and protect the team from being boxed into promises too early.

It felt like the responsible thing to do, but from the customer’s side, it had come across as opaque.

The real issue

Looking back, the issue wasn’t that we weren’t communicating.  It’s that we hadn’t agreed on how information should be handled once it’s shared.  

A different way to think about communication

What this experience reinforced for me is that effective communication isn’t about sharing more.

It’s about being clear on:

• What is exploratory vs committed
  
• What can be shared onward vs what must stay within the project team
  
• What decisions are reversible, and which are not
  
• What assumptions are still being tested
  

So, the question I’m taking away from this experience is a simple one:

“Where am I withholding clarity to avoid risk, and where is that actually creating a different risk instead?”

Thanks for reading. I hope you found some useful snippets of information in this post. Let me know in the comments if this resonated or if you’ve had a different experience.

Tom