Pocket PMO
Sign In
Back to blog

Auto-scheduling project plans: replanning without starting again

August 19, 2026
Auto-scheduling project plans: replanning without starting again

Every plan survives until the first change. A task takes nine days instead of four, a supplier confirms two weeks late, a resource is pulled onto something more urgent. The delivery impact is usually small. The administrative impact is enormous, because most people respond by rebuilding the plan by hand.

Auto-scheduling exists to remove that rebuild. Done properly it is not a black box that silently rewrites your dates. It is a calculation you are asked to approve.

Table of contents

What auto-scheduling actually does

Auto-scheduling takes three inputs: the current plan, the change you have just made, and the dependency network between tasks. It then produces a proposed new set of dates, together with a clear statement of what moved and why.

The value is not the arithmetic. Anyone can add five days to a date. The value is in the network effect: knowing which of the forty downstream items genuinely need to move, which have float and can absorb the slip, and which milestones are now at risk. That is where manual replanning goes wrong, because people move the obvious successors and miss the milestone three levels down.

Ripple rescheduling explained

A ripple reschedule walks forward through the dependency chain from the task you changed:

  1. The changed task gets its new duration or dates.
  2. Each direct successor is shifted only as far as its dependency requires.
  3. Where a successor has float, the float absorbs the shift and the ripple stops there.
  4. Milestones are recalculated last, so you can see the true end-date impact.
  5. Nothing behind today's date is moved, because history is not negotiable.

The important design decision is that the ripple is minimal. A naive implementation shifts everything downstream by the same number of days, which destroys any slack you had deliberately built in and makes the plan look far worse than reality.

Parallel or sequential? The question most tools never ask

The biggest source of false slippage is assuming work must be sequential. When you add a task, the honest question is: can this run alongside what is already scheduled, or does it genuinely have to wait?

Three tests decide it:

  • Resource — is the same person or role needed on both at once? If yes, it is sequential unless you add capacity.
  • Input — does this task need an output the other task produces? If yes, it is sequential.
  • Risk — would running them together create rework if the first changes direction? If yes, treat it as sequential even when the mechanics allow parallel.

If none of those apply, the task should run in parallel and your end date does not move at all. Being asked this question at the point of entry is worth more than any amount of clever maths afterwards.

Dependency detection

Most plans are under-linked. People type tasks in as a list, the order looks sensible on screen, and nothing is formally connected. The plan then looks stable while being completely unresponsive to change.

AI dependency detection reads the task names, owners and stage context and proposes the links a reasonable planner would draw: testing after build, training after configuration, go-live after cutover rehearsal. You accept or reject each suggestion. Once the links exist, every future change costs you a review instead of a rebuild.

Replanning after a real slip

Sometimes the ripple result is not acceptable. The milestone is contractual, or the end date is fixed by a regulatory deadline. At that point the useful thing is not a new date, it is a set of options:

  • Compress — shorten downstream durations where extra resource genuinely buys speed.
  • Parallelise — break a sequential link that only exists out of habit.
  • Descope — move the lowest-value scope out of this phase and into the next.
  • Accept — take the new date, and put the reasoning on the record.

Every one of those has a cost, and the sponsor should be choosing between costs rather than being handed a single revised Gantt chart. Presenting the options is the professional act. See project phases for how to handle the descope route cleanly.

Keeping humans in control

Auto-scheduling should be approval-first, without exception:

  • Nothing is applied until you approve it.
  • The proposal shows a before-and-after for every affected item.
  • The change is written to the audit trail with who approved it and when.
  • You can reject the proposal and keep your own dates.

A scheduler that silently rewrites your plan destroys trust the first time it gets one item wrong, and you will spend more time checking it than you ever saved.

A worked example

A plan has forty tasks and four milestones. Requirements sign-off slips by six days.

  • Manual approach: two hours moving dates, one missed dependency, a milestone that quietly stays wrong until someone notices in a steering meeting.
  • Ripple approach: eleven tasks move, nineteen absorb the slip in float, two milestones move by four days and one by nothing. You review, you approve, and you spend the remaining ninety-five minutes talking to the people who can pull the four days back.

That is the whole argument for auto-scheduling: it converts a data-entry exercise into a decision.

Related reading

Frequently asked questions

Does auto-scheduling change my plan without asking?

It should never do so. A well-designed scheduler proposes the new dates, shows exactly what moves, and waits for your approval before anything is written.

What happens to tasks that already have float?

Float is used first. A minimal ripple only shifts a successor as far as its dependency requires, so slack absorbs small slips instead of pushing the end date out.

Do I need a fully linked plan for this to work?

You need the dependencies that matter. Dependency detection can propose the obvious links from your task names and stages, and you approve the ones that are real.

Can it help me decide whether work can run in parallel?

Yes. The useful check is resource, input and rework risk. Where none of those force a sequence, the task can run alongside existing work and your end date is unaffected.