Progress is not planning

This piece started as a coffee-break argument. A colleague asked how a project that reported progress every single month still lost its finish date. The dashboards were green. The S-curve climbed. The end date slipped anyway, quarter after quarter, and leadership could not see where the months went. My answer took the whole coffee: the teams were managing progress. Nobody was managing the plan. Those sound like the same job. They are different jobs, and the gap between them is worth real months on real projects.

01The wall of bars

Say the word planning in a project review and people picture a document: hundreds of pages of Gantt bars printed to PDF, one row per activity, thousands of rows nobody reads. Managers receive it, weigh it, and file it. It speaks to no one, so planning gets the reputation of a paperwork ritual instead of a decision tool.

That wall of bars is not the plan. A plan is a network: activities tied to each other by dependencies, the way PERT and the critical path method drew it in 1958. Work flows through that network along paths. Some paths are short and simple. One is long, complicated, and needs preparation at every step. The bars are only a projection of the network onto a calendar, and they hide exactly the thing that matters: which chain of work decides the end date.

02Sixty seconds of PERT

Before the argument, the instrument. A plan is drawn as a precedence network: every activity is a box, every arrow a rule that says this cannot start before that finishes. From start to finish the network offers several routes of distinct, linked tasks. Reading it, the part that fills training manuals, is four moves. Walk forward to find the earliest date each activity can start, given the arrows arriving into it. Walk backward from the end to find the latest date each can run without moving the finish. Subtract the two: the difference is the activity's float. One unbroken chain comes out with zero float on every step. That chain is the critical path: the project cannot end before it does, and every week it slips, the project slips.

03Two jobs with the same name

On the project from that coffee break, the teams worked hard and reported honestly. What they practiced was progress management: collect what was earned this period, weight it by manhours, sum it, plot the S-curve, explain the variance. Useful, necessary, and entirely backward-looking. It counts what the project ate.

Planning is the other job. It looks forward along the network and asks which chain of activities has no slack left, what has to be protected this month so the end date survives, and where a delay would propagate. Progress management adds up the past; planning defends the future. Leadership on that project received the first every month and assumed it contained the second. It did not.

04La recherche de facilités

Weighted progress turns a project into a market. Every activity carries manhours; every hour earned is a tick on the curve; the monthly review prices the team on that tick. And in this market the paths of the network do not pay equally. Closing two short paths costs a few mobilizations and buys the same percent as grinding through one stage of the long path, which needs engineering complete, materials on site, permits, access, and three trades in sequence. A rational team under monthly reporting pressure goes where the percent is cheap. In our coffee break we called it la recherche de facilités, hunting the easy wins.

The network is indifferent to all of it. The short paths carry float: they can finish weeks late and change nothing. The long path carries none. So every crew, every meeting hour, every kilogram of management attention spent buying cheap percent on a floating path is capacity the zero-float path did not get. The easy paths eat your resources, your energy, and your agenda, in detriment of the one line that decides when the project ends. Percent arrives, time does not.

05The race: percent against path

Run the theory. Below are two identical projects: same 40 activities, same network, same total manhours, four crews each, same productivity. One rule differs, the dispatch decision every project makes each Monday morning: which available work do we staff?

Team Percent staffs whatever earns the most progress per day, the exact behaviour a monthly percent review rewards. Team Path staffs zero-float work first and lets the floating paths wait, which is what float is for. Both teams are rational. They optimize different numbers. Press play.

The shape deserves a second look. The curves cross long before anyone would react: Team Percent holds the better reported number through the early reviews, which is exactly long enough to make the outcome irreversible, because by the time the plateau is visible the easy work is spent and only the unprepared long path remains. If your monthly review rewards reported percent, it rewards the losing strategy at every meeting where the strategy could still be changed.

06Why the plateau is physics, not laziness

Every planner knows the curve that reaches 95 percent and then lives there for months. It is tempting to read it as bad reporting or bad faith. Mostly it is neither: it is the arithmetic of greedy dispatch, and it has a literature.

Ford and Sterman called it the 90 percent syndrome: development projects routinely report ninety percent complete for the second half of their actual duration, because the deferred, interdependent, hard-to-prepare work concentrates in the tail. The simulation above reproduces it with nothing but a dispatch rule. Goldratt's Critical Chain adds the resource side: the constraint resource wanders off to whatever looks urgent or easy, and the longest chain starves quietly. And the tail has one more trap waiting, the one commissioning managers meet on day one: parallel paths do not average out, they multiply.

07Feed the plan, or feed the fronts

The race hid one assumption: crews switch tasks freely and cost nothing. Real projects mobilize people, equipment, and a supply chain, and every site answers a doctrine question, usually by default: where do those feeds point? Spread them across every open front and every front shows progress at the next review. Concentrate them on the zero-float chain and the floating fronts go quiet while the project gets shorter. This is not a matter of taste with two defensible sides. Scheduling under limited resources is a formal problem, the resource-constrained project scheduling problem, proved NP-hard, which is why real sites run on priority rules. Those rules have been raced against each other in the literature for fifty years, and the minimum-slack rule, always staff the work with the least float, sits among the most robust simple rules ever benchmarked. The instinct to protect the critical path is not a preference; it has a test record.

Made explicit, the doctrine is mobilization by float band. The zero-float chain is staffed and supplied first, at full need: crews, materials, engineering answers, management attention, all of it. When that chain cannot absorb more, the next float band gets fed. The high-float fronts wait their turn, which is exactly what their float exists to pay for. The same discipline binds the supply chain: expedite the shipment feeding the critical chain, and let the floating front wait for the next vessel. A warehouse and a staffing plan that serve all fronts first-come-first-served are percent machines.

Every project manager hears the same objection: hold crews back and contractors file standby claims. True. Pay them. A standby claim is a visible, negotiable, crew-sized cost. A day of project delay carries the whole project's daily burn, its financing, its liquidated damages, its lost production, and it appears on no monthly report as a line anyone signs. Goldratt compressed the principle into one sentence: an hour lost at the constraint is an hour lost for the whole system, and an hour saved anywhere else is a mirage. Reinertsen documented the failure mode that follows from not knowing this: organizations that never compute their cost of delay systematically over-weight the local, visible cost. Put your own numbers in.

08What to watch instead

None of this argues against measuring progress. It argues against steering by it. Four changes move a project from progress management to planning, and none of them needs new software.

1. Report progress by path, not by total. One line for the longest path with its own percent, next to the overall percent. The gap between the two numbers is your self-deception index: overall 82, critical path 41 is a different project from overall 82, critical path 80.
2. Staff and supply by float band, zero first. Float is the network's written permission to wait; spend it deliberately. Crews, materials, engineering answers, meetings: the zero-float chain feeds first at full need, the next band after, the easy fronts last. Accept the standby claims that discipline produces; they are priced in crew-days while delay is priced in project-days.
3. Measure the finish, not the percent. The monthly question is "did the forecast finish date move, and which activities moved it", which is what earned schedule was invented to ask. A month where percent rises and the finish date does not improve was a month spent buying percent.
4. Give leadership the network, on one page. The longest path as a single line of a dozen bars, the merge points where paths converge, and nothing else. That page speaks. The 214-page wall never did.

The coffee-break version fits in two sentences. Progress tells you what the project ate; the network tells you when it will be done. Manage the second, and the first takes care of itself.