For my first years of running projects, I sent sponsors lists. What’s done, what’s in progress, what’s running late. Carefully, every week, color-coded, and every week I got the same reply: “thanks, got it.” Nothing more, or no reply at all.
For a long time I took that as a good sign. Only when one sponsor stopped me in the hallway to ask whether the project had any problems, while those problems had been described in the last three reports, did I understand that he wasn’t reading my reports as information to act on. He was reading them as proof that someone had the project under control. Or he wasn’t reading those emails at all.
Let me save you those years. A sponsor doesn’t need to know what you’re doing. A sponsor needs to know what you need from them.
Why a list of delays leads to no decision
A list of delays is honest, but it leaves all the work to the reader. The sponsor sees “integration pushed back two weeks” and has to answer three questions on their own: is that a lot, what follows from it, and do I need to do something about it. Usually there’s no time to think it through, so they respond with the simplest thing available: nothing. And a decision that never gets made has its own cost.
From my side, it looked like I had raised the problem. From their side, it looked like the problem was under control, because if it weren’t, the PM would have written more. And you know what? We were both right, each in our own head.
Four parts, in this order
For years now, every message to a sponsor where something is moving has followed the same layout.
Status. One or two sentences about what happened. No backstory, no excuses. “The vendor moved the test environment handover from mid-month to the end of the month.”
Consequence. What this means for the things the sponsor cares about: deadline, budget, scope, people. Not for the schedule in the tool, but for their world. “If we do nothing, go-live slips by two weeks, which puts it after the date you promised the board.”
Options. Two or three real paths, each with its price. Not one option dressed up as a choice, and not seven, because seven is handing the decision straight back. “We can start testing on substitute data and run integration tests later, which costs two extra days of team time. We can move the deadline. We can cut the reporting module from the first release.”
Recommendation. Which option I would pick and why, in one sentence. “I recommend the first, because it protects the deadline, and the integration testing risk with this vendor is low.”
That’s it. It usually fits in eight to ten sentences.
The recommendation is the most important part, and the one most often skipped
In conversations with other PMs, this last point meets the most resistance. I hear: “it’s not my decision,” “I don’t want to stick my neck out,” “the sponsor knows better.”
The sponsor will indeed make the decision. But you are the person who knows the project best, and if you don’t say what you would do, the sponsor decides on less knowledge than yours. A recommendation doesn’t take their authority away. It gives them a starting point they can accept with one word or reject with a reason.
There’s also a less noble reason, but a true one: a sponsor who gets a recommendation replies faster. With a list of delays, I’d wait several days for an answer. With the four parts, I often get it the same day, because the answer is “ok, the first one.”
What this structure doesn’t tolerate
It doesn’t tolerate beating around the bush. If in the “status” part you start explaining who’s to blame, the sponsor stops reading halfway and remembers the culprit, not the problem.
It doesn’t tolerate fake options either. I once sent a sponsor three options, two of which were so weak the choice was obvious. The reply was short: “if you already know what needs to be done, why are you asking me?” Fair point. If there’s only one sensible path, say so directly: status, consequence, what I’m doing, and by when you can stop it.
And it doesn’t tolerate mixing several topics in one message. Three problems means three short blocks of four parts each, not one long paragraph where the sponsor has to match the options to the problems themselves.
A small test for your next update
Before you send your next message to a sponsor, read it and answer one question: what decision can they make after reading it? If the answer is “none,” it isn’t a sponsor update. It’s a project diary you happen to be emailing them.
A diary has its place too, but let it sit somewhere the sponsor can look when they want to. Their inbox should get what requires them to move.
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.
