A timeline nobody trusts is worse than no timeline at all
Most IT project timelines are built to win approval, not to survive execution. A sponsor asks when the system will be live, a project manager works backward from a date that sounds reasonable, and the plan gets built to justify that date rather than to reflect the actual work. Everyone in the room knows this happens, and it quietly erodes trust in every schedule that follows.
I have sat on both sides of this problem, building timelines as a PMO manager and later having to defend them to steering committees as the person accountable for the technical delivery. A multi-year Oracle Fusion Cloud ERP migration is the clearest example I can point to. The original schedule, built before detailed requirements were finalized, assumed a straight line from design to go live. The schedule that eventually earned the sponsor’s trust looked different, and it moved twice before go live, but it shared a few specific habits that optimistic, approval-driven schedules do not.
1. Build the estimate from the people doing the work, not around them
Estimates handed down from a project manager without input from the engineers and analysts who will actually do the work are consistently optimistic. I ask the people doing each task to provide their own estimate, including their honest account of other commitments competing for their time. The number that comes back is almost always longer than what leadership wants to hear, and that is exactly the information the timeline needs. On the ERP migration, functional leads estimated data conversion testing at nearly double the original plan once they accounted for parallel payroll cycle work, and that number turned out to be close to right.
2. Separate the critical path from everything else
A schedule with forty parallel tasks and no clear sense of which ones actually determine the end date invites false confidence. I identify the true critical path early and track it separately from the rest of the plan. When a non-critical task slips, the project stays on track and nobody needs to panic. When a critical path task slips, everyone needs to know immediately, because the end date has just moved. Data migration and reconciliation sat on the critical path for nearly the entire ERP project, while a dozen cosmetic reporting tweaks did not, and treating them with equal urgency would have wasted attention the team needed elsewhere.
3. Put explicit contingency in the plan, not hidden in the padding
Project managers often pad individual task estimates quietly to protect themselves, which makes the plan dishonest without actually making it safer. I prefer a visible contingency buffer, sized against the project’s specific risk profile, placed openly on the schedule where the sponsor can see it. A visible ten percent buffer that gets used transparently builds far more trust than a hidden thirty percent spread invisibly across every task, because the sponsor can see exactly when and why it was drawn down. On the ERP project, that visible buffer absorbed an unplanned three week extension to user acceptance testing after the first test cycle surfaced more data mapping defects than expected, and because the draw down was logged openly against a named risk, the steering committee treated it as the plan working as intended rather than as a failure to report.
4. Treat dependencies on other teams as risks, not assumptions
A timeline that assumes a security review will take two weeks because that is how long it took last time, without confirming current capacity with the security team, is a guess dressed up as a plan. I confirm every cross-team dependency directly with the team that owns it, and I log any dependency that has not been confirmed as an open risk rather than a settled assumption. On the ERP project, confirming payroll’s testing capacity directly, rather than assuming it from a prior smaller project, surfaced a two week capacity gap months before it would otherwise have been discovered.
5. Report slippage the moment you see it, not at the next scheduled checkpoint
Waiting for the monthly steering committee to report a schedule risk that has been visible for two weeks is how small delays turn into credibility problems. I raise slippage as soon as it is confirmed, with a clear statement of impact and options, rather than waiting for the next scheduled update. Sponsors forgive delays far more easily than they forgive being surprised by one, and on a project with the visibility of an ERP replacement, that difference matters more than the delay itself.
The goal is a timeline people can plan around
None of these habits make a project faster. What they do is produce a date that other parts of the business, payroll, finance, operations, can actually plan around, which is the entire point of a timeline in the first place. A schedule that slips once and recovers credibility through early, honest reporting is far more valuable than one that hits its original date by hiding the real risk until it becomes unavoidable. The ERP go live date moved twice over the life of the project. Trust in the schedule did not, because both moves were flagged weeks before anyone had to ask why.
Leave a Reply