In the early 1980s, Eliyahu Goldratt had what most technology entrepreneurs would consider a good problem.

The production-scheduling software developed by his company worked. Its customers included companies such as RCA, GE, GM, Bendix, Westinghouse, Kodak, Philips and ITT. Goldratt later wrote that many customers reported increased production, lower inventory and payback periods of less than six months. His company had become one of the fastest-growing businesses in the United States. [1]

Yet Goldratt was frustrated.

If the results were so compelling, why was adoption not spreading much faster?

His team tried what technology companies normally try: seminars, presentations, workshops and pilot implementations. They explained the software and demonstrated what it could do.

Progress remained much slower than Goldratt expected.

Out of that frustration came an unusual idea. Instead of explaining the software again, he would explain the thinking behind it through a novel about a struggling factory.

That novel became The Goal.

A book almost nobody wanted

The idea was not immediately welcomed.

Goldratt later recalled that even people inside his company were sceptical. Jeff Cox, who worked with him on the book, preferred to be paid rather than take a share of royalties. Around two dozen publishers rejected the manuscript before North River Press agreed to publish it, initially expecting that even the first printing of 3,000 copies might be difficult to sell. [1]

Then something unexpected happened.

Plant managers began reading the book and recognising their own factories in it. Letters started arriving from managers saying that the situations described in The Goal looked remarkably similar to their own operations.

Some went further. They began implementing the ideas themselves.

One plant manager wrote to Goldratt that the book was no longer a novel for him; after following Alex Rogo’s actions, it had effectively become a documentary of what had happened in his own plant. Managers began inviting Goldratt to see what they had changed. [1]

For Goldratt, this should have been a triumph.

Instead, it led to one of the most uncomfortable discoveries of his professional life.

The companies without the software were sometimes doing better

Goldratt began comparing these implementations with companies that had purchased his software and accompanying education.

What he saw disturbed him.

Plants that had taken the ideas from The Goal and translated them into changes on the shop floor were, in some cases, achieving better results - and achieving them faster - than companies that had invested heavily in his software. [1]

The conclusion was particularly difficult because there was nothing fundamentally wrong with the software.

The software worked.

The problem was where management attention was going.

Goldratt concluded that the effort involved in installing and operating the software could distract people from the more important work: changing the fundamental concepts, measurements and procedures that governed the plant.

He described the software he had spent almost a decade developing as his “cherished baby”. Yet the evidence had forced him to confront the possibility that it was becoming an impediment to achieving the very results it had been created to deliver. [1]

This was not merely an intellectual dilemma. His company depended on selling the software. Goldratt wrote openly about the conflict between his responsibility to shareholders and employees, and what he now believed was his responsibility to customers.

Eventually, the company deteriorated and Goldratt was asked to leave. He subsequently founded the Avraham Y. Goldratt Institute, where the emphasis shifted much more explicitly toward generating knowledge and helping organisations change the way they operated. [1]

What were the successful plants actually changing?

Contemporary accounts provide useful clues.

In 1987, The Christian Science Monitor reported on James Rulseh, who managed a Modine Manufacturing plant in Illinois. After repeatedly reading The Goal, he began testing its concepts on the factory floor.

According to Rulseh, manufacturing lead time fell from approximately 13-14 days to 3-4 days, with some runs taking only two days. Work-in-process inventory fell by around 70 percent, while absenteeism declined by approximately 25 percent. [2]

The important point was not that Modine had obtained a more sophisticated schedule.

The physical system was being operated differently.

The organisation was questioning how work should flow, where management attention should go, and the assumption that keeping every resource busy was necessarily good for the system.

The same contemporary report described Convergent Technologies buying about 200 copies of The Goal and organising study sessions around its ideas. A plant manager recalled that the company had earlier been in serious difficulty, with cash heavily tied up in inventory. [2]

Another documented example came from Dow Corning. Robert Kain described receiving The Goal when his plant had approximately 50 percent on-time delivery, more than 100 days of inventory, and customers on allocation because demand could not be met. The organisation began applying the ideas, identifying its constraint and changing the way resources were focused. [3]

The significance of these examples is not that every organisation followed exactly the same implementation.

It is that the improvement came from changing the system by which work was managed, not simply from producing a better schedule.

Goldratt then encountered a second problem

Success of the book created another puzzle.

Large numbers of managers read The Goal, agreed with its arguments and described them as common sense.

And then changed almost nothing.

Goldratt began asking why some organisations translated the thinking into results while so many others did not.

He eventually identified three recurring obstacles: [1]

• The ideas did not propagate through the organisation. A few managers might understand the logic, while the people making daily decisions continued operating according to the old rules.
• People struggled to translate the concepts into practical operating procedures. Understanding an example was different from knowing exactly what to do on Monday morning in a particular plant.
• Existing measurements continued driving the old behaviour. Even when people understood what should change, policies and performance measures often rewarded them for doing the opposite.

The organisations that succeeded from the book alone had something unusual in common. Goldratt observed that they tended to be led by strong, analytical plant managers who could create buy-in and then work with their teams to develop the required procedures. [1]

That discovery pushed his work further.

It was not enough to tell people to focus on the constraint. Organisations needed operating rules for how work would be released, how priorities would be managed, how buffers would be used, how performance would be measured and how people should respond when the system came under pressure.

This work contributed to the formalisation of Drum-Buffer-Rope, Buffer Management, the Five Focusing Steps and eventually the wider body of knowledge that became the Theory of Constraints. [1]

The lesson had become larger than software: changing results required changing the operating system of the organisation.

Four decades later, projects face the same problem

The project industry today has substantially better technology than it had even a decade ago.

Organisations have sophisticated scheduling platforms, integrated project controls, ERP systems, mobile progress reporting, digital control rooms, dashboards, 4D and 5D models, and increasingly AI-based analysis.

All of these can be useful.

But Goldratt’s experience raises a question that is easy to overlook:

What has physically changed in the way the project is being executed?

If work is still released before drawings, materials, decisions or access are ready, better visibility does not remove the interruption.

If the same people are still spread across too many simultaneous work fronts, a more sophisticated priority algorithm does not automatically create focus.

If teams respond to delay by opening additional work so that everybody remains busy, digitising the additional work-in-progress does not shorten cycle time.

If contractors and departments continue being measured predominantly on local progress, utilisation or monthly volume, a central dashboard does not automatically make them behave according to overall project flow.

And if management reviews continue to revolve around chasing hundreds of activities, the fact that those activities are now visible in real time does not fundamentally change the execution system.

Technology can make the existing system more visible without making the system itself better.

That distinction matters.

There is a difference between digitising project management and changing project execution.

The same trap exists in Critical Chain implementations

This lesson is particularly relevant to organisations implementing TOC or Critical Chain Project Management.

It is possible to implement the visible mechanics of Critical Chain without implementing the underlying change.

The project gets a Critical Chain. Buffers are calculated. Tasks receive priorities. New reports are generated. Software begins showing buffer consumption and projected dates.

Yet the organisation may continue behaving largely as it did before.

Projects continue to be released irrespective of available capacity. Resources continue to multitask across multiple priorities. Work starts before the required inputs are ready. Contractors continue being pushed to maximise local progress. Monthly volume remains the dominant measurement. Management continues intervening in individual activities rather than controlling how work moves through the system.

In such an environment, Critical Chain has effectively been added to the traditional management system rather than replacing the operating assumptions that created the problem.

That distinction is fundamental.

The implementation challenge is therefore not merely to create a Critical Chain schedule. It is to change the physical rules of execution: when work is allowed to start, what must be ready before it starts, how much work is allowed to remain active, how scarce resources are prioritised, how handovers occur, how performance is measured and what management reviews are designed to control.

Without these changes, organisations eventually face pressure to fall back on the familiar system. When execution becomes difficult, more work is opened, priorities multiply, local progress again becomes important and the new methodology gradually gets absorbed into the old way of working.

The terminology survives.

The behavioural change does not.

Software becomes powerful when it reinforces the management system

Goldratt did not conclude that technology was unnecessary. He continued using computers extensively and later developed computer-based learning tools himself. [1]

His experience pointed to a more precise distinction.

Software is powerful when it reinforces the right management system. It cannot substitute for creating that management system.

In projects, a system can show which work has priority, but management has to protect that priority.

It can show that a task is not ready, but the organisation has to be willing not to release it.

It can reveal excessive work-in-progress, but leadership has to make the decision to stop opening more work.

It can calculate cycle time, but the measurement system has to make cycle time matter.

It can show that resources are overloaded, but management still has to choose where those resources should be concentrated.

This is where the difficult part of transformation lies: in changing how work is prepared, released, prioritised, executed, measured and reviewed.

Goldratt encountered this lesson in perhaps the hardest possible way.

He had built software that worked. But the evidence showed him that organisations could achieve more when they first changed the system by which work was managed.

For project leaders investing today in new planning platforms, digital project controls, AI and increasingly sophisticated software, the question remains remarkably similar:

Before asking what the next tool can do, ask what will actually change in execution.

Sources

• [1] Eliyahu M. Goldratt, ‘My Saga to Improve Production,’ TOC-Goldratt.
• [2] The Christian Science Monitor, ‘A novel approach to management,’ 13 February 1987.

‍

Read more articles:

Why Software Has Struggled to Deliver in the Construction Industry?

How CCPM and Little’s Law Reduced Cycle Time in Aircraft Maintenance at WR-ALC?

Reducing Cycle Time by 33% at WR-ALC: A U.S. Air Force Case

Solar Projects Don’t Miss Timelines for the Reasons You Think

Critical chain project management (CCPM): why projects remain late and how CCPM actually fixes it?

Why projects are late even when everything seems managed?

Beyond fragmentation: Toyota's cell manufacturing model offers a blueprint for construction

What if our best attempts to minimize time and cost overruns in projects are pointless?

How we can solve the late project problem?

Implementing critical chain in large infrastructure projects

Part 1: Why critical chain is not a science?

Part 2: Who said critical chain is not a science?

Part 3: Let’s make critical chain a science