Critical-path scheduling for MSPs
The critical path is the chain of dependent tasks that sets the earliest your project can finish. Here's how it works — forward pass, backward pass, float — and how MSP delivery teams actually put it to use.
What critical path actually means
The critical path is the longest chain of dependent tasks running through your project — and because it's the longest chain, it sets the earliest date the whole project can possibly finish. Every task on that path has zero slack: delay any one of them by a day and the entire project's end date moves by a day. Tasks that sit off the critical path have room to breathe. They can start late, or run long, without pushing the finish out — up to a point. Knowing which tasks are which is the entire value of the method. It tells you, out of forty tasks on a network refresh, exactly which eight you cannot afford to let slip and which thirty-two you can shuffle to free up a technician.
The Critical Path Method (CPM) has been the backbone of formal project scheduling since the late 1950s, and it's baked into the Project Management Institute's guidance. The math is old and settled — what's changed is that a modern engine can run it continuously on live work instead of once at kickoff.
Forward pass, backward pass, and float
Critical path is calculated with two walks over the dependency network. You almost never do this by hand on a real project, but understanding the mechanics is what lets you trust — and question — what the tool tells you.
The forward pass
Working left to right from the project start, you compute each task's Earliest Start (ES) and Earliest Finish (EF = ES + duration). A task can't start until all its predecessors finish, so its ES is the latest EF among everything feeding into it. The forward pass answers 'how soon can each task happen?' and produces the project's earliest possible completion date.
The backward pass
Now work right to left from the project deadline, computing each task's Latest Finish (LF) and Latest Start (LS = LF − duration). A task's LF is the earliest LS among its successors — the last moment it can finish without delaying anything downstream. The backward pass answers 'how late can each task slip before it costs us the deadline?'
Float (also called slack)
Total float is the gap between the two passes: LS − ES (equivalently, LF − EF). It's how long a task can slide without moving the project's end date. Any task with zero total float is, by definition, on the critical path. Free float is a stricter cousin — the delay a task can absorb without pushing the earliest start of even its immediate successor. Watch both: total float protects the deadline, free float protects the next person waiting on the handoff.
- Zero total float → the task is critical; a slip moves go-live.
- Positive total float → the task has a buffer you can spend to relieve a resource crunch.
- Free float < total float → you can delay the task, but not without disturbing the very next task in line.
Why MSP delivery work needs it
MSP projects are dependency chains with hard, physical sequencing. A Microsoft 365 cutover, a server migration, a firewall replacement, a new-client onboarding — none of these are flat lists of parallel to-dos. You can't migrate mailboxes before the tenant is provisioned. You can't configure a switch that hasn't shipped. You can't decommission the old firewall until the new rules are validated. When work is sequenced like that, the finish date is governed by one specific chain, and if you don't know which chain it is, you spend your energy expediting tasks that have float to spare while the real bottleneck quietly slides.
Two realities make this sharper for MSPs than for a generic construction schedule. First, procurement lead times: hardware that ships in three weeks often is the critical path, no matter how fast your engineers are. Second, shared, thin resources: the same senior engineer is on the critical path of three projects and carrying a ticket queue. Critical-path scheduling that's blind to PTO and capacity will hand you a plan that looks fine and can't be executed by a single human. That's why availability has to be a first-class input, not an afterthought.
How to apply it on real projects
The steps below turn the theory into a repeatable delivery habit. The goal isn't a perfect Gantt chart at kickoff — it's knowing, at any moment, which handful of tasks own your date so your attention lands where it changes the outcome.
Where the PSA usually stops
Be clear-eyed about your existing tools. As of 2026, per vendor documentation, Autotask's project task dependencies are finish-to-start only, and native critical-path analysis in the major PSAs typically arrives through an add-on such as Moovila or TopLeft rather than the core module. Moovila, for its part, runs the deepest, most mature critical-path engine in the MSP space — if pure scheduling depth is all you're buying, it's a serious tool. Current's angle is different: a native critical-path engine with cycle detection, PTO-aware scheduling, and a Kanban/Gantt/dependency-map trio, sitting on top of a client portal with database-level financial isolation — running alongside your PSA, which stays the source of truth for billing. The point isn't to replace the scheduler you have; it's to make sure the date you promise your partner is one the dependency network can actually hit.
Step by step
- Step 1Map the real dependencies first
Before durations, list what genuinely can't start until something else finishes: you can't cut over mailboxes before the tenant is provisioned, can't rack the switch before it ships. Draw those finish-to-start edges. Tasks with no true dependency should not be chained just to make the plan look tidy — false dependencies invent a critical path that isn't real.
- Step 2Estimate durations honestly, not optimistically
Critical path is only as good as the durations feeding it. Use working-hour estimates that reflect how the task actually runs, including the procurement and shipping lead times that MSP work lives and dies by. A hardware task's duration is often 'ordered' to 'arrives on the dock', not 'time to rack it'.
- Step 3Let the engine run the forward and backward pass
You do not compute this by hand on a live project. A scheduling engine walks the dependency network to find earliest start/finish and latest start/finish, then flags every zero-float task. Current's native critical-path engine does this on the dependency map, the Gantt/timeline, and what-if scenarios — with client-side cycle detection so a circular dependency can't silently corrupt the schedule.
- Step 4Layer in availability and PTO
A path that ignores who is off is fiction. Feed technician PTO, holidays, and capacity into the schedule so a task on the critical path can't be planned across a week the assigned engineer is out. Current pulls PTO/availability into scheduling and back-scheduling across the timeline, dependency map, and scenarios so all three agree.
- Step 5Protect the critical path, spend the float
Put your best-available people and your management attention on zero-float tasks — those are the only ones where a slip moves the go-live date. Tasks with float are your buffer: you can shuffle them to relieve a resource crunch without touching the finish date, as long as you don't burn more float than they have.
- Step 6Recast whenever reality changes
A shipment slips, a ticket balloons, an engineer calls in sick — the critical path can jump to a different chain of tasks. Re-run the schedule on every material change rather than trusting last week's plan. Use what-if scenarios to test 'if this date moves, what breaks' before you commit to the change.