Over the years, I have watched many businesses get burned by software outsourcing — projects that were declared dead on arrival the moment they were handed over, even when the vendor delivered on time and ticked every feature box. On paper, the acceptance documents looked spotless: green checklists, functionality matching the spec, screens matching the Figma. The client cut the ribbon with a smile. The vendor cashed the cheque with one too.
Then the tragedy begins the moment the system goes into real operation. Problems that had been baked in from day one start surfacing and causing serious damage to the business. Let us pull apart the knots behind this breakdown through the lens of psychology and economics.
During British colonial rule in India, the government was struggling with a cobra problem. The number of people bitten was rising every year. Snakes were turning up everywhere, inside homes, on the streets, in the markets. Someone in the administration came up with a solution that seemed perfectly logical: offer a cash bounty for every cobra killed. Hand in a dead snake, collect the money. Simple, effective, with clear KPIs.
And at first, it actually worked. People rushed out to hunt snakes. The number of dead snakes handed in shot up. Officials reported good progress. Everything seemed to be going in the right direction.
Now put yourself in that situation and think: why would you go out and catch wild snakes, risky and exhausting work, when you could just breed them at home? That is exactly what people started doing. They set up cobra farms. Dozens of snakes. Then hundreds. Then thousands. Breed the snakes, wait for them to multiply, kill them, hand them in, collect the money — a perfect loop. The number of dead snakes kept climbing and the officials felt increasingly confident that their policy was the right call.
Then the government figured out what was happening and immediately cancelled the programme. And that is when everything truly fell apart. Thousands of cobras being farmed across the city were now completely worthless. The farmers did the only rational thing available to them: they released every single one. The cobra population in the streets ended up higher than it had been before the programme ever existed. The solution had created the exact problem it was designed to solve.
The Nature of the Cobra Effect in Business Management
Economists call this the Cobra Effect, a term coined by German economist Horst Siebert to describe a phenomenon that has appeared repeatedly throughout history: when a system is designed to measure and reward one thing, the people inside that system will optimise for what is being measured, not the real goal behind it. Not because people are dishonest. But because it is basic human psychology to always find the most efficient path to the stated target. The British colonial administration wanted fewer snakes. The people wanted to make money. Two different goals, two different definitions of optimal, and the two ended up working directly against each other.
If this story sounds familiar, that is because it should. It plays out constantly, in every corner of life and work. The software and digital transformation industry is no exception. There are just no snakes, no farms, and nobody has given it a name.
Case Study — Lidl: €500 Million Lost by Holding Onto Old Processes
In 2011, Lidl, the largest discount supermarket chain in Europe with over 10,000 stores across 30 countries, decided to undertake what it called the biggest transformation in the company’s history. The goal was to replace its ageing in-house warehouse management system with SAP, standardising operations across more than 140 logistics centres and thousands of stores worldwide. The initial budget was €201 million and the timeline was a few years, which seemed entirely reasonable for an organisation of Lidl’s scale.
In 2015, they went live with a pilot in Austria and things seemed stable enough to continue, but there was a problem that nobody had seen clearly or been willing to say out loud from the very beginning: Lidl had always managed its inventory based on purchase price, while SAP was built to manage inventory based on retail price. That might sound like a minor technical detail, but it was the core logic of the entire stock management system, the foundation on which every other business process was built. Rather than adapting their own processes to fit SAP, Lidl decided to customise SAP to fit their existing processes.
From that decision, everything began to pile up in ways nobody could control. The harder they pushed to bend SAP toward the old way of working, the more complex and unstable the system became. Customisations stacked on top of each other and broke the integrity of the platform. Technical debt accumulated until the system was nearly impossible to scale. The €201 million budget had long been exceeded but nobody felt safe saying what the real number was. A timeline of a few years stretched into seven, while staff were expected to keep the old system running while simultaneously dealing with the problems of the new one, and morale eroded steadily throughout. There was no meaningful internal oversight, nobody who truly understood the system end to end, and no real knowledge transfer happening anywhere in the process.
In 2018, after seven years and €500 million, CEO Jesper Hoyer sent a memo to all staff: “The strategic goals as originally defined cannot be achieved without spending considerably more than we are prepared to.” They shut the whole thing down and returned to the old system, the same in-house system they had spent seven years and half a billion euros trying to replace, while the CIO left the company and the entire strategy was reversed.
This is not a story about SAP being bad or Lidl being incompetent. It is the Cobra Effect in software running exactly as its mechanism dictates: every party involved — Lidl wanting to preserve their existing processes, SAP wanting to deliver against the contract, the consultants wanting to bill more hours — was doing precisely what they were being measured and rewarded for, while not one of them was asking the only question that actually mattered: “After all of this, can the warehouse staff actually do their jobs?”
Why Acceptance Criteria Cause So Many Software and Digital Transformation Projects to Fail
Whenever human beings design a measurement system, the people inside it will optimise for the metric being measured rather than the real goal behind that metric. Goodhart’s Law, articulated by British economist Charles Goodhart in the 1970s, states this plainly: “When a measure becomes a target, it ceases to be a good measure.”
In software projects, the metrics are features delivered, deadlines met, and QA passed. Nobody measures whether employees can actually use the thing. Nobody measures whether the business problem has been solved. The Standish Group spent 30 years tracking more than 50,000 software projects globally and the results are unambiguous: only 29% of projects truly succeed, 52% run into serious problems, and 19% fail completely. In Vietnam the picture is even worse, with 76% of digital transformation projects ending in failure. Not because Vietnamese businesses are less capable. But because the Cobra Effect does not discriminate by geography — it follows the structure of the problem wherever that structure exists.
Decoding the Structural Breakdown in Software Outsourcing
Every software project follows a familiar flow. It looks clear and logical on the surface, with each step having a responsible owner and a concrete deliverable.
The problem is not in any individual step. It is in what happens between the steps, as information moves from one person to the next and a little more context is lost with every handoff, never to be recovered.
The Misalignment Between the Problem Owner and the Builders
The client describes the problem in their own language. The BA hears it and interprets it through the BA’s understanding. Design reads the spec and understands it through a designer’s lens. Dev looks at the Figma and implements it through a developer’s logic. With each handoff, part of the original context disappears without anyone noticing, because nobody in the chain has enough shared context to even know what they are losing.
Lidl had a fully featured SAP system. The warehouse staff had their own operational processes refined over many years. Those two things were never placed on the table together during the build, not until €500 million had already been spent.
When Every Link in the Chain Optimises for a Different Goal
This is the Cobra Effect operating inside a software project. Nobody is deliberately breeding snakes, but the structure of the system naturally leads every person to optimise for what is being measured rather than what actually needs to be achieved. The table below makes it clear why a project can succeed by every individual’s definition within the chain while still failing completely by the definition of the person who paid for it.
Nobody is being irresponsible. They are doing exactly what the contract asks of them. The problem is that the contract is not asking for the right things.
The Contract — Where the Metric Trap Gets Legalised
When you sign a contract with a dev company, what you are actually signing is a document that describes features, timelines, and acceptance conditions — not business outcomes. The vendor has no contractual obligation tied to whether your staff can actually use the software. They only need to deliver the agreed features, hit the deadline, and pass acceptance testing, at which point the contract ends. This is exactly when the Cobra Effect operates at its most efficient, because the metrics being measured are features and deadlines and so the vendor optimises precisely for those two things, producing a product that succeeds on paper and fails in practice. The Standish Group identifies three factors that most determine whether a software project succeeds: real user involvement, direct leadership support, and clearly defined requirements from the start — and none of those three things typically appear in a standard contract.
The Paradox: The Person With the Most Information Is the One Left Out
Once the contract is signed it is easy to feel like your part is done and the rest belongs to the experts. But the dev team understands the technology, not your business. They do not understand your actual processes, they do not know who your end users are or what problems those users face every day — and only you have that knowledge. The person with the most information needed to make the project succeed is consistently the person least involved in building it. That is the central paradox of almost every software project, and it is precisely how Lidl managed to lose €500 million while the dev team remained technically blameless because by the terms of the contract they had done everything right.
Hard-Won Lessons for Protecting Yourself When Outsourcing
Not by finding a better dev company, not by increasing the budget, and not by writing a longer spec. Two things need to change, in this order.
First, change how the contract is written — because the definition of success needs to be in the contract not as a list of features but as a measurable outcome. Something like “80% of staff are proficient with the system within 30 days of go-live” rather than “the system includes features A, B, and C.” When the metric changes, the behaviour of everyone in the chain changes with it, and that is how you break the Cobra Effect at its root.
Second, change who is in the room from the beginning — because real users need to be part of the build process and not just present at the kickoff and the handover, and the feedback loop from real users needs to be a built-in part of the process rather than a bonus if time allows.
The British colonial administration in India did not fail because of a lack of money or willpower — they failed because they were measuring the wrong thing and the entire system optimised around that wrong metric. Lidl did not fail because SAP was bad or because they were incompetent — they failed because nobody in seven years was willing to ask directly “can the warehouse staff actually do their jobs with this system?” And 76% of digital transformation projects in Vietnam do not fail because of a lack of technology — they fail because the Cobra Effect is running quietly inside every contract, every meeting, and every handoff, and nobody has given it a name.
Software does not fail at the build stage. It fails before the build begins, when nobody is asking the right questions and nobody is measuring the right things.
Thank you for taking the time to sit with me through this whole story. Everything I have shared above comes entirely from real experience built up over years in this field, but every business is different — each one carries its own unique digital transformation or experience design challenge.
What is your take on this? What have you seen in your own work? Do not hesitate to leave a comment below — let us sit down together and learn from each other.
Leave a Reply