Construction Schedule Delay Analysis: I Tested Every Task

Construction schedule delay analysis almost always starts from the same document: the float table. Which activities had slack, how much, and therefore who owes whom the days. It is the number that decides whether a delay was excusable, concurrent, or somebody’s fault, and it is on the front page of every claim I have ever read.

So I tested it. I took a 21-task renovation with three general crew, delayed every single task a day at a time, and re-solved the whole schedule after each one to see when the finish date actually moved. Twenty-one tasks, a few hundred solves. Three of them turned out to have nine days of float on paper and no tolerance at all.

Paired bar chart of twelve renovation tasks comparing total float with the delay each can actually absorb; roofing, driveway and landscaping each show nine days of float and zero days of tolerance.
Every task was delayed a day at a time and the whole plan re-solved. Grey is what the float table promised; blue is what survived contact with three crew.
Continue reading “Construction Schedule Delay Analysis: I Tested Every Task”

Resource Leveling Techniques, and Why Yours Guesses

Search for resource leveling techniques and you get lists: level within float, delay non-critical tasks, split tasks, reassign resources, adjust the calendar, fast track, add people. All real things you can do. None of them is what the button in your scheduling software is actually doing when you press it, and the gap between the list and the button is why two tools level the same plan and hand you two different schedules.

Underneath, there is one technique with two moving parts, and a lot of arbitrary choice in the second part. Here is what it did to a 21-task renovation.

Horizontal bar chart of the eleven tasks leveling pushed later, from Driveway and Landscaping at 14 working days down to six tasks at 3 days each.
Five of the eleven tasks that moved had no CPM float at all. A technique that only shifts slack tasks cannot produce this schedule.

Continue reading “Resource Leveling Techniques, and Why Yours Guesses”

Resource Loading: The Chart Under the Gantt Chart

A resource loading chart is the histogram that sits under a Gantt chart: for each day of the plan, how many people that day needs. It is the least glamorous drawing in project management and the only one that ever told me anything I did not already know from looking at the bars.

Here is one for a 21-task house renovation, before and after the schedule was made to fit inside the crew that actually exists. The two panels hold exactly the same amount of work.

Two resource loading charts of the same renovation: before leveling the daily crew count peaks at 5 and exceeds the cap of 3 on 14 days; after leveling it never exceeds 3.
Same 155 crew-days under both panels. Leveling changes the shape of the histogram, not its area.
Continue reading “Resource Loading: The Chart Under the Gantt Chart”

Resource Leveling vs Resource Smoothing, Measured

Resource leveling vs resource smoothing is usually taught as a pair of definitions to memorise for an exam: leveling may push the finish date out, smoothing may not. Both true, both useless the moment you are standing in front of a schedule that needs fixing, because neither tells you which one your plan can actually give you.

They are not two techniques. They are one trade-off, read from opposite ends. I solved the same 21-task renovation both ways and the two answers landed on exactly the same curve.

Line chart: with 3 general crew the renovation finishes 2 December, with 4 it finishes 30 November, and with 5 or more it finishes 25 November.
Resource leveling picks the left end and lets the date move. Resource smoothing wants the right end — and on this plan that means five people, not three.

Continue reading “Resource Leveling vs Resource Smoothing, Measured”

Fast Tracking vs Crashing: I Measured Both

Every project management course teaches fast tracking vs crashing in the same order and with the same moral: if the date is at risk, fast track first, because overlapping tasks costs nothing but risk, and crash second, because crashing costs money. I have repeated that advice myself. Then I put both through a solver on the same plan and got the opposite of what the order implies.

Fast tracking pulled eight working days off the schedule and one day off the job. Crashing pulled six off the schedule and eleven off the job. Same 21-task renovation, same solver, same afternoon.

Grouped bar chart: fast tracking pulls 8 working days off the finish with unlimited crew but only 1 with the real crew, while crashing pulls 6 on paper and 11 in reality.
Fast tracking wins on paper and loses on site. Crashing is the only one of the two that gains more in reality than it does on the network.
Continue reading “Fast Tracking vs Crashing: I Measured Both”