The failure that looks exactly like being helpful.
There's a specific kind of stuck that shows up in requirements sessions, and I used to handle it badly.
Two people disagree about a business rule. Not leadership versus the floor, which is a different problem with a different fix. Two peers who each own a piece of the same policy and see it differently. The operations lead thinks a project should be locked once it's awarded. The finance lead needs to be able to adjust it after the fact. Both are right about their own side of it. Neither one outranks the other.
The room goes quiet and looks at you.
Resolve it. Take the input from both sides, weigh it, propose something that splits the difference, and move on. It feels good. It's efficient. You're the consultant, you've seen this before, and you have an informed opinion.
It works for about six weeks.
Then it comes back, usually in UAT, usually as a bug that isn't a bug. Somebody looks at the system and says this isn't how we do it, and they're right. You go back through the notes and find the decision was made in a session, by you, on a hunch nobody signed off on. Now you're unwinding a build and having a harder version of the original conversation, except this time there's a deadline and someone has already told their boss it was done.
The system now runs on a rule the business never agreed to. That's the failure, and while it's happening it looks exactly like being helpful.
The better move is boring. Lay out the tradeoffs, say who owns the call, write it down as open with that person's name on it, and keep going.
Not "we'll circle back." A named owner, a specific question, and a date the answer is needed by. Then continue with the parts of the design that don't depend on it, and be explicit about which parts do.
Three things that make this work:
State the tradeoff without picking a side. Locking the record keeps the data clean and means every correction becomes a request. Leaving it open keeps finance moving and means the awarded number can drift. Both of those are real problems. Saying them out loud in front of both people is most of the value, because usually neither one has heard the other's version stated plainly.
Name the owner, not the committee. "The business will decide" means nobody will. If nobody in the room can say who owns it, that's the actual finding, and it's worth surfacing to whoever sponsored the project.
Put it somewhere they'll see it. An open decision buried in your notes is the same as no decision. It needs to sit where the client runs into it over and over, so the cost of not answering lands on them instead of on you.
The instinct to resolve is not laziness. It comes from a good place: the room is stuck, you're being paid to unstick it, and everyone will be relieved.
There's also a pressure nobody says out loud. An open decision makes the project look less finished. It puts a question mark in the status report. A consultant who settles things looks decisive, and one who keeps raising open questions can look like he isn't getting anywhere, especially to somebody reading a summary from a distance.
I'd rather look slower in week three than be wrong in month five.
But it took a few month-fives to get there.
There's a distinction worth being careful about, because this can turn into an excuse for not having opinions.
Technical decisions are yours. Formula field or flow, how the data model handles a many-to-many, whether the validation sits on the record or in the automation. Nobody in the room knows this better than you, and handing those to the business isn't humility, it's ducking the job.
Business rules are not yours. What the policy should be, who gets to override what, which number wins. You can advise, you can spell out what each option costs, and you should push hard when a choice is going to hurt. But the answer isn't yours to give.
The mistake is mixing them up, in either direction. Settle business rules yourself and you get a system nobody agreed to. Hand off the technical calls and you get a system designed by committee, which is worse.
The best version I've been part of ended with a decision log the client actually read. Six or seven open items, each with a name and a date. Some got answered in a week. Two went up a level, because it turned out neither person actually had the call and somebody above them had to make it. One sat there long enough that the business decided it didn't matter after all, which is a fine outcome and one you'd never get to by guessing.
None of that made the project look tidy. All of it made the build correct.
The systems that get abandoned usually aren't the buggy ones. They're the ones running a version of the business that the business doesn't recognize. A lot of those start in a room where somebody helpfully broke a tie.