“That’s not what your developer told me.” The client says it calmly, without any complaint, and in that same second the PM understands that the project has a communication channel they didn’t know about. The developer did nothing wrong. The client asked directly, so the developer answered.
Most teams have a communication structure, it’s just that nobody designed it. It emerged on its own, from who knows whom, who replies faster and who was at the first meeting. A structure like that works as long as the project runs smoothly, and falls apart at the first difficult message.
Count people, not roles
A project chart usually has six or eight names on it. In reality more people work on the project, you just can’t see some of them.
There is someone in legal who holds up the contract once a month. There is an administrator on the client’s side without whom nothing goes to production. There is a person in accounting who decides whether the supplier gets paid on time. And there is the line manager of someone on the team, who can pull that person onto another task.
None of them attends the daily and none of them reads the status. Each of them can stop the project for a week.
So the first step of the audit is simple: list everyone who, over the last month, did something for the project or held something up in it. The list almost always turns out longer than the chart.
Next to each name, add one word: what that person can stop. A contract, a deployment, a payment, a team member. That column comes in useful more often than the chart itself, because it shows who you need to call before things come to a halt.
Check who talks to whom
The second step is channels. Next to each person on the team, write down who on the client’s side they are in direct contact with. What counts is who they actually write and talk to, not who they are supposed to.
Usually one of three pictures comes out.
The funnel. Everything goes through the PM. The client has a single source of information, but the PM becomes a bottleneck and every technical question waits in their inbox.
The mesh. Everyone talks to everyone. It’s fast, but nobody knows what was promised to whom, and the client picks the person who will give the more convenient answer. This is also where the client’s “done” and the team’s “done” drift apart fastest.
The accident. A bit of funnel, a bit of mesh, depending on the day. It is the most common picture and the hardest one to run, because nobody can say what the rule is.
Each of these setups can be made to work, provided someone chose it on purpose and everyone knows which one applies.
Three agreements that put the rest in order
You don’t need to draw the communication structure across half a wall. Three agreements are enough, said out loud to the team and to the client.
Who talks about dates and money. One person, usually the PM. Everyone else can talk to the client about the substance of the work, but to the questions “when?” and “how much?” they answer “I’ll check and get back to you”.
Who talks to whom directly. The developer with the client’s administrator about the environment, the analyst with the user about requirements. These channels shorten the road and are worth keeping, provided they are named.
Where what was agreed ends up. Every conversation in which something was promised ends with one sentence in a place the whole team can see. Without that, even well-arranged channels produce surprises, and it is exactly how things fall through the cracks.
In my experience the first agreement gives the most. Once the team knows they don’t have to answer the client’s question about the deadline, they talk to the client more freely about everything else.
One question for this week
List the people on your team who talked to the client without you over the last month. Do you know what they agreed?
All situations described in this article are based on real events, but contain no company names, no individual names, and no data from any specific project.
