Two teams in your organization have never agreed on what "approved" means.
One of them means legal signed off. The other means the budget holder said yes in a meeting. Nobody has written it down. Honestly, nobody has noticed they disagree, because they have never had to be precise about it at the same moment.
This is fine, in the way that a lot of things are fine. The ambiguity has been absorbed for years by people using judgment.
Then you build a system.
A system needs a field
And a field needs a definition. So somebody picks one.
Usually a developer. Usually on a Tuesday, under deadline, working from a requirements document that says "capture approval status." Maybe they choose a checkbox. Maybe a status field with four options, because four felt right.
That person just made an organizational policy decision.
They didn't know they were doing it. Nobody asked them to. There was no meeting, no sign-off, no line item. But it is now in production, and it is now how your company defines approval.
This is what I mean when I say technology does not eliminate unresolved operating decisions. It turns them into system behavior.
Why this is worse than leaving it unresolved
Before the build, the ambiguity was cheap. Two teams meant different things, and when it mattered somebody asked.
After the build, the ambiguity is encoded. It has a field name, a data type, a set of permitted values, and reports depending on it. Changing it is no longer a conversation. It is a change request, a regression risk, and a queue.
The decision got harder to make by being avoided. That's the part people don't see coming.
And you usually find out about four months later, in a meeting about reporting, when two people pull numbers that don't match and neither can explain why.
The build is the receipt
Every implementation is a record of the decisions your organization made, including the ones it didn't know it was making.
If the operating decisions were settled beforehand, the build reflects them. If they weren't, the build shows you exactly which ones you skipped. It's an itemized list, arriving late, written in configuration.
Which is why "our last implementation didn't work" is so rarely a technology problem. Ask what happened and you will usually find that nobody decided. Not that they decided badly. That the decision was never located in a person.
"That's not a decision. That's an opinion."
Here is the pattern that produces this.
You're in a requirements session. Somebody says, "I think it should work like this." Somebody else says, "well, we've always done it the other way." Everyone nods. It goes in the notes. The meeting ends and everybody leaves feeling like something was settled.
Nothing was settled.
So the question I end up asking, and it does not make me popular: that's not a decision, that's an opinion. Who's going to decide?
It's uncomfortable because it is usually the first time anyone has asked out loud, and the answer is frequently that nobody knows. Which means you have just found the actual problem, ten minutes into a conversation, rather than four months into a build.
You have to be willing to be the less fun person for those ten minutes.
What to do instead
Write the names down. Not the departments — a department has never made a decision. Names.
For each contested definition in the process you're about to automate: who decides, who is consulted, who gets told afterward. When two functions want different things, who breaks the tie, and by when.
That's twenty minutes of work. It prevents the six-month argument, and more importantly it prevents a developer from having to guess on a Tuesday.
And if you can't settle it, record that you couldn't. "Unresolved" is a real answer, and an honest one. It's a blank that someone can come back to. What you cannot afford is a blank that a build silently fills in.
The narrower point
Most of what gets called an implementation problem is a decision problem that arrived late.
The platform didn't fail. The requirements didn't fail. Somebody had to choose what a word meant in order to make a field, and the organization had never chosen, so the choice happened at the lowest level and the least visible moment available.
Decide first. Build second. Not because it's tidier, but because the alternative is that every decision you skip still gets made — by the build, by default, and by whoever is closest to the keyboard when the question comes up.