Skip to main content
DoneThat

AI Adoption GuideConstructionBuild

Schedule Recovery Scenario Generation

ML generates ranked schedule recovery options, including overtime, resequencing, and additional crews, from current delay and productivity data. (e.g., Alice Technologies)

Construction processBidAwardPlanMobilizeBuildInspectHandoverClose

By Don, DoneThat’s AI coach · updated

Ranked options are a review order, not a recovery programme

A recovery model should return an ordered list of options a planner can still own, not a programme the site is expected to run. Each option needs cites back to the delay and productivity records that exist today: which activities slipped, against which baseline or last accepted update, and which measured production rates support or contradict a proposed catch-up. Ranking means the order in which those options are presented for review. It is not a measured success probability, and it is not a duration the model is entitled to invent.

Construction planning platforms in this class, including Alice Technologies and Autodesk, sit beside the planner. They are not a ranked shortlist of products. Do not assume a capability that is not on the current project licence.

The planner remains the issuer. Until someone with schedule authority edits the option, attaches the same cites the model used, and signs, there is no recovery programme.

Cite delay and productivity before the model runs

Feed the model only what the project already holds as delay and productivity evidence. Typical cites include the current accepted programme, the latest progress update, delay notices or compensation-event records that name slipped activities, and production tracking that shows actual versus planned output for the trades in play. If visual progress is used as a productivity input, keep it as a cite to the monitoring record rather than as a free-text claim. AI visual progress monitoring belongs in this pack only when the date, location, and observed activity are attached to the option the model will rank.

Do the same for materials that sit on the critical path. An ETA that has already been predicted or confirmed belongs as a constraint cite, not as a hope the recovery option can ignore. When the delay is a late delivery rather than a crew-rate problem, pull that cite from critical material delivery ETA prediction and keep the predicted window visible on every overtime, resequence, and crew package that would consume the material.

If a cite is missing, stop. Generating overtime, resequence, or extra-crew options from a gap in the record is how invented durations get into the ranking. The model may interpolate inside a cited rate range the planner already accepted. It may not mint a recovery calendar that no delay notice, update, or production sheet supports.

Overtime, resequence, and additional-crew packages

Ask the model for three families of option, each tied to the same cites.

Overtime packages name the activities, trades, and calendar windows that would take extra hours, and they rest on the productivity records for those trades. They do not assert that extra hours close the delay by a stated number of days unless that closure is already calculable from the cited rates and remaining quantities the planner supplied. Name the calendar exception as a proposal, not as an issued working-time change.

Resequence packages propose a different logic or work-front order, still inside the scope and logic the current programme owns. If the baseline came from CPM schedule generation from scope, the resequence must show which logic ties it is asking to change and which delay cites make that change worth reviewing. It is not a new CPM generated from a blank sheet.

Additional-crew packages name where a second or third crew would start, which work fronts can actually take them, and which productivity cites suggest the current rate is labour-constrained rather than access-constrained. A crew option that requires a work face the lookahead has already flagged as blocked is not a recovery option. It is a conflict the ranking should surface or drop.

Rank the three families together only as a review order: which package the planner should open first, given the cites. Do not convert that order into a probability that the top package will succeed.

Illustrative path: a superstructure planner has a floor-cycle update showing the deck pour slipped against the last accepted programme, and the pour-crew production sheet shows a lower square-metre rate than the rate used in that update. The model returns three packages in review order. First, weekend overtime on the deck crew, using that sheet as the rate cite. Second, a resequence that pulls a non-critical riser activity off the same crane window, citing the logic in the accepted programme. Third, a second deck crew on an adjacent wing, citing both the production sheet and a lookahead that already shows that wing as unconstrained. The planner still has to check access, crane time, and the pour specification. None of the three packages states a recovery duration the record does not already support.

The planner edits, then signs

Open the top-ranked package as a draft, not as the issued recovery. Edit it against live plant, access, permits, inspections, and anything the lookahead constraint scan has already flagged for the same window. If the lookahead named a blocked floor, a missing inspection, or a delivery that has not arrived, that constraint stays visible in the option. Hiding it so the ranking looks clean is a failure, not a cleanup.

Change crew names, calendar exceptions, and logic only with the same authority used for a normal programme update. Attach the delay and productivity cites the model used, plus any cite the planner added during edit. Then sign. Signing is what turns a ranked option into a recovery programme the site can be held to. The unsigned ranking is a review artefact.

If every package fails the lookahead or the cited rates, sign nothing. Ask for a new ranking from corrected cites. Do not fill the gap by typing a duration into the top option so that a steering-group slide has a number.

How a ranking becomes a false programme

Three failure modes show up on live jobs.

Issuing the top option as the recovery programme. Ranking is an order of review. Copying the first package into the issued programme without edit and sign treats the model as the planner. Downstream teams then work to a calendar nobody in project controls accepted, and the delay cites no longer match what the site is actually doing.

Inventing a duration. The model, or the person writing the steering note, states that overtime or extra crews will recover a stated number of days when no remaining-quantity and rate cite supports that number. Once that duration is in the recovery narrative, it is treated as a commitment. Keep recovery language to the options and the cites. If a duration is required for a report, calculate it from the planner-owned quantities and rates, and show the calculation. Do not let the ranking supply it.

Hiding a constraint the lookahead already flagged. A resequence or extra-crew option that needs a floor, a crane slot, or a delivery the lookahead marked as not ready will look attractive in a ranked list because it ignores the block. Reject or rewrite that option with the constraint still attached. If the constraint later clears, re-run the ranking from the new cites. Do not quietly drop the flag so the original top option can be issued.

Keep recovery next to lookahead and the accepted programme

Schedule recovery sits downstream of the accepted programme and upstream of the next lookahead. The CPM that came from scope is the logic the resequence is allowed to argue with. The lookahead is the constraint set overtime and crew packages are not allowed to contradict.

When those records disagree, do not average them in the model. Surface the disagreement in the ranking: this option assumes the production sheet; that option assumes the last accepted update; this third option is blocked until the lookahead constraint clears. The planner chooses which cite to trust, edits, and signs.

The quality outcome is ranked recovery options, each with cites to delay and productivity records the planner still owns, issued only after human edit and sign-off. The model never issues the programme, never invents the duration, and never treats rank as a probability of success.

Is this worth automating for you?

Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other. This one is rated high effort to implement, so the baseline matters more than usual.

DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.

Measure the baseline first