I’m Krzysztof Nyrek
a Project Manager Storyteller Writer

How Many People Are Actually in Your Project, and Who Talks to the Client?

“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.

Good Decision, Bad Outcome: Why Project Reviews Punish the Wrong Thing

“Who decided to go with that supplier?” In a review of a project that ended badly, this question is one of the first to be asked. Someone raises a hand or looks down, and from that moment the conversation is about the person, not about the decision.

Meanwhile the decision may have been a good one. The supplier had the best references, the shortest lead time and a sensible price. Six months later they lost two key people and the delivery fell apart. On the day of the choice nobody knew that, including the supplier.

The outcome is not the same thing as the decision

Two things make up an outcome: the quality of the decision, and what happened afterwards that nobody had any influence over. A good decision can end badly. A bad decision can end well, because it just happened to work out.

Psychology has a name for this: outcome bias. Knowing the ending, we judge the decision through that ending and stop remembering how much was known at the moment of the choice. After the fact everything looks obvious. “It was clear that company was too small.” On the day of the decision it wasn’t clear, it was one of five risks on the list.

In projects this bias is especially expensive, because reviews happen mainly when something has gone wrong. A project that succeeded rarely gets taken apart. As a result, bad decisions with a lucky ending pass unnoticed, and good decisions with an unlucky ending get labelled as mistakes.

What the team learns from a review like that

People draw a conclusion quickly, just not the one that was intended. Instead of “make better decisions” they hear “don’t make decisions you can get blamed for”.

The effects show up in the next projects. The biggest supplier gets chosen, even if it is the worse one, because nobody will question that choice. Every decision gets three signatures so that responsibility is spread thin. The risks that were worth taking disappear from the plan, and with them goes the chance of anything better than an average result.

The other side is just as costly. A PM who got away with a bad decision is praised and repeats the same move in the next project. This time the luck may run out.

How to review decisions instead of outcomes

The point is not to stop holding anyone accountable for anything. The point is to hold people accountable for what they had influence over. In practice four things help.

Write the decision down on the day it is made. Three lines: what we chose, what we knew, which options were dropped and why. Without that record, a review six months later rests on memory, and memory already knows the ending. A premortem before kickoff gives you the list of risks that were known at the time.

In the review, start with the question about knowledge. What was known then? What could have been checked and wasn’t? Only the answer to the second question says anything about the quality of the decision.

Separate bad luck from negligence. People leaving the supplier is bad luck. Not asking how many people the delivery depends on is negligence. Both can produce the same outcome, but only the second one has a lesson in it.

Review the projects that succeeded, too. Even one a quarter. In my experience, successful projects contain just as many questionable decisions as failed ones, it’s just that nobody went looking for them.

A review like this takes longer than pointing at someone. What it gives you is a team that isn’t afraid to decide, and in a project that is worth more than one accurately assigned blame.

One question for this week

Think back to the last decision in your project that was judged a mistake. Was it judged by what was known on the day of the choice, or by how it ended?

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.

Green on the Dashboard, Red in the Hallway

“The dashboard is all green, so where is this escalation coming from?” That question usually comes from a sponsor who opened the dashboard in the morning and heard from the client in the afternoon that the rollout is stuck. Both pieces of information are true. The dashboard really was green and the rollout really was stuck.

In a moment like that it’s easy to assume someone was hiding the truth. In my experience, usually nobody was hiding anything. The tool showed exactly what it is able to show, which is the last thing somebody typed into it.

What the dashboard actually shows

A status tool doesn’t see the work. It sees entries about the work. Between the two there is a person who has to find a moment to update the entry, and has to decide there is something worth updating.

Three things follow from that, and they are worth keeping in mind every time you look at a green field.

A status has a date you can’t see. A green field entered two weeks ago looks exactly like a green field entered this morning. Most dashboards show the colour of the information, not its age.

A status is an opinion, not a measurement. “On track” means that the person entering it believed so at the moment of entering it. If they didn’t yet know about the problem at the supplier, their green was honest and untrue at the same time. It’s the same mechanism that keeps status reports green right up until they turn red.

Changing to red costs something, changing to green doesn’t. A red field means questions, a meeting and explaining yourself, so people change the colour only once they are sure things are bad, and for a few days before that they hope the team will catch up.

Why the hallway knows earlier

In the hallway, over coffee or in the team chat, information travels without a form. Someone says “I don’t like the look of that integration” long before they are able to justify it. A sentence like that has no field on the dashboard, so it never gets there.

The gap between the dashboard and the hallway is therefore neither a tool failure nor bad faith on the team’s part. It is built into the way information comes into being. First someone has a hunch, then a suspicion, then certainty, and only at the end the time to type it in. The dashboard gets the last stage, the hallway knows the first.

Buying a better tool won’t change that. The new dashboard will look nicer and will still show the last entry.

What you can do without replacing the tool

You don’t have to throw the dashboard away. It’s enough to stop treating it as a measurement and add a few habits that shorten the road from the hallway to the status.

Show the age of the status. Next to the colour, the date of the last change. A green from two weeks ago stops being reassuring and starts raising the question of whether anyone has looked there at all.

Add a field for the hunch. One short question for every workstream: “what worries you, even though you can’t prove it yet?”. The answer “nothing” is fine. The point is to give the worry somewhere to land before it becomes a delay.

Ask about confidence, not only about colour. “Green, low confidence” is completely different information from “green” alone. The PM who receives it knows where to look first.

Lower the price of red. If the first reaction to a red field is “what do you need?” instead of “why only now?”, people start changing the colour earlier. That depends more on the sponsor and the PM than on the team.

Walk the hallway once a week. Literally, or in the chat. Ten minutes of conversation with the two people doing the hardest part often tells you more than the whole dashboard. Whatever you hear there, write it down where the project keeps its tasks, because spoken agreements rarely survive a week.

This doesn’t remove the gap entirely, because there will always be a moment between the hunch and the entry. It does shorten it from weeks to days, and that is usually enough to react in time.

One question for this week

Open your dashboard and, for every green field, check when someone last changed it. If there is no way to check, you already know where to start.

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.