Chapter 3: Managing with Imperfections

Imperfections are inevitable. Micromanagement is optional.

Every manager lives in a world of imperfections. Machines fail. Suppliers deliver late. Customers change their minds. Estimates are wrong. For years, I believed that, in addition to the Five Focusing Steps, buffer management was one of Goldratt’s greatest contributions. I thought it was simply a way to protect the schedule. What changed over time was not my appreciation for buffers, but my understanding of how they ought to be used—and how easily they can be misused.

Managers spend enormous effort trying to eliminate the imperfections that plague operations: diligent planning to anticipate every detail, continuous improvement efforts, metrics to hold people accountable, and so on. But they cannot. Imperfection is not an exception to reality. It is reality. The opposite response is no better: don’t plan at all, fly by the seat of your pants, and react to whatever happens next. We know how that goes.

Goldratt offered a third way: buffers (unscheduled blocks of time) and buffer management. Buffers protect flow from the inevitable disruptions that occur in every dependent system. But buffers are more than protection from imperfections. It has taken me almost thirty years to understand that.

My education began in 1996. I was still at Thru-Put when Eli sent me the advance galleys of Critical Chain. I thought he wanted feedback on his upcoming book. What he really wanted was for us to build software to support his new approach to project management: Critical Chain, which accounted for limited resources instead of Critical Path, which ignored them.

At first glance, it didn't seem particularly difficult. We already understood finite-capacity scheduling for manufacturing. I called Eli and told him that while buffer placement was different in projects, and while a project network replaced bills of material and routing files, the overall software architecture looked familiar. The critical chain scheduling algorithm required some work, but it wasn’t a big deal.

Before we had even started working on it, Eli told Elbit Systems in Israel that our existing software had a “switch” that changed the placement of buffers and the scheduling algorithm. He told them that the software was ready to be used in projects.

It wasn’t.

Elbit invited us to Israel for a software demo, and Ravi spent the flight to Tel Aviv writing code. When we arrived, the software was working but still crashing and not producing consistent results. Ravi worked overnight until Guy Brill, Elbit’s COO, picked us up from the hotel at six a.m. He kept working in the car and then continued during our meetings, while I did everything I could to delay the demonstration. I filled whiteboards and flipcharts with discussions about their projects, explained scheduling logic and buffers, and talked about existing customers. Every hour bought Ravi another hour.

Eventually there was no more time to buy, and we had to run the software. To our enormous relief, it produced the same schedule that Elbit’s team had painstakingly developed by hand. This was not the first time Ravi had produced last-minute magic. That was enough for Guy. He agreed to buy the software.

Looking back, however, a successful software demonstration was the least important thing that happened that week.

Guy kept returning to the same subject. He wanted more sophisticated scheduling, more intelligence built into the software. Of course I disagreed, and on our last day I finally told him so.

“Guy, thank you for inviting us and agreeing to become our first customer for this software,” I said. “But we won’t be able to meet your expectations. What you want from the software is different from what we think the software should do.”

Guy looked at me calmly. “That’s fine,” he said. “But since Eli brought you here, we should tell him.”

That evening, Guy drove us to Eli’s home. He had already explained the situation over the phone. After we arrived, after the hellos and shaloms, Eli turned to me. “Sanjeev, did you again tell one more company that you will not sell your software to them? Let me talk to Guy. You go outside and smoke a cigarette.”

To this day, I have no idea what Eli said to Guy while I was outside. When I came back in, the conversation had changed. Guy no longer wanted better scheduling. He wanted something much simpler—and much more powerful. He wanted every project participant to know exactly one thing: What should I be working on right now?

To this day, I have no idea what Eli said to Guy while I was outside. When I came back in, the conversation had changed. Guy no longer wanted better scheduling. He wanted something much simpler—and much more powerful. He wanted every project participant to know exactly one thing: What should I be working on right now?

Guy made a second observation that proved equally important. “The web is coming,” he said. “People shouldn’t have to stand around a Gantt chart.”

He was right. Instead of treating the schedule as a cluttered graphic, we built a web-based buffer management report that anyone could access from anywhere.

A few weeks later I demonstrated it at Israeli Aircraft Industries. They had already been using a competitor's software for scheduling, and quite successfully. Their issue wasn’t the schedule. It was the management process. Every discussion about priorities required dozens of people standing around a printed Gantt chart trying to determine what should happen next. When they saw the web report, the conversation changed immediately. The schedule had become information. The priority had become visible. Management became easier.

Over the next several years, our software, Concerto, spread rapidly. Large organizations managing hundreds of simultaneous projects discovered that people did not need a better schedule nearly as much as they needed better priorities during execution. A multi-million-dollar contract with Lucent came first. Their Vice President, Mary Sajak, immediately understood what she was buying. She wasn’t investing in scheduling software. She was investing in execution visibility. The implementation was successful, and for the next six or seven years our company grew by roughly fifty percent annually. More multi-million-dollar contracts followed. Seagate. Medtronic. L&T. The U.S. Air Force.

Everything suggested we had found the answer. But something kept bothering me. At Lucent, most projects remained red. At Seagate, the same thing happened. At Medtronic, again. Everywhere we went, the software and the method worked. Throughput increased. Cycle time shrank. Yet recovering red buffers remained a constant struggle, and on-time delivery never improved as much as I expected.

Our consulting partners blamed resistance to change. I wasn’t convinced. The pattern was too consistent. When the same problem appears in organization after organization, the first place to look is not the customer. It’s yourself.

Rockwell Collins forced me to see it. They were developing software for GPS systems. Software development is not an assembly line. The same engineer often needs to stay with a project from detailed design through testing and rework. Knowledge accumulates inside the person doing the work. Handing it off casually does not save time; it destroys continuity.

Our buffer management process did not understand that. When a project went red, the logic said to move engineers to recover the buffer. On paper, it made sense. One project was in trouble. Another seemed less urgent. Shift the resource. The tool designed to prevent multitasking was creating it.

The pilot failed. It deserved to fail.

That failure was painful, but it was also clarifying. I could no longer pretend the problem was customer resistance. We had built a system that, under pressure, encouraged exactly the behavior TOC was supposed to prevent. Buffer management was identifying the problem correctly, but our response to the signal was damaging the flow.

Rockwell revealed a second edge of the sword. The task management process itself had become a form of micromanagement. Daily remaining-duration updates. Daily management reviews. Engineers reporting instead of engineering. Managers reviewing reports instead of solving problems. The overhead was consuming the very capacity the system was supposed to protect.

Two fixes were needed. The first was to raise the level of task definition. Instead of breaking work into granular tasks that could be shuffled between people based on buffer signals, define work at a level where one person or a team owns a coherent chunk of work—from detailed design through testing and rework. Finish the work instead of constantly reassigning fragments of it.

The second fix emerged from three engagements that were unfolding around the same time. At Hamilton Beach, Paul Blankenship was adamant that the project pipeline should not be overloaded. He understood something that we had not yet fully absorbed. Buffer management cannot rescue an overloaded pipeline. If too many projects are launched into execution at once, every project will compete for the same people. Buffers will turn red not because people are resisting change, but because the system was overloaded before execution even began.

When Hamilton Beach executed with a controlled pipeline, buffer management worked cleanly. At LSI Logic, we convinced the team to stagger project starts instead of managing red buffers more aggressively. Linda Babcock and Uma Shankar had the courage to put some projects on hold, and the results were immediate. The redness diminished, not because buffer management had improved, but because the loading had been controlled before execution began.

At Warner Robins Air Logistics Center, it crystallized. Staggering was not a scheduling technique. It was a prerequisite for good execution. Higher-level tasks. Staggered loading. Those ideas came together and became the foundation of what we later called Focus & Finish. The workstream became the unit of management. The bucket became the execution unit. Staggering controlled the loading. The buffer protected the workstream instead of being hidden inside every individual task.

That was a major shift in my thinking. For years I had believed that better buffer management would produce better execution. Rockwell, Hamilton Beach, LSI Logic, and Warner Robins taught me the opposite: better execution conditions produce cleaner buffer management.

If people are overloaded, fragmented, and constantly reassigned, buffer signals merely tell you that the system is drowning. If the pipeline is controlled, work is defined at a meaningful level, and people are allowed to stay with coherent chunks until completion, buffer management becomes useful again. It stops being a firefighting mechanism and becomes an early-warning system.

I thought that lesson had settled the matter. Then came the U.S. Naval Shipyards.

In 2025, we were asked by the Vice Chief of Naval Operations to help improve performance at Norfolk Naval Shipyard. The outward problem was accountability. Commitments were being made and missed everywhere. Action items from meetings went unfulfilled. The instinctive response was understandable: demand stronger commitments, track them more aggressively, and hold people accountable when they were missed.

It took me a while to understand. “We cannot enforce accountability on a messed-up plan. Let’s first create the conditions for accountability. Create a plan that can be executed. Control work-inprocess. Define work in chunks people can finish. Protect flow. Then, and only then, does accountability mean anything.”

We made progress. And then we almost fell into our own trap. Buffer management risked becoming the new accountability hammer.

A buffer turns red. Managers demand explanations. Commitments are extracted. Pressure increases. The signal that was supposed to help the organization learn becomes a trigger for micromanagement. It feels decisive. But it is harmful.

People learn very quickly what the system punishes. If surfacing a red-buffer leads to interrogation, pressure, and another commitment they may not be able to keep, they will delay surfacing the problem. They will explain it away. They will wait until the red is impossible to hide.

That is not buffer management. That is managing by fear using colored charts.

We coached meeting by meeting, signal by signal. A red buffer should not begin with, “Who is responsible?” It should begin with, “Why is this workstream consuming buffer?” The next question is not, “What new date will you commit to?” It is, “What intervention is needed to restore flow and the buffer?”

The distinction sounds small. It changes everything.

By the time we reached the U.S. Coast Guard, I had learned to begin every implementation with a warning: “Buffer management can become a tool for micromanagement.”

Nobody wants to be a micromanager. Nobody wants to be micromanaged. So they listened.

“Let me show you what it looks like,” I told them. “Daily duration updates. Buffer signals used as pressure tools. Commitments extracted in meetings and missed a week later.”

Then I asked them a question. “This system will make everything visible. The temptation to use that visibility as a pressure tool will be enormous. How will you avoid that trap?”

By asking the question before implementation, the team became the architect of the answer. They were not simply receiving a methodology. They were designing the behaviors required to use it well. The implementation was swift.

Looking back, buffer management is one of the most important lessons of my career. Buffers are essential because imperfections are unavoidable. Without buffers, every delay becomes a crisis. Every disruption changes priorities. Every dependency transmits variability downstream. But buffers do not work without a different philosophy of response.

The danger is that, instead of managing buffers, managers begin reacting to them. When buffer signals become the basis for constantly moving people, you create the multitasking you were trying to eliminate. When buffer management becomes a daily reporting ritual, you consume the capacity you were trying to protect. When red buffers become accountability triggers, people hide problems until they are too late to solve.

Used well, buffers protect flow. Used badly, they damage it.

Managing with imperfections requires more than inserting safety into a schedule. It requires a philosophy of response. A buffer signal is information, not an alarm. It should create curiosity before action. Why is this workstream consuming buffer? Is the problem local or systemic? Is intervention needed at all? If so, what is the smallest intervention that restores flow without disrupting everything else?

The paradox is that the better the operating system, the less dramatic buffer management becomes. The pipeline is not overloaded. Work is defined at a level people can own. Teams are allowed to finish. Managers intervene to remove obstacles, not to spread anxiety.

Then buffers do what they were meant to do. They absorb imperfections. They reveal emerging risk. They help management see where attention is needed without turning every variation into a crisis.

It took me almost thirty years to realize all this.

What Reality Taught Me

• Buffers are necessary because imperfections are inevitable.
• Buffer signals are information, not alarms.
• Reacting to buffer signals creates multitasking and fear.
• The difference is not the buffers. It is the philosophy of how they are used.
• Used with System 2 Thinking, buffers protect flow. With System 1 Thinking, they damage it^.2

A Debt of Gratitude

My talented ex-colleague, C. Sridharan, deserves a special mention. He forced us to solve the problem of red buffers, and then cajoled, coaxed, and guided the customer to implement the staggering. I still carry great respect for him.

‍

Chapter 4: Managing for What?

Measurements Are Not a Report Card. They Are a North Star.

Managers don't lack measurements. They lack clarity about what they are trying to optimize. It took me more than thirty years to realize that those are not the same thing.

For years, I believed I knew exactly what managers should be trying to achieve: increase throughput, reduce inventory, shorten lead times, and improve on-time delivery. Those objectives became the foundation of our software at Thru-Put Technologies. We were not simply building a finite-capacity scheduler. We were trying to synchronize operations around the system constraint so companies could produce more, ship faster, and carry less inventory.

We even built a product mix optimization module. Given product demand, bills of material, routing files, selling prices, and the available constrained capacity, the software recommended the product mix that would maximize throughput.

One of the first companies to use the module was Hindustan Aluminum. They manufactured many aluminum products but did not have enough capacity to satisfy demand for all of them, even with better scheduling. The question was simple: given limited capacity, which products should they manufacture?

The software produced an answer nobody expected. It recommended stopping the production of corrugated aluminum sheets and increasing production of milk cans. Corrugated sheets were the company’s pride. They had invested heavily in the equipment, the engineering, and the expertise required to manufacture them. Milk cans were ordinary.

Mr. Biyani, the head of the company, looked at the results and immediately called his Chief Financial Officer.

“Are these numbers correct?”

The CFO checked them.

“Yes.”

Mr. Biyani then called his head of sales.

“From today, stop selling corrugated sheets. Sell only milk cans.”

Profitability improved dramatically. I was proud of that outcome because it demonstrated the practical power of TOC. But something else was becoming clear. We could not sell many product mix optimization modules.

The reason was simple. Most companies were not constrained by capacity. Customer orders were late not because they lacked capacity, but because they were mismanaging the capacity they already had. Their problem was not deciding what to produce. It was learning how to manage what they could already produce.

After I was fired from Thru-Put, Eli encouraged me to build a company around Throughput Accounting rather than production scheduling. I did not. I saw Throughput Accounting as a financial reporting system: elegant, certainly, and better than traditional cost accounting, but ultimately just another way of presenting financial information. I wanted to solve operational problems.

Looking back, I completely missed the point. Eli was not asking me to build better accounting. He was asking me to build a better management system. It would take me almost twenty-five years to understand the difference.

In 2023, I joined Vulcan Mozambique. The Naveen Jindal Group had already implemented Ravi Gilani’s Cash Score (a metric that converts Throughput, Inventory and Operating Expense into one number) across all their companies, including Vulcan. Every CEO was given an annual Cash Score target.

I already knew that increasing production—not reducing costs—was the key to turning the mine around. But thinking through the priorities required to improve Cash Score forced us to ask a different question: where was cash getting stuck?

The answer surprised us. We were not mining enough coal because only about forty of our seventyseven mining trucks were operational. To control costs, the company had stopped purchasing new tires, and the number of operational trucks was declining every month. Rebuilding mining capacity would take time.

At the same time, we had enormous inventories of intermediate coal sitting between the mine and the washery. The problem was not the quantity. It was the type of coal. Our mining plans were producing the coal the plan called for—not the coal our customers wanted.

Cash Score pointed us toward a completely different strategy. Instead of Mine-to-Plan, we shifted to Mine-to-Order. We mined the coal customers were waiting for. That single change aligned the mine with customer demand. It also stabilized the feed into the washery, increasing yield from eleven percent to seventeen percent. Within weeks our past-due backlog disappeared. Profits climbed to roughly sixty million dollars per month.

Cash Score continued to shape our decisions. Every week it identified the single improvement opportunity with the greatest impact on cash generation—improving quality, obtaining faster customer approvals, increasing truck uptime, stabilizing feed rates. Everything was prioritized through one lens. You would be surprised how quickly an organization improves when the CEO is focused on only one thing at a time.

I realized that Cash Score was not merely measuring the business. It was helping me manage it. For example, we needed another loader to stabilize feed into the washery. Buying one would cost less but delivery would take several months. Leasing one would cost more but it could begin generating throughput within weeks. Traditional accounting favored buying. Cash Score favored leasing. Traditional accounting required all kinds of cost data. Cash Score required answering mainly one question: how much additional throughput will this decision generate?

Another lesson came from forecasting. As flow improved, cash generation became increasingly predictable. For the first time I could look several months ahead and see where cash would become trapped unless we intervened. The measure was not simply reporting yesterday. It was helping us change tomorrow.

What Reality Taught Me

• The right measure doesn't merely evaluate performance. It guides management.
• Throughput Accounting is theoretically elegant. Cash Score makes it practical.

A Tribute Years in the Making

There was not a single week at Vulcan when I did not think about Eli. He was so right about so many things. More than once, I found myself wishing I could pick up the phone and tell him what we were learning. But he was not with us anymore. I missed him. A lot.

Because I know he would have been proud—not simply because we had transformed the mine from losing twelve million dollars a month to earning roughly sixty million dollars a month, but because I had finally understood the lesson he had been trying to teach.

For more than thirty years I had been helping companies improve operations. Eli had been trying to teach us how to manage. I finally understood.

‍

Find this article interesting, read:

Part 3: From Insight to Breakthrough: The Philosopher-Warrior

Part 1: When the Theory of Constraints Meets Reality

‍

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