Advanced Critical Chain · Lesson 6 of 8

Planning without task deadlines

Task deadlines clash with sequential priority, and padded estimates are wasted by student syndrome. Plan with touch times, pool the safety into one buffer, and steer by the trend of the project’s ETA.

22 min · Not completed yet

Do you really believe in sequential priority?

An execution team is running late on an intermediate deadline of a project. Is that task urgent? Surely.

Now suppose that project is priority number 3. The same team also has a task on priority number 1. Which should they take up?

See the conflict. Missing a project’s key deadlines isn’t good. But task estimates in projects can go wrong, so a shared team can easily be late on several projects at once. If task deadlines act as a priority system, priorities clash, and bad multitasking creeps back in. If we accept sequential priority and WIP control, we have to give up task-level deadlines, or scheduling as it’s usually called.

But then, how does anyone see where the whole project stands?

Why conventional planning breaks the flow

The conventional answer is a project plan with intermediate deadlines, commitments against them, and variance tracking. Do that, and deadline-based priorities conflict with the common priority sequence, the flow culture is lost, and the benefits of WIP control are diluted. The challenge is to create visibility without the negative effects of deadlines.

Behind the conventional plan sits an assumption: for a project to finish on time, every task must finish on time. That creates the need for accurate task estimates, and for deadlines to hold people to them.

Counts and estimates

Walk into a conference room and count the people: you’ll get an accurate number. Now estimate their average age without asking anyone’s date of birth: you’ll give an estimate. Counts can be accurate; estimates, by definition, can’t. Yet project management keeps asking for accurate estimates. The trouble starts when estimates are turned into commitments.

Watch what happens. A design head asks an experienced designer how long a task will take. First comes silence: the designer is working out what number the boss won’t cut. Pressed, the designer describes all the task’s complexities, building a case. Finally: “Sir, it will take minimum so many days.” The word minimum is deliberate. The more uncertain the work, the more buffer goes into the estimate. Under commitment, safety comes as a free gift.

Student syndrome: why hidden safety doesn’t protect

Remember a professor announcing an exam for tomorrow? “No, sir, not enough time!” After negotiation, the exam is set for a week later. How many students start studying that day? Almost none. Most start a day or two before. Then they find the notes are incomplete, the friend who has them is away, and when the notes finally arrive the photocopy shop is closed. They blame the world.

Effort over that week looks like a small blip at the start, sizing up how long they can wait, then nothing, then a huge spike just before the exam. And when does Murphy, the name of uncertainty, strike? Once the task has started, when it’s too late to absorb it.

This is student syndrome, and it isn’t limited to students. The safety exists, but it is wasted, and then every bit of variability causes delay, so we conclude the problem is variability. Add the escalation and collaboration conflicts, and task-level safety protects almost nothing.

Pool the safety

So safety exists in every task: each task may run beyond its touch time, but nobody knows which, or by how much. Some won’t run over at all. Pool the extra time into one place, where it protects the whole project instead of being wasted task by task.

The rule used in practice:

  • Plan each chain with task touch times.
  • Add half of the touch time of the longest chain as a project buffer at its end. Shorter chains get their own buffers where they join.
  • The due date is at the end of the project buffer on the longest chain.

At any point during execution, the project’s ETA (estimated time of arrival) is: today + remaining touch time on the longest chain + half the touch time as buffer. It is still an estimate, and it moves within a range: a month either way may be fine on a two-year project, 15 days on a six-month one, depending on what the customer can tolerate.

Control: when to intervene, and when not to

With task deadlines gone, project managers ask: how do I keep control? Control means knowing when to intervene, and, even more, when not to.

Plot the trend of the ETA. Each day, record the project’s ETA. Divide the project buffer into three equal zones, green, yellow and red, and read the trend:

Trend Meaning Action
Steady in green Running early, and stable No top-management intervention needed
Steady in yellow On time, within customer tolerance Stable; leave it
Steady in red Late, but the delay isn’t growing Look at whether recovery is possible
Climbing steeply Delay is spiralling: out of control Top management steps in to find the cause

A rising line is great news on a sales chart and alarming on an ETA chart.

Watch for stagnation. The biggest wastage in any project is a period with no progress. Progress on feeder paths while the longest path barely moves isn’t real progress, because the longest path controls the lead time. So the measure is % completion along the longest path over time. Flat periods are stagnation. If stagnation exceeds, say, 5% of a project’s time, find out why: those are the intervention points.

See the whole programme. Put every project’s position on one portfolio chart; review the red ones for recovery. Two warnings: red doesn’t override the sequential priority, and before rescuing one project, check whether work is piling up at one work centre. If it is, the problem is systemic.

Finally, management can estimate an ETA for the programme: from the current rate at which projects complete and each waiting project’s place in the queue, work out when it will enter WIP and when it will be done. As flow stabilises, that programme ETA becomes reliable.

Check your understanding

Answer all five. Get four right to complete the lesson.

1. Why are task-level deadlines incompatible with sequential priority?

  • They are too long
  • Nobody reads them
  • A late task on a low-priority project competes with high-priority work, so priorities clash and multitasking returns
  • They are illegal

Deadlines become a second, conflicting priority system.

2. The designer says “minimum so many days” in order to…

  • Build a buffer into the estimate that the boss won’t cut
  • Finish early
  • Impress the boss
  • Avoid the task

Under commitment, safety is added as a free gift.

3. Student syndrome means hidden safety is…

  • Used to finish early
  • Returned to the project
  • Too small
  • Wasted by starting late, so Murphy strikes when there’s no time left

The safety exists but is consumed before the work starts.

4. A project’s ETA is…

  • The sum of all task deadlines
  • Today + remaining touch time on the longest chain + half the touch time as buffer
  • The customer’s requested date
  • Last month’s finish date

It updates daily and moves within a range.

5. The measure of a project’s stagnation is…

  • Money spent
  • Progress on feeder paths
  • Flat periods in % completion along the longest path
  • Number of meetings

The longest path controls the lead time.