All posts

What’s next?

Picking the tasks, choosing the route, and finding the one task the project is waiting on.

By Erik Williams | July 20th, 2026

startdone
One chain of tasks sets the finish date.

Chapter 2 of “Is it worth it?”, a working paper on choosing what to spend time on. Chapter 1 scored projects with a value function, V: rewards plus discounted opportunities, minus risks, divided by costs times the years the project has been open. Above 1, fund. Below 1, shelve.

From verdict to schedule

The value function ends with fund or shelve. Execution needs a plan: the tasks, the resources the tasks take, the dependencies between the tasks, and the chain that sets the finish date.

At any moment, one chain of tasks sets your project’s finish date, and an hour spent anywhere else moves the finish date by zero.

What needs to get done?

Walk backward from done, the smallest version of the project that starts paying. What must be true for done to hold? Each requirement is a task.

A task with no line back to done is not part of the project.

What resources do the tasks take?

Independent tasks run in parallel only when the resources exist: a second pair of hands, a second machine, budget for both. With one owner, even independent tasks run in series, and every path runs through you. Add resources and chains that ran in series split into parallel work, which shortens the path and can move the path somewhere else.[4]

The critical path depends on your resources, not only on your tasks.

More than one route reaches the goal

A goal rarely has one task list. A monthly invoice report can arrive through the accounting tool’s built-in report, a paid connector, or a custom script, and each route carries its own costs, waits, and risks.

Comparing routes usually means scheduling each one: sketch the graph, estimate the tasks, and find each route’s critical path, because the finish dates are the comparison. A sketch that eliminates a route is not wasted work. And weigh the blockers: a route with fewer external blockers leaves more of the schedule under your control, which can be worth more than a faster date on paper.

Sometimes you must schedule a route to know whether the route is worth picking.

One chain sets the date

Within the chosen route, tasks depend on tasks, and the longest chain of dependent work is the critical path: the earliest the project can finish.[1] Every other task has float, room to slip without moving the date.[2] The finish date matters because age sits in V’s denominator: costs accumulate until done.

Only hours spent on the path move the finish date.

Request API key0.5 h3-day wait in someone else’s queueTest the invoices2 hSchedule run0.5 hRead the docs1 hWrite the script3 h4 hours of float: the whole build fits inside the three-day waitDesign a logo1 hnothing waits on the logocritical path: sets the finish datefloat: can slip without moving the date
An invented example: an eight-hour invoice automation. Four of the six tasks can slip without moving the finish date. The path runs through a half-hour form, filed early.

The correct first move above is the half-hour key request, because the three-day wait then runs alongside the build instead of after it. You cannot shorten someone else’s queue, but you choose when you enter the queue, so start every task with an external wait first. And a wait is work time: pre-work the next tasks while you wait, so that when the key arrives, only testing remains.

In this graph, the smallest task decides the finish date.

Uncertainty moves the path

Estimates are guesses, so each task finishes somewhere in a range of early and late, and chain lengths are ranges too.[3] Float is the budget that absorbs the misses: a float task that slips past its float lands on the critical path, and the path changes.

overlap: either chain can be criticalChain A: likely 6.5 days, range 5 to 9Chain B: likely 6 days, range 4 to 8345678910days to finish the chain
Numbers invented. Each task finishes early or late with some probability, so chain lengths are ranges. Chain A is likely critical, but run chain B late and chain A early and the path flips.

When two chains overlap in range, either can end up critical.

Treat both as critical, and re-check the path as real durations replace the guesses.

Put the path in the tool

A tracker with blocked-by links already holds the graph. A tool can recompute the critical path on every ticket change and keep one card on every project view naming the single next task.

#12 schema migration#18 data access#27 forecast APIcritical chain#31 chart colors#33 docs page#35 report logofloat: none of these move the dateWHAT’S NEXT#18 data accessRequest read access from ITOn the critical path · blocks 2 ticketsOpen ticket
A mock of a what’s-next card, ticket numbers invented. The tracker’s blocked-by links already form the dependency graph; a tool can recompute the path on every change.

Shorten the path on purpose

Before accepting a finish date, ask what redesign would shorten the path: pay to speed up a path task, add resources so more of the graph runs in parallel, overlap path tasks that were queued out of caution, or cut path scope.[1] Money and effort buy schedule only when spent on the path.

And run one project at a time. For one owner, every path runs through the same bottleneck, you, so serial finishing beats parallel starting, shortest project first.[4][5]

The four planning questions

Planning any project is four questions, asked in order:

  1. What are all the tasks necessary to complete the project?
  2. What resources do the tasks take?
  3. How do the tasks depend on each other?
  4. Once the tasks are sequenced, what is the critical path?

Ideas are infinite, hours are scarce, and every hour now has a project, a route, and a task.

Sources

  1. Critical path method, Wikipedia
  2. Float (project management), Wikipedia
  3. Program evaluation and review technique, Wikipedia
  4. Critical chain project management, Wikipedia
  5. Shortest job next, Wikipedia