Why Most Software Projects Fail Like a Tarantino Heist

What an old PhD thesis can teach product managers about systems thinking, requirements discovery and building the right thing

“You know what they call a Quarter Pounder with Cheese in Paris?” — Jules Winnfield, Pulp Fiction

It is an odd question, but it is also a surprisingly good metaphor for product management. Most software projects begin by discussing the Quarter Pounder: the technology, the architecture, the integrations, the UI and the database. Far fewer begin by asking whether anyone actually wants a burger in the first place.

Nearly twenty years ago, Judith Nwako’s doctoral research at the University of Huddersfield tackled exactly this problem. Her thesis proposed a method called MoIST, or Method of Incorporating Systems Thinking into Information Systems Design, which combined traditional software engineering with Peter Checkland’s Soft Systems Methodology.

The central argument was simple: software projects rarely fail because developers cannot build systems. They fail because organisations misunderstand the problem they are trying to solve. That observation feels as relevant in the age of AI as it did in 2007.

The Reservoir Dogs Problem

Think about Reservoir Dogs. Nobody knows exactly what is happening, everyone has a different version of events, nobody fully trusts anybody else, and people are working towards different objectives while communication gradually collapses into chaos.

Now replace Mr White with Operations, Mr Pink with Finance, Mr Blonde with Sales and Joe Cabot with the Executive Team, and you have something that looks uncomfortably like many software projects. The issue is not usually technology. The issue is that every stakeholder sees a different system.

Operations may think the problem is planning efficiency, while Finance thinks the problem is invoicing. Sales may frame it as a customer experience issue, while IT sees poor data quality as the root cause. Everyone may be technically correct, but nobody is completely right because each person is only seeing part of the wider system.

As Peter Checkland observed decades ago, organisations are not machines. They are collections of people with different goals, assumptions, incentives and worldviews. Software projects inherit all of that complexity, whether the project plan acknowledges it or not.

Hard Systems vs Soft Systems

Traditional software engineering is what systems thinkers call a hard systems approach. Hard systems thinking assumes that the problem is known, the objectives are clear, success criteria are agreed, requirements can be gathered and the system can then be optimised.

Once those assumptions hold, engineering can begin with confidence. The challenge is that organisations rarely behave this neatly. Real organisations are messy because people disagree, departments optimise for different outcomes, politics exist, culture exists and nobody has updated the process documentation since 2014.

There is also always someone like Dave from Planning, who still has a spreadsheet he built in 2009 and refuses to give up because, in his words, “the system doesn’t do it properly.” Dave may sound like a blocker, but very often Dave is actually the person who understands the real process better than anyone else.

This is where Soft Systems Methodology enters the picture. Instead of starting with, “How do we build the solution?”, it starts with the more important question: “What exactly is the problem?” That sounds obvious, yet entire industries have been built around avoiding the question.

The Product Manager’s Favourite Mistake

One of the most interesting observations in Nwako’s thesis is that organisations frequently make design decisions before they fully understand requirements. As product managers, we see this constantly.

A stakeholder says, “We need AI.” The product manager asks, “What problem are we solving?” The stakeholder replies, “The AI problem,” before suggesting that perhaps a chatbot would help. Three months later, the chatbot is answering questions nobody asked and solving problems nobody had.

The software may work perfectly, but the project can still fail spectacularly because success was defined around a solution rather than a problem. This is the equivalent of spending six months selecting the perfect getaway car before deciding what you are stealing. Even Tarantino’s criminals usually work that bit out first.

Rich Pictures and Other Weird Things

One of the techniques used within Soft Systems Methodology is something called a Rich Picture. The name sounds like something a Silicon Valley consultant invented after three espressos and a mindfulness retreat, but in reality it is brilliantly simple.

You draw the organisation, not as a process diagram or a system architecture diagram, but as the actual situation. You include people, relationships, conflict, frustrations, information flows, power structures and the awkward things that rarely appear in a formal requirements document.

When you do this, you often discover the real bottleneck. In logistics software, for example, a planner may complain that route optimisation is slow. After investigation, the real issue may turn out to be poor order quality, missing collection windows, inconsistent customer data, last-minute manual amendments and multiple communication channels.

The routing engine is innocent. Like Vincent Vega, it was simply in the wrong place at the wrong time.

Example Rich Picture

flowchart TD

    SALES[Sales Team]
    CUSTOMER[Customer]
    TMS[TMS]
    PLANNERS[Planners]
    EXCEL[Excel]
    PHONE[Phone Calls]
    BOARD[Whiteboard]
    DRIVERS[Drivers]
    OPS[Operations]

    SALES -->|Last minute promises| CUSTOMER
    CUSTOMER -->|Incomplete orders| TMS

    TMS --> PLANNERS

    PLANNERS --> EXCEL
    PLANNERS --> PHONE
    PLANNERS --> BOARD

    EXCEL --> PLANNERS
    PHONE --> PLANNERS
    BOARD --> PLANNERS

    PLANNERS -->|Load Plans| DRIVERS

    DRIVERS -->|"Nobody told me about that stop"| OPS

    OPS -->|Complaints| PLANNERS

    SALES -.->|"Can we squeeze in one more delivery?"| PLANNERS

    CUSTOMER -.->|"Where's my delivery?"| OPS

Notice what this reveals. The planners appear to be the bottleneck, but the real issues may be sales entering orders late, multiple information channels, poor customer data quality, manual workarounds and communication failures.

The planning software is not necessarily the constraint. The organisation may be the constraint, and Goldratt would be nodding approvingly at this point.

CATWOE: Asking Better Questions

Once the situation is understood, Soft Systems Methodology uses a technique called CATWOE. CATWOE forces us to view the problem through several lenses rather than allowing one department, one stakeholder or one preferred solution to dominate the conversation.

Transport Planning Example

From CATWOE we create a Root Definition:

A system owned by the Transport Manager and operated by planners that transforms incomplete and fragmented transport demand into efficient executable delivery plans in order to improve customer service and operational efficiency within the constraints of legislation, vehicle availability and customer requirements.

Notice what is missing from that definition. There is no mention of AI, databases, APIs, Kubernetes, microservices or chatbots, because none of those things are the problem. They are potential solutions, and treating them as the starting point is exactly how teams end up building technically impressive things that do not improve the system.

As product managers, we often jump straight to discussing solutions. SSM deliberately forces us to remain in the problem space, which is the difference between asking, “How do we build a better planning screen?” and asking, “Why do planners need a better planning screen?” One question produces a backlog, while the other produces understanding.

Designing the System Before Designing the Software

This is perhaps the strongest lesson from the research. Most organisations design software, but far fewer design systems, and there is a significant difference between the two.

Software is technology. Systems are people, processes, information, incentives, behaviours and technology working together. Improving software without understanding the wider system often produces the corporate equivalent of replacing the tyres on a car with no engine. Technically, something has improved, but the practical outcome remains disappointing.

For product managers, this distinction is critical. When we discuss Transport Management Systems, Warehouse Management Systems, ERP platforms, AI assistants and planning tools, we are rarely just building software. We are redesigning human systems, and the software is simply the most visible part of that redesign.

What MoIST Got Right — And Where Time Has Moved On

Reading the thesis nearly twenty years later is fascinating because some parts feel remarkably modern while others are clearly products of their era. The strongest ideas have aged exceptionally well, particularly the need to understand the problem before designing the solution, explore multiple stakeholder perspectives, recognise that organisations are social systems rather than machines, separate the problem space from the solution space and incorporate human and organisational factors into system design.

These principles sit comfortably alongside modern approaches such as Product Discovery, Design Thinking, Service Design, Event Storming, Domain Driven Design, Continuous Discovery and Jobs To Be Done. In many ways, MoIST was tackling product discovery before product discovery became fashionable.

UML Everywhere

Like many methodologies of the early 2000s, MoIST assumes UML will become the dominant language of software design. The industry largely moved on from that assumption.

Today, most product teams are more likely to use User Journey Maps, Service Blueprints, Event Storming, Domain Models, BPMN and User Story Mapping than detailed UML diagrams. The UML revolution turned out to be rather like the wedding rehearsal in Kill Bill: everyone expected it to go one way, but reality had other plans.

Heavyweight Documentation

MoIST emerged during a period when large up-front design was still common. Modern agile teams generally favour short feedback loops, incremental delivery, rapid experimentation and continuous learning over extensive documentation before development starts.

A contemporary product team would probably borrow MoIST’s thinking tools while dramatically reducing its documentation burden. The value is not in turning product discovery into a paperwork exercise; the value is in forcing the team to understand the problem before committing to a solution.

AI Changes the Economics

In 2007, software development was expensive. Today, AI can generate a prototype before you have finished your second coffee, and that changes the economics of delivery.

Ironically, this makes systems thinking even more important. The bottleneck is no longer simply coding. The bottleneck is understanding. When software becomes cheap to build, building the wrong thing becomes even more dangerous because teams can now generate waste at impressive speed.

Why This Matters More in the Age of AI

For years, software development was constrained by technical capability. Today, it is increasingly constrained by organisational capability, which means the most valuable skills are becoming problem framing, stakeholder management, systems thinking, organisational design and requirements discovery.

In other words, the most valuable skills are the exact things MoIST was trying to improve. The death of SaaS has been greatly exaggerated, but what is changing is where value sits. Increasingly, value sits in understanding the problem rather than writing the code.

As AI makes software generation easier, the value of good product managers, business analysts and systems thinkers increases. Someone still has to figure out what should be built, why it matters and how it fits into the wider organisation.

As Douglas Adams might have observed, AI is getting very good at providing answers. The challenge remains finding the right question.

The Big Kahuna Burger Conclusion

The lasting contribution of Nwako’s research is not MoIST itself. It is the reminder that technology projects are ultimately human projects, and a technically perfect solution to the wrong problem remains the wrong solution.

Before building software, understand the system. Before designing the interface, understand the organisation. Before implementing AI, understand the people. Before writing requirements, understand the world those requirements live in.

Or, as Jules Winnfield might have put it if he had become a Product Manager instead of a hitman:

“The path of the righteous Product Manager is beset on all sides by the inequities of poorly defined requirements and the tyranny of stakeholder assumptions.”

Unlike a Tarantino film, most project disasters do not happen because somebody gets shot. They happen because nobody stopped to ask the most important question: what problem are we actually trying to solve?

That is a lesson from 2007 that feels increasingly valuable in 2026.

Back to Writing