What-if scheduling: testing audit plans before you commit

What is what-if scheduling?

What-if scheduling is scenario testing for the audit programme. You take the current plan as a baseline, make a copy, change one input and re-run the schedule. Then you compare the two plans side by side and decide whether to adopt the change, adjust it or drop it. Nothing reaches an auditor or a client until you commit.

Planners already do this informally. Before accepting a 40-site tender or approving a long leave request, an experienced planner runs through the diary in their head. The limit is scale: a person can test one change against a few weeks and a few auditors. A scenario run tests the change against the whole programme, every audit window and every competence rule at once.

Which questions should audit planners test?

The best scenarios answer questions someone is about to decide. These come up in most certification and inspection bodies.

What if a lead auditor leaves or goes on long leave?

Remove their availability from the leave date and re-run. The result shows which audits move, which fall outside their window and which codes have no cover left. It also tells you whether to recruit, qualify a colleague or subcontract. See auditor capacity planning.

What if we win a large new client?

Add the tender's sites, standards and audit time as demand and re-run. You see whether the work fits your own team, which months overflow and how much would go to subcontractors, before the price is fixed.

What if we allow remote surveillance for low-risk clients?

Mark eligible audits as remote-capable under your IAF MD 4 procedure and compare travel, utilisation and the number of audits placed. See remote audits under IAF MD 4.

What if we cut subcontracting by a quarter?

Cap subcontracted days and re-run. The result shows whether internal capacity and competence can absorb the work, or which codes block it.

How does a what-if scheduling cycle work?

Every scenario follows the same loop. The discipline that matters most is changing one thing at a time, so you can explain the result to a director who asks why the numbers moved.

When a scenario is adopted, it becomes the new baseline. Keep the old one, with a note of what changed and why, so you can show later how a decision was reached.

How to run a what-if scenario step by step

The steps below assume a tool that can copy a plan and re-run it. The same logic works on a spreadsheet, only much more slowly.

1. Fix the baselineSnapshot the current plan, availability and demand. Note the date so the scenario is comparable.
2. Pin what must not moveLock audits already confirmed with clients, witnessed audits booked with the accreditation body and unannounced visits inside their window.
3. Write the questionOne sentence, for example: can we absorb 40 new sites from March without extra subcontracting?
4. Change one inputAdd the demand, remove the auditor or change the rule. Leave everything else as it was.
5. Re-run and compareUse the same engine settings. Compare the agreed numbers with the baseline.
6. Check the exceptionsRead the audits that could not be placed. They usually point to one competence gap or one busy month.
7. Decide and recordAdopt, adjust or drop. Record the reason with the scenario.

Why does a deterministic engine matter for what-if scheduling?

A scenario comparison only works if the engine gives the same answer to the same data. If a re-run of the unchanged baseline produces a different plan, you cannot tell whether a difference in the scenario came from your change or from chance. Deterministic optimisation removes that doubt, and makes every allocation explainable. See constraint-based scheduling explained and explainable AI scheduling.

Which numbers should you compare between scenarios?

Pick a short list and use it for every scenario, so directors learn to read the comparison. These are the numbers most planning teams need:

• Audits placed inside their audit window, and audits left unallocated.
• Internal utilisation, on your own definition (see auditor utilisation rate).
• Subcontracted days and the codes that caused them.
• Travel distance or time, and nights away.
• Competence gaps: audits with no qualified auditor available.
• Disruption: how many client-confirmed dates would change.

Disruption is the number most often left out. A scenario that saves travel but moves 200 confirmed dates will cost more in client goodwill and admin than it saves. For wider KPI definitions, see certification body KPIs.

How fast does what-if scheduling need to be?

Scenario testing is only practical when a full re-plan is quick. If a plan takes a month to build, nobody builds a second one to test a tender. When it takes minutes, a planner can test five options in an afternoon and bring the comparison to the management meeting. These results from ScheduleAI customers show the run times involved:

Speed changes the kind of question you can ask. Instead of whether a plan works, you can ask which of four plans works best, and show the reasons.

What goes wrong with what-if scheduling?

Most failures come from the set-up. Changing several inputs at once makes the result impossible to explain. Forgetting to pin confirmed bookings produces a beautiful plan that moves half your clients. Running scenarios on stale availability tests a team that no longer exists. And scenarios that never get a decision become clutter: close each one as adopted or dropped.

Keep planners in charge of the outcome. A scenario is evidence for a decision, and the planner or operations director still makes it. When a scenario is adopted, AI agents can handle the client date requests and reminders that follow, with planners approving each change.

See how ScheduleAI's audit scheduling software applies these rules across a whole programme in minutes.