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, and buys. Then it spends the next year reshaping itself to fit what it bought — renaming its own stages to match the vendor’s stages, abandoning steps the tool has no field for, and inventing a spreadsheet on the side for everything that falls through. Eighteen months later the verdict is that the platform did not work. The platform worked exactly as designed. It was just designed around a business that was not this one.
I know this failure from both ends. I have implemented systems for other people, and before that I ran a CNC manufacturing company and an advertising agency, and I was the one whose actual operation had to bend. When you have been the client in that arrangement you stop finding it abstract.
So I invert the order. Before anything gets configured, I want to know how the work actually moves. Not the org chart. Not the process document written for a certification audit three years ago. The real thing: who touches this, what do they do when the customer changes their mind at the last minute, where does the job sit while it waits, and what is 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 is not a defect in the client. It is the requirement nobody wrote down.
Only after that do I open the tooling — and by then the tooling is a means, not 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 in custom middleware rather than getting forced into a field that was named for something else.
The order matters more than any individual choice. Map first, then choose, then bend. Reverse it and every later decision inherits an assumption you never agreed to.
There is one measure I trust for whether this worked, and it is not 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 have not 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 was not 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 do not need me. A system whose survival depends on its implementer being reachable is not a system — it is a dependency wearing a system’s clothes, and the invoice for that arrives later, always, and never to the person who signed for it.