The project a $200 barcode printer killed — a case study

The project was a furniture factory. Moderate size, one location, a straightforward manufacturing and stock requirement. On paper it was among the easier deliveries of that year.

It failed, and the stated reason was a barcode printer that cost less than two hundred dollars to replace.

That was not the reason. It was the excuse the real reasons hid behind.

Failure one: “everything is fine” at contracting

The requirements gathering was smooth. Every question about existing process returned the same answer: yes, we do that, it works well, no problems there.

A client who reports no problems has either an unusually well-run company or an unusually thin understanding of their own operation. The second is far more common, and it is detectable: ask the same question of the person who does the work rather than the person who owns the company, and the answers diverge.

We did not ask twice. The requirements document recorded a factory that did not exist, and every estimate in the plan was built on it.

Failure two: management by affection

The staffing requirement was stated plainly and in writing: five people from the client side, dedicated, for the duration.

The owner assigned one. A shop-floor employee who was already asking to be relieved of some of his existing work, and who was now also the data owner, the tester, the trainer and the escalation point for a system he had never seen.

He did not refuse, because he could not. He was not chosen for capacity. He was chosen because the owner liked him — and the same affection that put him there made it impossible for anyone to report that he was drowning.

A resourcing plan that names a role and not a person is not a plan. A plan that names a person without removing something else from their week is a wish.

Failure three: a system larger than its owner

Midway through, the pattern became clear. The requirement list described a company with regional distribution, multi-warehouse allocation and full traceability. The budget described a company that was arguing over a printer.

The mismatch is not a budgeting error; it is an identity problem. The owner wanted the system a much larger company would run, at a price a much smaller one would pay, staffed by nobody.

This is diagnosable early and almost never diagnosed, because naming it in a sales meeting sounds like an insult. The neutral version is a question: which three of these thirty requirements would you go live without? A client who cannot drop any of them has not budgeted, they have wished.

The printer

Go-live approached. The label printing step needed a device that could take the new label format. The existing printer was old enough that no current driver supported it.

Replacing it would have cost roughly two hundred dollars. The owner refused, and refused again, and then made the refusal the grounds for declaring the system unfit and demanding his money back.

Nobody spends six figures on software and then loses it over two hundred dollars, unless the two hundred dollars was never the issue. It was the first defensible-sounding reason to stop paying for a project that had gone wrong for reasons he did not want to name.

Three things worth taking from it

To the consultant. A contract that does not list the supported hardware and does not carry a written job description for each named client-side resource is not a contract, it is a rope. Both omissions were ours, and both were the kind of detail that feels pedantic in week one and decides the outcome in month six.

To the owner. Saving money on tools and on people is not saving. It is the same economy as thinning the cement — the building goes up, it goes up cheaper, and the failure arrives later and costs more than everything that was saved.

To everybody. Digital transformation is a decision about how a company will be run, taken before any software is bought. A company that is not willing to change how it works has not bought a system. It has bought an expensive record of the way it already works.

The general shape of these failures — and the seven that recur most — is in why ERP implementations fail. What a consultant is actually for is in this article, and if you are evaluating a vendor now, how to run a demo so it tells you something is the place to start.