Resource Buffer

Concept: Vocabulary that names a phenomenon.

A warning signal placed before a critical-chain task or path start so the assigned resource can set down other work and be ready when the chain needs them.

Also known as: resource alert.

A resource buffer is the easiest CCPM buffer to misread because the word buffer usually means reserve. In Critical Chain Project Management, this one does not. The project buffer protects the project’s due date. Feeding buffers protect critical-chain merge points. A resource buffer protects a start. It tells the person, crew, machine, test rig, or specialist group assigned to an upcoming critical-chain task that the task is approaching and that their other work has to yield.

Context

A critical-chain schedule works only if each critical-chain task starts as soon as its predecessor is done. That rule sounds simple until the project reaches a scarce resource that has been doing something else: a specialist assigned to a non-critical task, an engineer split across projects, a lab team finishing a late test, or a manager handling routine line duties. If that resource first hears about the chain task when the predecessor finishes, the chain waits while the resource disengages.

The resource buffer is CCPM’s communication mechanism for that handoff. Budd and Cerveny place it in Step 6 of the critical-chain scheduling sequence, after the critical chain has been identified and after the project and feeding buffers are already in place. That order matters. The resource buffer doesn’t find the chain, size a time reserve, or absorb variation. It warns the resource before the chain needs them.

The TOCICO Dictionary defines the resource buffer as a warning mechanism used in single-project environments to make sure resources working on a critical-chain task are available when needed. The same entry gives the useful synonym: resource alert. The plain wording is the point.

What It Is

The resource buffer has four operational properties.

It is a calendar warning, not task time. A resource buffer adds no duration to the project plan. It carries no work package, no deliverable, and no safety time. In the schedule it appears before a critical-chain task or path start, but its purpose is communication: tell the assigned resource to prepare.

Its size is the warning interval the resource needs. Some resources can set down other work in an hour. Others need two days because their line duties are inflexible, their current work has to be handed off cleanly, or the setup for the critical-chain task is real. Budd and Cerveny’s rule is managerial rather than mathematical: set the alert interval from the project manager’s knowledge of the resource and the work. Two resources on the same project won’t necessarily need the same warning time.

It is placed after the project is already protected. Resource buffers are added after the critical chain, project buffer, and feeding buffers are in the plan. They also appear before tasks with no predecessor when the task is a project start or path start that needs active notification. In the Handbook’s sample schedule, some starts receive a separate resource buffer and others don’t because the resource is already instructed to continue directly from one task to the next.

It supports the relay-runner rule. CCPM expects a resource on the chain to work as if passing a baton: finish the current critical-chain task and start the next eligible one without waiting for a date on a Gantt chart. The resource buffer lets that behavior happen without chaos. It gives the resource enough warning to set down non-critical work in an orderly way and be ready when the predecessor finishes.

How It Is Measured or Recognized

You recognize a resource buffer by asking what would happen at the next critical-chain start.

1. Name the next critical-chain task or path start. The resource buffer is tied to a start, not to the whole project.

2. Name the resource that must be ready. The resource may be a person, a team, a machine, a facility, or a scarce skill group.

3. Ask what the resource is likely to be doing before the start. If the answer is “waiting for the chain,” no alert may be needed. If the answer is “working on something else,” the schedule needs an alert.

4. Set the warning interval from real set-down and setup needs. The interval should be long enough for the resource to leave current work without damage and prepare for the chain task.

5. Check whether the alert is still needed after sequencing. If the same resource finishes one critical-chain task and should immediately move to the next, a separate resource buffer may be redundant. If the resource is likely to be pulled into other work between the tasks, it is not.

The diagnostic failure is also simple. If a critical-chain predecessor finishes and the assigned resource is not ready, the schedule is missing a resource buffer or has sized it too small. If the resource was notified and still was not available, the problem has moved from scheduling to subordination: non-critical work was allowed to outrank the chain.

Why It Matters

Resource buffers protect the most fragile part of a critical-chain schedule: the handoff from plan to behavior.

They keep the critical chain from waiting on readiness. Project and feeding buffers absorb time variation after a task runs long. A resource buffer works before the delay appears. It prevents a preventable delay in which the work could start, the predecessor is done, but the assigned resource is still trapped in another commitment.

They make early finishes usable. The TOCICO Dictionary notes that the resource buffer improves the chance of taking advantage of early finishes. That point is easy to miss. If a predecessor finishes early but the next resource isn’t ready until the original scheduled date, the project loses the gain. The alert lets the next resource prepare for a range of start times rather than only the date printed on the baseline.

They reduce bad multitasking without pretending multitasking disappears. CCPM does not assume critical-chain resources have nothing else to do. It assumes the priority rule is clear when chain work arrives. The resource buffer gives enough warning for that rule to be honored without last-minute thrash: finish or pause the non-critical work, make the handoff clean, then take the critical-chain task.

They complete the distinction among the three CCPM buffer types. The project buffer is one time reserve at the end of the chain. Feeding buffers are time reserves at feeder-path merge points. Resource buffers are notifications. Treating all three as interchangeable is one reason critical-chain implementations quietly regress into padded critical-path plans.

For TOCICO certification-track readers in the CCPM domain, the resource buffer is a precision test. A practitioner who calls it a time buffer has missed the mechanism. A practitioner who omits it from a schedule with scarce shared resources has built a plan whose chain starts depend on luck.

Common Misunderstanding

A resource buffer is not extra capacity. Outside CCPM, the phrase may sound like a spare person or a reserve crew. In CCPM it is not capacity. It is a warning signal. If the project needs an extra person, that is an elevation or staffing decision, not a resource buffer.

A resource buffer is not slack. Slack is unused schedule time on a non-critical path. A resource buffer adds no schedule time and carries no task. It tells a resource when to prepare.

A resource buffer is not a substitute for resource leveling. The resource-leveling pass removes planned conflicts before the chain is identified. The resource buffer handles readiness during execution. If the schedule still assigns the same person to overlapping work, a warning will not fix it.

A resource buffer is not always a visible block in software. Budd and Cerveny note that some organizations simply report upcoming critical-chain tasks and path starts instead of drawing explicit resource-buffer objects. That can work if the communication happens at the right time and reaches the resource that must act. The mechanism matters more than the icon.

Complements: Fever Chart — The fever chart reads buffer consumption after variation appears; resource buffers work earlier, before a resource-readiness problem consumes time.

Contrasts with: Feeding Buffer — A feeding buffer is time placed before a non-critical path joins the critical chain; a resource buffer warns a resource before a critical-chain task or path start.

Contrasts with: Project Buffer — The project buffer is a time reserve at the end of the critical chain; a resource buffer is a notification signal and adds no time to the plan.

Implements: Subordination — Resource buffers make subordination practical by telling non-critical work when to yield to the critical chain's next start.

Mitigates: Bad Multitasking — Resource buffers reduce bad multitasking by giving critical-chain resources enough warning to set down other work instead of context-switching at the last moment.

Mitigates: Multi-Tasking Cascade — When many projects compete for the same people, resource buffers help prevent every chain start from becoming another late handoff in the cascade.

Supports: Critical Chain — Resource buffers prepare critical-chain resources to begin the next chain task as soon as its predecessor finishes; the critical chain is the protected structure.

Sources

• Cox, TOCICO Dictionary (2nd ed., 2012), entries “resource buffer,” “resource alert,” “resource contention,” “critical chain,” “project buffer,” and “feeding buffer.” The Dictionary supplies the certification-grade definition and the warning-mechanism boundary this entry cross-checks against. It is distributed through TOCICO membership and doesn’t carry an Open Library record.

• Goldratt, Critical Chain (1997), the originating treatment of CCPM. Introduces the project buffer, feeding buffers, resource buffers, and relay-runner work behavior as a coordinated mechanism for protecting the critical chain.

• Cox and Schleier, Theory of Constraints Handbook (2010), Ch. 3 (Budd and Cerveny, “A Critical Chain Project Management Primer”), the chapter-length operational specification. Places resource buffers in Step 6 of the scheduling sequence, defines them as communication tools with no task time, explains how warning intervals vary by resource, and distinguishes them from project and feeding buffers.