The Black-Box Schedule Forecast on a Fixed-Date ERP Cutover
Northline Engineering runs a 14-month ERP replacement across five sites, with 340 scheduled activities and nine external contractors. The PMO has licensed an AI schedule-forecasting tool that ingests Primavera P6 history and daily progress updates. At the end of month four the tool flags an 87% probability of a six-week slip on data migration, driven mainly by “integration complexity.” The migration lead, who has delivered three similar cutovers, says the work is on plan and the model is reacting to normal test-cycle variance. The tool is a black box; the vendor provides confidence scores but no feature attribution. Its training corpus was drawn mostly from infrastructure and construction projects, not ERP implementations. A $250,000 milestone penalty applies if cutover slips past 1 October, and the steering committee meets in three days. The PMO director wants the slip added to the baseline immediately; the project manager is not convinced.
1. How should the project manager treat the tool’s 87% slip forecast in the status report and the project baseline?
Read the worked answer
Treat the forecast as a risk signal, not a scheduling fact. The 87% figure is a model output whose training distribution-infrastructure and construction-differs from ERP cutovers, so its calibration on this context is unproven. The PM should not rebaseline on a single opaque prediction, because a baseline is a commitment changed through integrated change control with evidence, not a forecast refreshed whenever a tool emits a number.
In the status report, present three things separately: the committed baseline, the current deterministic forecast from the schedule team, and the model’s scenario as an emerging risk with its assumptions and limitations. Ask the migration lead to document the test-cycle variance the model may be misreading, and ask the vendor for backtesting results on comparable ERP projects. Check schedule quality-critical path, float, dependency logic-rather than debating the number in isolation.
If the steering committee wants financial protection, propose a contingency reserve or a decision trigger-for example, reforecast after two weeks of migration test results-not an immediate baseline slip. Log the model’s recommendation, the human judgement, and the rationale for any override. That preserves an audit trail and counters automation bias without discarding a potentially useful warning.
2. What governance should the PM put in place before the tool is used for future forecasts on this programme?
Read the worked answer
The PM should establish intended use and decision rights first: the tool advises, the schedule owner decides, and no forecast changes the baseline without change control. Then require evidence of fitness: backtesting on ERP and cutover projects, known error rates, calibration by project phase, and a description of input data quality. If the vendor will not provide feature attribution, ask for a surrogate explanation, reference customers, and a documented list of input variables so the team can test sensitivity.
Operationally, assign a named model owner in the PMO, define the review cadence, and keep a log of forecasts, overrides, and outcomes. Set thresholds for when a model alert triggers a human review-not automatic action. Check that progress data fed to the model is complete and timely; a forecast is only as good as its inputs. Train schedulers to challenge outputs and to record dissent.
Finally, add the tool to the programme’s risk and vendor registers, with limitations, dependencies, and exit options. Reassess after a defined period using actual versus predicted slip. This turns an opaque vendor claim into a controlled management aid and gives the steering committee a defensible basis for accepting or rejecting its advice.
3. What should the PM recommend to the steering committee in three days?
Read the worked answer
Recommend a conditional response, not a binary accept-or-reject. Present the model forecast as one input alongside the migration lead’s assessment and the schedule team’s deterministic view. Explain the material limitations: training-data mismatch, lack of explainability, and no local validation. State what would change the decision-for example, independent schedule review findings, two weeks of migration test results, or vendor backtesting evidence.
Propose a short validation window with a named owner and a decision date. Protect the 1 October milestone with a contingency reserve or a pre-agreed trigger for accelerating testing or adding resources, rather than immediately moving the baseline. If the committee prefers to recognise the slip, record it as a management reserve draw or a risk-informed forecast, with the assumptions and the evidence that would justify a formal rebaseline.
Also ask the committee to direct the vendor to provide model documentation and reference cases, and to require future AI forecasts to meet the same evidence standard as any other schedule claim. This gives the committee a decision it can defend, preserves the team’s credibility, and avoids letting an unvalidated model drive a $250,000 commercial outcome.