Critical path for small teams
The critical path method was built for construction schedules with thousands of tasks. This paper argues it is more useful, not less, on a twenty-task plan, and shows how to read it without a scheduling degree.
Abstract. Small teams avoid dependencies and critical paths because the tools that offer them are built for large programs. Stripped to its essentials, the method is three questions a team already asks, and answering them on a small plan takes minutes. This paper explains the four dependency types, lag, slack and the critical path in plain language, shows what baselines add, and connects the schedule to capacity so the path is realistic.
1. Three questions
Every team planning a launch asks the same three questions, usually in a meeting and usually from memory.
What has to happen before what? Which of those chains decides the finish date? If something slips, does it matter?
The critical path method is nothing more than a way of writing down the answers so that the plan can answer them for you after the meeting ends.
2. Dependencies, in plain words
A dependency says one task waits for another. There are four kinds, and most plans use one of them almost exclusively.
Finish-to-Start is the ordinary one: design finishes, then build starts. Start-to-Start says two tasks begin together, such as writing and illustration on the same chapter. Finish-to-Finish says they end together, such as testing and documentation for a release. Start-to-Finish is rare and says a task cannot finish until another starts, as when a night shift cannot end until the day shift arrives.
A lag is a gap: build starts two days after design finishes, because the files need to be handed over. A negative lag is an overlap.
Write these down and the plan knows when every task can start at the earliest.
3. Slack and the path
Each task now has an earliest start, from its predecessors, and a latest start, working backward from the finish date without delaying anything. The difference is its slack: how far it can slip before it moves the end.
Tasks with zero slack form the critical path. A day lost on any of them is a day lost on the project. Tasks with slack can absorb a slip. That is the whole method, and it answers the third question for every task at once.
On a two-hundred-task program the path is a thing you compute. On a twenty-task plan it is a thing you can see, once it is drawn, and seeing it changes what the team does on Monday.
4. What small teams get wrong
Dating everything by hand. When every task has typed-in dates and no dependencies, a slip has to be propagated by hand, and it is not. The plan silently becomes fiction. With dependencies, moving one bar moves its dependents.
Treating every task as critical. Without slack, every slip looks like a crisis. With slack visible, most slips are nothing, and the team's attention goes to the few that are.
Never recording the original plan. A plan that only shows the current state cannot show how it got there. A baseline is a named snapshot of the schedule; drawn under the live bars, it shows which tasks slipped, by how much, and whether the slip came from the critical path.
5. The path is only as true as the people
A chain of tasks can be feasible on the chart and impossible in the calendar, because the same person is on three of them in the same week. The schedule needs capacity beside it: each person's open tasks per week against what they can carry. A critical path through an overloaded week is a path that will slip. Rebalancing before the week arrives, by reassigning or pushing a task, is what keeps the path honest.
6. In Kyndium
Kyndium's Timeline supports the four dependency types with lag, computes slack and highlights the critical path with one toggle, draws baselines under the live bars, and sits beside a Workload view that counts each person's week against their capacity. Dependencies are added in plain language ("starts after it finishes"), and dragging a bar moves what depends on it. None of this requires a scheduling specialist; it requires writing down what the team already knows.
Comments