Anonymised, illustrative composite. Two adjacent building phases on one Alberta site shared a single tower crane. The master schedule, imported from Primavera P6, never flagged that both phases needed it the same week — because that level of detail was never in the master schedule to begin with.
At a glance
Sharing one tower crane across two phases on the same site is a routine cost-saving move, and it works fine as long as each phase’s crane-dependent activities land in different weeks. The two phases’ schedules had been built and imported separately, then merged at the master-schedule level — at which point each phase’s structural steel and panel lifts appeared as multi-week activity bars, without the day-by-day detail that would show whether any two of those bars actually competed for the same crane on the same day.
Each phase’s own project manager was confident in their own sequence — and each was right, in isolation. Phase A’s steel package was scheduled sensibly against Phase A’s own trades. Phase B’s panel lift was scheduled sensibly against Phase B’s own trades. Neither project manager had a reason to check the other phase’s week-by-week crane demand, because the master schedule they each worked from did not carry that level of cross-phase detail to check against.
Procore’s Schedule tool does not build or re-optimize a construction schedule — it states plainly that it lets a team “import existing schedules created in Microsoft Project, Primavera P6, and the MPX file format.” The master schedule on this job was exactly that: an imported plan, carried at the level of detail it was built at in P6, which was activity-by-activity, not lift-by-lift. Nothing at that resolution was ever going to surface a same-week resource clash between two phases’ crane use, because the master schedule was never asked that question.
The project’s weekly three-week lookahead — a separate, shorter-horizon planning session run against the imported baseline, not a report the software generated on its own — broke both phases’ activities down to specific lifts, day by day, three weeks ahead of execution. That review surfaced the conflict: Phase A’s structural steel lift and Phase B’s panel lift were both scheduled for the same week, and the site had one crane. A second crane, rented for the week plus mobilization and demobilization, was quoted at roughly $9,800 for the week and $6,000 to bring on and off site — about $15,800 in avoidable cost.
Instead, the team pulled a non-critical Phase B prep activity forward by one week. That string of Phase B activities carried 6 days of float, more than enough to absorb a one-week pull-forward without putting anything on Phase B’s own critical path. The crane conflict cleared itself, at a cost of roughly half a day of coordination.
Because the imported master schedule was never built to carry lift-by-lift, day-by-day resource detail — and the software importing it does not add that detail or re-optimize around it — a same-week crane clash between two phases was never going to show up automatically. That level of detail only exists in a shorter-horizon lookahead, run by a person, on a recurring cadence, specifically because the baseline schedule was never going to produce it on its own. The lookahead is not a summary of the master schedule; it is the only place this kind of conflict is visible at all.
Alberta’s Occupational Health and Safety Code does regulate cranes sharing a site — s. 107 requires operators of two or more tower cranes with overlapping operating radii to keep a working means of communicating with each other and avoid collisions — but it says nothing about scheduling a single shared crane’s competing weekly demands across two phases. That gap is exactly why a lookahead review, not the safety code, is what catches a same-week resource clash.
No crane was rented, and neither phase lost schedule time. The weekly three-week lookahead review is now a mandatory Friday agenda item on every job sharing equipment across concurrent phases. See what a three-week lookahead actually is and how a schedule baseline is set and revised. For a related documentation change on the same kind of job, see how one GC cut its RFI turnaround time.
A 30-minute call is enough to tell you whether AI pays for itself here.
