What a recovery plan has to answer
Recovering lost time means shortening the path that drives the milestone: more crews or shifts on production work, resequencing to overlap activities, or removing a constraint. Each option has a limit. Shortening an activity only helps until another path becomes the driver, and work held up by procurement, fabrication, inspections or approvals does not respond to extra labor at all.
So the useful questions are which activities are worth accelerating, by how much, and when the next path takes over. Answering them on the schedule itself, before anyone commits a crew, is what separates a recovery plan from a hopeful one.
How Pathizer tests a recovery assumption
Production Simulator works from the latest analyzed update and a phase you choose. You set a production factor per contractor, from 0.5x to 3x on the slider, or lock a contractor at 1.00x when its scope is fixed. The factors are saved for the project and the contractor, so they carry into the next update instead of being re-entered.
Activities are sorted by whether production can speed them up. Installation, framing, concrete and similar work can be modeled faster; procurement, fabrication, deliveries, submittals, inspections and commissioning cannot, unless you switch on Expedite all. The modeled result is a phase date and the days gained or lost, by contractor.
Critical Path Drag answers the question from the other side. Pathizer reschedules the latest update's own XER, with its calendars, holidays, constraints and scheduling options, once as it stands and once per critical activity with that activity's remaining duration set to zero. Each activity's drag is the calendar days the finish pulls in. With start-to-start or finish-to-finish logic it can be negative: shortening the activity pushes the finish out.
Where the model stops
A scenario models an assumption you supply; it is not a forecast of what crews will achieve. It computes the phase date and the days that move it, not a fresh float calculation for every activity, so per-activity float is shown for the current schedule only and is not invented for the scenario. Edits to remaining durations are what-ifs: nothing is stored, Reset returns the file's own values, and the uploaded XER is never edited.
