A stalled technology project almost never stalls because of a bug. It stalls because it reached a point that needs a decision nobody made at the start, and now every option costs money.
The first is data ownership. When every department has its own version of the same customer, someone has to decide which version is authoritative. If that isn't settled in discovery, it will be settled in month six — after three screens have already been built on the wrong assumption.
The second is defining success. An organization that hasn't defined what counts as a closed deal or a handled enquiry will find the system showing numbers nobody agrees on. At that point you can no longer talk about improvement, because there's no baseline to compare against.
The third is who's responsible after go-live. A project without an internal owner ends up where the vendor is done, the team hasn't adopted the system, and there's nobody to decide on the small change that would have made it usable.
What all three have in common is that none of them is a technical question. They're all organizational questions that can be settled in the first week, in one meeting with the right people in the room. That's exactly what a good discovery document does: it doesn't describe a system, it forces decisions.
The bottom line
If you can answer these three questions before you start building, most of the project's risk is already behind you.