The meeting does not feel important at the time
When a software project fails, the post-mortem usually blames the estimate, the technology, or a person. In our experience the decision that killed it was made much earlier than any of those, in a meeting that felt routine. Somebody asked a question that did not have a comfortable answer. Somebody else gave a comfortable answer anyway. The meeting moved on, because meetings are graded on getting through the agenda, and the gap between the comfortable answer and the true one became the shape of the project.
This is not a communication problem and it does not get fixed by better note-taking. It is a structural one. Early meetings are full of people who are motivated to be agreeable: the vendor wants the work, the internal sponsor wants the project approved, the manager whose team owns the data wants to look capable, and the one person who knows the honest answer is usually two levels down and not invited. Everyone in the room is behaving reasonably. The output is still wrong.
What follows is what to listen for, what those sentences usually mean, and the small number of decisions that have to be closed in the room rather than deferred. None of it requires a methodology. It requires somebody to be willing to make one meeting uncomfortable.
You are probably here because
- The data you were told existed turned out to be a monthly export somebody builds by hand
- Month four is the first time anyone raised something that was knowable in week two
- Two people in your organization believe the project has two different goals, and both are right
- The build matches the spec and does not match how the work is actually done
All four trace back to a question that was asked once, answered softly, and never reopened.
Four sentences that mean a decision was skipped
“We can get you that data.” This is the single most expensive sentence in commercial software. It is almost never a lie and it is almost never true in the sense the vendor heard it. It usually means the data exists somewhere, someone knows how to produce a version of it, and nobody in the room has personally opened it in the last year. Between the sentence and a usable table sit five separate facts: whether it exists, whether it is complete, whether it is correct, whether you are permitted to use it for this purpose, and how long it takes to get a copy into an environment where an engineer can work on it. Each is a different person’s answer.
“Let’s park that and come back to it.” Sometimes the right call. But note who suggested it and what they were about to be asked. Parked items are not neutral; they accrue interest. A question deferred in week two is answered in week ten by whoever is writing the code that day, quietly, in the way that is most convenient for that afternoon. Nobody experiences that as a decision, which is exactly the problem.
“Whatever you think is best.” From a buyer this sounds like trust and functions as abdication. A vendor cannot know that the regional managers will refuse anything that adds a step to their Monday close, or that the finance director rejected the last three tools that could not export to a specific format. Delegating the decision does not remove your organization’s constraints; it just guarantees they are discovered late, by an engineer, in the form of rework.
“Let me check with Dana.” The useful information here is that Dana was not in the meeting and Dana can veto. Every project has a Dana — the security lead, the compliance officer, the operations manager whose team actually does the work. If a decision requires Dana and Dana is asynchronous, your project now runs at Dana’s response time, and Dana has a day job.
What the sentence usually means, and what to ask next
None of these are accusations. They are prompts. The correct follow-up is always narrower and more concrete than the original question, and it should be answerable by someone in the room or immediately assignable to someone who is not.
| What you hear | What it often means | Ask this instead |
|---|---|---|
| “We have that data” | A report exists that contains some of it | “Can we open the table on this call and count the rows?” |
| “It’s all in the system” | It is in three systems that disagree | “Which system is authoritative when they conflict, and who decided that?” |
| “That should be straightforward” | Nobody has looked at the integration yet | “Has anyone here written against that interface? What did it take?” |
| “The team will love this” | The team has not been asked | “Which two people can we watch do the job next week?” |
| “We’ll handle access” | A ticket will be filed at some point | “Who approves it, and what is the normal turnaround in days?” |
| “We just need something quick” | The real requirement has not been stated | “What happens on the first Monday after it ships?” |
The right people, which is not the same as the senior people
Attendance is usually decided by seniority and it should be decided by decision rights. Five roles have to be reachable during scoping, and only one of them is the sponsor.
The person who does the work today. Not their manager. The manager describes the process as designed; the practitioner knows the four exceptions that consume most of the day, and those exceptions are the software. If you invite only one extra person to one meeting, invite this one.
The person who owns the data. The one who can open the table, explain why there are two customer identifiers, and say which of the three date fields is the one people actually mean.
The person who can say no on security or compliance. Their veto is cheap in week one and catastrophic in week twelve. Bring them in early with a specific question, not a general briefing.
The person who signs acceptance. Whoever will eventually say “yes, this is done.” If nobody can name them, that is the finding, and it is worth stopping the meeting over.
The person who pays. Frequently in the room and frequently the only one, which produces a scope that reflects the budget rather than the work.
Cost of leaving each question unanswered — our ranking
Judgment from our own engagements, not a survey. The ordering is the useful part — note where the technology question sits.
The two decisions that cannot be deferred
Most early questions can wait a few weeks without harm. Two cannot, because everything downstream is shaped by them and reversing either one late means rebuilding rather than adjusting.
What the system decides, and what a person decides. A tool that recommends and a tool that acts are different products with different failure modes, different review requirements, different interfaces and different approval paths inside your company. Teams routinely leave this ambiguous because both answers sound fine in a meeting. Then the build assumes automation, the operations lead assumes review, and the disagreement surfaces at the demo. Write the sentence down: “the system will do X automatically; a person will approve Y before it takes effect.”
Who accepts the work. One named person, and the test they will apply. Not a committee, not a role. If the answer is “we’ll all look at it,” then acceptance will be decided by whoever is least happy on the day, and no vendor can build against that.
The vendor’s side of this, honestly
We are on the selling side of that meeting, and the incentive there is not neutral. A seller who presses hard on whether the data really exists, in front of the buyer’s boss, risks embarrassing the person who invited them. A seller who nods and writes an assumption into the proposal wins the work and gets paid to discover the truth later, often with a change order attached. That is not a hypothetical; it is the ordinary economics of the trade, and buyers should know it applies to everyone bidding, including us.
So use it as a test. The vendor who asks to open the table on the call, who asks who signs acceptance, who says “that assumption is doing a lot of work in this estimate” is spending their own political capital to reduce your risk. That behaviour is cheap to fake for one sentence and expensive to fake for an hour. Ask a question you already know the answer to and see whether you get the comfortable version.
How to run the meeting so it cannot go quietly wrong
The change is small. One page, six questions, and a rule that every answer gets a name and a date next to it. The agenda is not the deliverable; the list of what is still unknown is.
A ninety-minute scoping session that earns its place
Two mechanics make the difference. First, open the data live. Ten minutes of looking at a real table settles arguments that would otherwise run for a month, and the discomfort of finding it messy is worth about a hundred times what it costs. Second, read the open items back at the end while people are still in the room. An item read aloud with a name attached is one that someone will either accept or correct on the spot; the same item in a follow-up email is a document nobody opens.
If the meeting already happened
Usually it has, and you are reading this because something is off. The recovery is cheap if you do it now and expensive in a month.
Take the current plan and mark every load-bearing assumption — the sentences that, if false, change the schedule. There are rarely more than five. For each, write the specific check that would settle it and the person who can perform it. Then do the checks this week, before the next increment of build. This takes a competent pair of people two or three days and it is the highest-return work available on a young project.
Expect one of them to be wrong. That is not a sign the project is bad; it is the ordinary hit rate, and the difference between finding it in week three and finding it in week twelve is most of the budget. A vendor who resists this exercise is telling you something. A vendor who runs it themselves and brings you the bad news early is worth keeping.
The mistakes we are called in to fix
- An assumption about data promoted to a fact because it appeared in a slide three times
- No named acceptor, so “done” is decided by whoever is unhappiest at the demo
- The practitioner never interviewed, so the exceptions that are the actual job were never modelled
- Security consulted at the end, after the architecture assumed access it will not get
- Automate-or-advise left ambiguous, discovered at the first review with the operations lead
- Open items recorded without an owner, which is the same as not recording them
- A vendor rewarded for agreeableness during selection, and it worked exactly as designed
Before you leave the room
- Somebody opened the real data on screen and stated the row count out loud
- One named person will sign acceptance, and the test is written down
- The automation line is a sentence, not an implication
- Every veto holder outside the room has a question and a date
- Somebody who does the job today has described it, in their own words
- Access has an approver, a request date and an expected turnaround in days
- Open items were read back aloud with names attached
- At least one uncomfortable answer was given, and nobody was punished for it
Bottom line
Projects are not usually lost to hard technical problems. They are lost to easy questions that received polite answers early, in rooms where everyone was being reasonable. The counter-measure is not more governance, and adding a steering committee will make it worse. It is one meeting, run with the practitioner present, the real data on screen, and the discipline to leave with names and dates on the things nobody could answer. That meeting is unpleasant for about twenty minutes and it is usually worth more than the next two months of work.
Frequently asked questions
Whichever one first requires a real answer about your data, your process or your approvals. Sometimes it is the second sales call, sometimes it is the kickoff, sometimes it is a hallway conversation that never had an agenda. It is identifiable by feel: a question lands, the room gets slightly quieter, and then somebody rescues it with a general answer. That is the moment.
A good vendor will run it and you should still hold your own copy of the open items. Their list is optimised for what they need to start work; yours should include the questions that determine whether the project should proceed at all. When the two lists differ, the difference is the conversation worth having.
You do not need them all at once. The practitioner and the data owner belong in the same ninety minutes, because most of the value comes from those two disagreeing in front of you. Security and the acceptor can be handled with a specific written question each. What does not work is doing none of it and buying the schedule anyway.
A cautious vendor names the specific assumption, tells you what would settle it, and offers to do that check cheaply and early. A padding vendor raises unnamed risk in general terms and prices it. Ask what evidence would let them lower the number. If there is no answer, the caution was not about your project.
Then you found that out for the cost of a meeting instead of the cost of a build, which is the best outcome available on that day. Not every project should proceed, and the ones that should will survive an accurate description. A scope that only holds together while nobody checks the data is not an opportunity.