The most common way I see a software project fail has nothing to do with the software.
A company decides it needs a system. It evaluates platforms, watches demos, compares feature matrices, buys. Then it spends the next year reshaping itself to fit what it bought — renaming its own stages to match the vendor’s stages, dropping steps the tool has no field for, inventing a spreadsheet on the side for everything that falls through the gaps. Eighteen months later the verdict is that the platform didn’t work.
The platform worked exactly as designed. It was just designed around a business that wasn’t this one.
I know this failure from both ends. I’ve implemented systems for other people, and before that I ran a CNC manufacturing company and an advertising agency, where I was the one whose operation had to bend. Once you’ve been the client in that arrangement it stops being abstract.
So I invert the order. Before anything gets configured I want to know how the work actually moves. Not the org chart, and not the process document somebody wrote for a certification audit three years ago. The real thing. Who touches this, what happens when the customer changes their mind at the last minute, where does the job sit while it waits, and what’s the WhatsApp message that unblocks it.
That last one is the important question. Every business has a step that runs on a phone call or a message because no system ever gave it a home. That step isn’t a defect in the client — it’s the requirement nobody wrote down.
Only after that do I open the tooling, and by then the tooling is a means rather than the subject. In Zoho terms this usually means a Blueprint that encodes the transitions the business genuinely enforces, and only those. If a stage has no gate in real life, it gets no gate in the Blueprint. Manufacturing a rule to satisfy the diagram is how you teach people to lie to the system on day one.
Deluge covers the space between what the platform assumes and what this company does — the approval that depends on a margin threshold nobody else calculates that way, the document that has to exist before a specific person can proceed. When something genuinely lives outside the platform, it goes into custom middleware instead of getting forced into a field that was named for something else.
The order matters more than any individual choice here. Map first, then choose, then bend. Reverse it and every later decision inherits an assumption you never agreed to.
There’s one measure I trust for whether this worked, and it isn’t go-live. Go-live proves nothing — anything runs while the person who built it is watching. The measure is what the system looks like six months later, when I haven’t been in the room. Is the team still using it the way it was designed, or have they quietly grown a parallel spreadsheet again? Can they add a stage themselves when the business changes, without calling me? Did somebody who wasn’t part of the project make a change and have it hold?
Success is that the client’s team runs it without me. Not that they need me less — that they don’t need me. A system whose survival depends on its implementer being reachable isn’t really a system. It’s a dependency, and the invoice for it arrives later, always, and never to the person who signed for it.