I ask one question at a kickoff. Not what are we building. Who has to say yes, and by when.
The room goes quiet. Someone names a person who is not in the meeting. Someone else names a different person. Nobody names a date. We have just spent forty minutes agreeing a list of deliverables that everyone nodded at, and the first question about how that list gets decided empties the room.
That silence is the project. The deliverable list is not.
The argument
A scope document that lists what you will build is describing the output. Output is not what moves. Decisions move. So the document should list the decisions nobody has made yet, put one name against each, put a date on each, and state what the team does if the date passes. One page. Four sections. Not one deliverable in it.
That is the opposite of the standard advice. Every statement of work template, every work breakdown structure, every scope creep guide published this year tells you the same thing: describe the deliverables in more detail, write tighter acceptance criteria, and bolt a change control process on the side. I think that advice is aimed at the wrong failure.
The numbers say the failure moved
PMI published Pulse of the Profession on 22 May 2026. Ninety seven percent of project professionals managed at least one complex project in the prior year. Thirty one percent of those complex projects failed to achieve their originally intended scope of benefits, against 12 percent in the 2024 report. That is two and a half times in two years.
Now put that next to delivery performance, which barely moved at all. Arcidiacono’s 2025 update in the PM World Journal, published January 2026, compares two multi year datasets on IT project outcomes. The 2015 to 2017 window: 29 percent successful, 52 percent challenged, 19 percent failed. The 2020 to 2024 window: 31 percent successful, 50 percent challenged, 19 percent failed. Nine years, two points of movement, and the failure column did not move by a single point.
So delivery discipline is flat and benefit capture fell off a cliff. Whatever broke, it did not break in the part of the project that a deliverable list controls.
The PMI report says where it broke. Under value and alignment gaps, which hit 61 percent of complex projects, the largest single item is stakeholder decision delays at 34 percent. Budget overruns are 12 percent. Profit loss is 9 percent. Decision delay is bigger than both of those put together and then some. Every scope artefact on the market is built to police budget and deliverables. Almost none of them is built to police decision latency, which is the variable doing the damage.
There is a second number in the same report that I keep coming back to. Forty five percent of project professionals name multiple stakeholders across functions and geographies as a driver of complexity. Twenty seven percent of executives name the same thing. An eighteen point gap between the people who sign the scope document and the people who have to live inside it, on exactly the variable that produces decision delay. The document is written by the party that cannot see the constraint.
Speed is not the enemy of quality
The usual objection to all of this is that forcing decisions onto dates produces bad decisions. McKinsey surveyed more than 1,200 managers for its 2019 work on decision making. Respondents who reported that decisions were made fast were 1.98 times more likely to report that those decisions were high quality. Not a tradeoff. A correlation running the other way.
The same survey found 61 percent of managers saying at least half the time spent making decisions is ineffective, and only 34 percent saying their organisation made cross cutting decisions that were both good and timely. Cross cutting is the category every project sits in.
Read those two findings together and the change control process looks different. A change control board exists to slow a decision down so it can be examined. The evidence says slow decisions are not better decisions, they are just later ones, and the lateness is the thing killing benefit capture. The safeguard is the failure mode wearing a lanyard.
The one page
Four sections. It fits on a page because if it does not fit on a page nobody reads it in week six, which is the only week it matters.
One. The open decisions. Every decision not yet made that would change what gets built. One line each, written as a question with at least two real answers. Not “confirm the data model”. Instead: “do we write to the existing customer table or stand up a new one”. If it has only one answer, it is not a decision, it is a task, and it belongs somewhere else.
Two. One name. A person, not a function, not a committee, not “the steering group”. If two names appear, the decision is actually two decisions and you have not finished writing it. This section is where most kickoffs fall apart, because naming an owner in writing is a commitment and the room can feel it.
Three. The date and the default. The date the answer is needed, and the sentence describing what the team will build if that date passes without an answer. The default is the whole trick. It converts a blocked decision into a made one. It also removes the incentive to stall, because stalling now has a named consequence that the owner has already read.
Four. What is already out. The things explicitly not in scope, written as decisions that have been made, with the person who made them. This is the section that survives a change of sponsor, which is when every undocumented exclusion comes back.
There is a loop hiding inside the first section and it is the part that costs money. An unnamed decision does not stop the team. The team assumes an answer, builds on the assumption, and the assumption surfaces at a review where it is expensive to unwind. Then the same decision goes back into the queue, still unnamed. I have watched the same decision arrive at three consecutive steering meetings, get discussed each time, and get owned none of them.
Where this breaks
Four honest limits.
The change control evidence cuts against me. PMI’s own research says projects without formal change management are 35 percent more likely to exceed cost or miss deadlines. That is a real finding and I am arguing for less process at the point of change, not more. My position is narrower than it sounds: the change process is fine for changes, and useless for decisions that were never made in the first place. Those are different objects and most documents treat them as one.
The PMI decision delay figure is self reported by project professionals, who have an obvious interest in locating the blame one level above themselves. I read a survey of practitioners as evidence about executives. That is a weakness and I am not going to pretend otherwise.
The default mechanism assumes the team can actually proceed on a default. In regulated work, in anything touching patient data or client money, there are decisions where the only lawful default is stop. For those the section still helps, because it makes the stop visible and dated before it happens, but the mechanism is doing less work.
And the honest one about me. A one page document is easy to write and easy to like. It does not survive contact with a sponsor who will not put their name on anything, and there are organisations where the refusal to name an owner is the culture rather than an oversight. In those places this document does not fix the project. It just tells you early, in writing, that the project is not going to work, which is worth something but is not what I sold.
What I would do on Monday
Take the scope document for your largest running project. Count the deliverables. Then count the decisions that are named, dated and owned by one person. If the second number is zero, you have a wish list, not a scope.
Write the open decisions down as questions with two real answers each. Most teams find between six and twelve on a project of any size. Anything with one answer moves to the task list.
Put one name and one date against every line, out loud, in a meeting, with the names in the room. Do not accept a function. Do not accept two names.
Write the default for each. The sentence starts “if we have no answer by this date, we will build”. Circulate it. The objections you get back within a day are the real risk register.
Bring the page to every steering meeting and change only the dates. If a date moves twice, escalate the owner, not the decision.
The kickoff where I ask who has to say yes is still quiet. That has not changed. What changed is that I now write the silence down, put a date on it, and hand it back to the room before anyone has spent a dollar building anything.
I spend most of my week inside delivery organisations where the build is fine and the decisions are late. If you are about to sign a scope document that names forty deliverables and no owners, book a call first.