On this page
Why I keep reaching for the same TOC tool in completely different situations — and what that tells you about where Critical Thinking sit relative to any single methodology.
There's a habit I've developed over the years that I think is worth naming explicitly, because I don't see it discussed often enough: Critical Thinking should sit above discipline, not inside it.
What I mean by that is this. CCPM, Lean, Six Sigma, ITIL, whatever framework you're trained in — these are all disciplines, with their own vocabulary, their own tools, their own boundaries. They're useful precisely because they're specific. But the moment you start treating a discipline's tools as the only lens available, you lose something important: the ability to recognize when a tool built for one context is actually solving a more general problem, one that shows up in places the discipline's own vocabulary never anticipated.
Buffer Management is the clearest example of this I've personally lived through. I've now applied the same underlying instrument — a buffer, divided into zones, read either by consumption rate or by simple penetration depending on what it's aimed to — to two completely different problems, years apart, in the same company. Neither application followed exactly the discipline, but both worked for the same reason, and that reason is worth pulling out explicitly.
Why Buffer Management Generalises
According to the TOCICO Dictionary, Buffer Management is
a control mechanism based on the amount of time — or stock — remaining, used during the execution phase of TOC applications across operations, projects, and distribution
Note what that definition does not say: it doesn't say "for projects only" or "for manufacturing only". It's defined at the level of the mechanism, not the domain.
The mechanism itself is almost embarrassingly simple. Take whatever is protecting you against variability — time against a deadline, stock against demand, capacity against load — and divide it into three "variability" zones: expected, normal, and abnormal. What differs is how you read it. A project buffer compares consumption against how far along the critical chain actually is — that's a rate. A stock buffer has nothing to compare against; you just look at how deep into it you've gone — that's a level.
The capacity buffer I'll describe later works the same simple way: no comparison, just how much is left. Same three zones underneath, two ways of reading them. It works as a green/amber/red semaphore because it compresses a hard question ("are we in trouble?") into something you can read at a glance.
Nothing in that mechanism is specific to project management, or to any other discipline. It's specific to anything that unfolds against a deadline, where you need an early warning before the deadline is missed rather than a binary pass/fail at the end. That's a much larger category than "projects".
First Application: Incident and Service Request Management
I first applied this thinking outside of a formal project context when I was requested to looking at how my organization handled IT incidents and service requests. This was in a strongly regulated pharmaceutical environment, where incident management carries real weight — unplanned issues that could affect product quality or data integrity (and in the end patient safety) need to be caught and resolved before harm occurs, and the regulatory expectation around that is unambiguous.
The operational problem was a familiar one to anyone who's run a ticket queue: every incident management tool has its own algorithm for prioritizing tickets by severity, and every ticket gets a resolution window based on that severity. But severity-based prioritization alone breaks down quickly in practice. You may end up with several high-priority tickets simultaneously, all urgent, all with similar due dates. After a couple of days some have had real progress made against them, others have had none — but severity alone doesn't tell you which ones are actually at risk of breaching their SLA. It's easy, in that situation, to feel overpowered without being able to say precisely why, or which ticket needs attention first.
The fix was to treat the time allocated to resolve each ticket as a time buffer. Tickets kept their existing priority label — incident or service request, with whatever severity classification the tool already assigned — but their urgency to act on right now was recalculated continuously based on Buffer Consumption Rate: time already elapsed divided by total time allowed: a ticket at 40% buffer consumption with little progress made sits in the amber zone and gets flagged for a mitigation plan before it has any chance of sliding into red. This let management see, across an entire queue of tickets with similar severity and similar due dates, exactly which ones needed attention today — not based on a static severity score, but based on how the situation was actually evolving in real time.
That distinction matters. Severity tells you how bad a ticket would be if mishandled. Buffer consumption tells you how close it actually is to being mishandled, right now. The two are different questions, and only one of them changes day to day.
This piece of work was never something I'd been taught to do as part of an ITIL playbook or a CCPM course. It came directly from recognizing that "time remaining against a deadline, monitored as a consumption rate rather than a countdown" was a TOC pattern that happened to fit a ticketing problem perfectly — even though tickets are not projects, and ITIL is not CCPM.
Second Application: Drum Resource Capacity
These days, years later, working through running a CCPM portfolio, I found myself reaching for exactly the same underlying instrument — this time applied to a problem that had nothing to do with tickets and everything to do with a single constrained team.
The starting question was about my drum resource: an OT infrastructure team acting as the constraint across a multi-project portfolio. The standard CCPM approach to this question is to calculate a pooled-hours Drum Capacity — available team hours divided by estimated consumption per project — and gate releases against that number. I ran that calculation, and the result didn't survive contact with reality. The team is running far more concurrent projects than the formula said should be possible, and yet the work was visibly getting done.
Digging into the actual historical task duration data eventually surfaced that the real issue wasn't team-level volume at all — it was an uneven distribution of load across individuals. Breaking a team-level capacity chart into one chart per person revealed that a few team members were genuinely stretched while others had real headroom, with one additional team member still in onboarding and appropriately unloaded.
That distribution problem is what brought Buffer Management back into the picture, in a form that's directly analogous to what I'd done with the ticket queue years earlier. Once it was clear that the right unit of analysis was the individual, not the pool, the natural next step was to ask: what if I'd use a time buffer, for each person's capacity?
The answer is the same mechanism, relabelled. For each individual resource, define total available capacity over a planning horizon, define allocated capacity as the sum of scheduled hours already committed against that person, and the difference is their remaining capacity buffer — expressed as a percentage, with the same green/amber/red zones as any other buffer. There's no progress axis here, so this is a penetration read, not a consumption rate: it doesn't ask how fast the buffer is being used relative to some milestone, it simply asks how much of it is left.
The release decision at a weekly portfolio meeting becomes: does releasing this project push any individual's buffer from green into amber, or amber into red? That's the same three-zone logic as a project buffer, just read the simpler way — how much capacity remains — applied to a person's workload instead of a ticket's countdown or a project's schedule.
It's worth being precise about what this buffer is actually for, because it's easy to misread it as a workload-balancing exercise. It isn't. Spreading hours evenly across the team so everyone sits at a similar load is not the goal, and chasing that would be exactly the kind of local optimization TOC warns against — a team that looks "balanced" on paper can still be starving the one person whose output the whole portfolio's flow actually depends on. The point of the buffer is to protect and increase flow through the constraint: keep the drum resource fed without interruption, catch the moment someone's heading toward overload before it actually delays a critical chain, and free up the headroom that lets you release the next project sooner rather than later. Rebalancing assignments toward whoever has a green buffer is a tool for getting there, not the destination itself. If reassigning work to a less-loaded person doesn't translate into the portfolio moving faster, the rebalancing hasn't actually achieved anything.
The point of a buffer is to protect and control
Why Time Is the Constraint in Both Cases
Goldratt was explicit that in project environments, the number one constraint is time. Not a machine, not a person, not a budget line — time itself, because a project's value is realised at a single point (completion), and every day lost before that point is value that cannot be recovered by working harder afterward. That's why CCPM's entire architecture — critical chain identification, project buffers, feeding buffers, resource buffers — is built around protecting time specifically, rather than protecting cost or protecting any individual task's local schedule.
The drum capacity buffer I described above is, first and foremost, a gate signal: green means the release gate stays open, amber means proceed with attention, red means the gate closes — hold the release, or reassign the work to someone with headroom. That's its job at the weekly portfolio meeting, full stop.
It also happens to sit inside a CCPM portfolio, which is why a red reading carries the weight it does: it means the constrained resource cannot absorb more demand without delay propagating through the critical chain, putting the project's due date genuinely at risk. That's Goldratt's point about time being the number one constraint in project environments, showing up exactly where it should — as the reason the gate matters, not as the gate itself.
I don't think the incident management case is actually an exception to this. A ticket's value — preventing or resolving harm — is realized at a point in time too, and a lost hour of response isn't recoverable afterward by throwing more people or money at it, any more than a lost day on a project is. Goldratt's reasoning for why time is constraint number one was never really about projects specifically — it was about anything whose value is realized at a fixed point, where a delay can't be bought back after the fact. Both cases qualify. That's also, I think, why the same buffer mechanism works cleanly in both: it isn't a coincidence that a tool built for protecting project due dates turned out to fit a ticket queue just as well. They're both, underneath, the same kind of problem.
The Actual Point
What connects the ticket queue and the drum capacity buffer isn't that both are "secretly CCPM." They're not. One is an ITIL-flavoured operational queue; the other sits inside an actual CCPM portfolio — and even between the two, the read isn't identical: the ticket buffer is a consumption rate against progress, the capacity buffer is a plain penetration read with no progress axis at all. What connects them is that Buffer Management is a very powerful and helpful tool not related to a particular discipline. It asks only: is there something being protected against variability, is there a meaningful zone of "fine" versus "watch this" versus "act now," and is the right read for this situation a rate or a level?
If those conditions hold, the three-zone buffer with consumption-rate monitoring is available to you — regardless of whether your training tells you this is a "project management tool" or an "ITIL tool" or something else entirely. That's what I mean by Critical Thinking sitting above discipline: the discipline gives you vocabulary and a community of practice, which is genuinely valuable.
But Critical Thinking — actually questioning whether the framework you were trained in is the right lens for the problem in front of you — doesn't belong to any discipline. It's an attitude, not a technique. That actually lines up with a couple of TOC pillars. "Never Say I Know": don't assume you've already got this figured out just because it worked last time. And managing "the fear of the unknown": the tendency, especially inside organizations, to respond to anything unfamiliar by tightening control — more process, more approval steps, more rules — rather than sitting with the discomfort of not having it figured out yet.
Noticing that a tool built for tickets also fits a team's capacity isn't some happy accident outside the framework. It's those same mindsets doing their job — just aimed at your own toolbox for once, instead of at the problem.
I've now seen it show up twice, in the same organization, years apart, in two situations that have almost nothing in common operationally. I'd be surprised if that's the last time.
If you're working through a constraint-management problem that doesn't fit neatly inside whatever framework you were trained in, that's usually a sign you're looking at the right level of the problem, not the wrong one. I work with organizations applying TOC thinking — CCPM and otherwise — to exactly these situations. Get in touch if it would help to talk it through.
