“And what happens if the supplier is a month late?” The question comes up at the steering committee, from a director who is seeing the plan for the first time. The PM starts answering and halfway through the sentence realises there is no answer. For the next ten minutes the room watches a plan the team worked on for three weeks lose its credibility over a single question.
The question was a good one. The trouble is that it came in the worst possible place: in front of the people who decide about the budget, and at a moment when nothing can be calmly checked any more.
Someone friendly could have asked the same question a week earlier. All it took was asking them to.
What red-teaming your own plan means
The idea is simple. Before the plan reaches the people who will judge it, you give it to one or two people with a single job: for twenty minutes they look for holes in it. They don’t fix it and they don’t advise. They attack.
What makes it different from an ordinary review is the stance. In a review people look for confirmation that the plan is good and keep small doubts to themselves so as not to drag things out. Here the role is reversed and explicit. The attacker has permission, even a duty, to say uncomfortable things.
It is also different from a premortem. There the whole team imagines the project has failed and looks for the causes. Here one person goes after the plan itself, line by line.
Who to ask
Ideally someone from outside the project. Team members know the plan too well and share its assumptions, so they no longer see what has become obvious to everyone on the inside.
A manager of another project works well, as does someone from operations or from the department that will use the result. They don’t need to know the technical details. It is enough that they know how the company works and have no stake in the plan looking good.
Send the plan a day ahead. An attack done cold ends up at typos and formatting.
Three angles of attack
Twenty minutes is not much, so it helps to split them into three parts.
Assumptions. What has to be true for this plan to succeed? The supplier will deliver on time, the client will reply within a week, the requirements won’t change. For each assumption, one question: how do we know?
Dependencies. Who outside the team has to provide, sign or grant something? Does that person know about it, and is it in their calendar?
People. Who is down in this plan for more than they realistically have time for? Who is the only person able to do a given thing, and what happens when they are off sick?
The hardest rule: don’t defend
During the attack the author of the plan takes notes and asks follow-up questions. They don’t explain, they don’t correct, and they don’t say “we’ve already thought about that”.
In my experience this is the hardest part of the whole exercise. The reflex to defend your own work is strong, and every explanation takes time and teaches the attacker that their remarks meet resistance. After the third defence they stop speaking plainly.
If a remark comes from a misunderstanding, that is information too. If a friendly reader misread the plan, the steering committee will misread it the same way.
What to do with the list afterwards
Twenty minutes usually produce somewhere between eight and fifteen remarks. Not all of them call for a change to the plan. Each gets one of three labels.
I fix it. The hole is real and can be closed in the plan: add a buffer, change the order, add a person.
I accept it knowingly. The risk exists, but protecting against it would cost more than the risk itself. I write it down and I know what I will say when someone asks.
I ask the sponsor. The decision isn’t mine. I take it to the sponsor before the meeting, not during it.
The third label is the most valuable. A question the PM has no answer to sounds completely different when the PM puts it to the sponsor in private than when it comes from the room.
One question for this week
Take a plan you are due to present in the coming weeks. Who in your company could spend twenty minutes looking for holes in it, and what would it cost you to ask them?
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.
