Most software fails before anyone writes a line of code
The expensive failures are decided in the weeks before implementation starts — in what was assumed, what was never asked, and what everyone agreed to without meaning the same thing.
By the time a project is visibly in trouble, the decision that doomed it is usually months old. The code is rarely the problem. The problem is that the system was asked to do something nobody had stated precisely, for a business process nobody had mapped, under constraints nobody had written down.
This is why I keep ending up in the same kind of room: aging systems nobody fully understands, rewrites that stalled halfway, organisations caught between what the business wants and what engineering can deliver. These look like engineering failures from the inside. They almost never are.
Where it actually goes wrong
A rewrite stalls halfway because the original system’s behaviour was never documented, only observed — so every attempt to replace it discovers new obligations it was secretly meeting. A delivery misses because “the business wants X” turned out to describe four different Xs held by four people who had never been in the same meeting. An integration overruns because the data model of the thing being integrated with was taken on trust.
None of these are fixed by better programmers. They are fixed earlier, by insisting that the question be made precise before the answer gets expensive.
What follows from it
Understand the business first. Map the process as it actually runs, not as the org chart implies. Write down what the system must be true of, before arguing about how to build it.
This is slower at the start and faster everywhere after. It is also the part most readily skipped, because at the moment it matters there is nothing to demonstrate — no running code, no screen to show. The cost of skipping it arrives much later, and by then it looks like an engineering problem.