A garment manufacturer near Tiruppur, three units, around 600 people on the floor, a little over ₹110 crore. The daughter running operations had spent five months on a proposal. Vendors compared, references called, a phased plan, a cost she'd negotiated down twice. Her father listened to all of it and said the same sentence people in her position hear constantly: we tried this before and it didn't work.
She argued. That was the mistake, and it's the one almost everybody makes, because the sentence sounds like an objection about software and it isn't.
Why do software proposals fail in family businesses?
What that sentence is actually carrying
Three things, usually stacked.
There's the money, which was spent and produced nothing visible. There's the embarrassment, because somebody recommended it and somebody else signed it and neither has mentioned it since. And there's a quieter one: if the new system works, it makes the way things were done before look wrong, and the person who did them that way for thirty years is sitting at the table.
That last one is almost never said and it drives more resistance than the first two combined. A system that makes everything visible is, from where he's sitting, a system that audits his judgement.
Concede the history before you ask for anything
The version that worked in Tiruppur opened by agreeing. Yes, the last one failed. Here is specifically why: it went live across five modules at once, the supervisors were never asked, and by week three they'd gone back to the register while the software collected nothing. Nobody's fault in particular, and a predictable outcome of that sequence.
Naming the failure mechanism does two things. It shows you understand the business well enough to diagnose it, and it converts a vague fear into a specific risk that can be designed around. You can't mitigate a bad feeling. You can mitigate going live across five modules at once.
Ask for something small enough to be refused cheaply
The instinct is to ask for the whole thing, because the whole thing is what you believe in. Ask for one module, one unit, ninety days, with a named supervisor who has a veto. The scope is a tenth of what you wanted and it has one property the big ask doesn't: if it fails, it fails cheaply and visibly, which is precisely what makes a cautious person comfortable saying yes.
The supervisor veto is the part people leave out, and it's doing the most work. It answers the unspoken objection directly: this isn't an audit imposed from above, it's a tool the floor can reject. Handing that veto to a long-serving supervisor rather than to a young engineer matters more than anything in the proposal document.
"She stopped telling me the software was good. She told me why the last one failed, and she asked for three months on one line with Murugan able to stop it. I couldn't find a reason to say no to that."Garment manufacturer, Tiruppur
Give the old system a dignified exit
Whatever you're replacing, somebody built it and somebody defends it. The register, the spreadsheet, the way dispatch has always been checked. Saying it served the business well for fifteen years and has run out of room is both true and free, and it costs you nothing to say while it buys you a great deal of cooperation.
The opposite framing, where the old way is presented as a mess you're rescuing them from, is accurate often enough and wins nothing. You need those people in week five when the novelty has worn off and the new thing is still slower than the old habit. The failure modes that show up in that window are covered in the five ERP mistakes manufacturers make.
Once you have the yes, the numbers side of the case still has to hold up, and building the business case for a new ERP covers the four figures that carry it. Facto goes live one module at a time with our own engineers doing the deployment, which is what makes the ninety-day ask an ordinary request rather than a concession. If you want help shaping that first phase, talk to our team.
