10 What-If Analysis Mistakes That Produce Confident Wrong Answers

What if analysis mistakes all share one property: the software did exactly what it was told, and the answer was still wrong. These ten come up repeatedly when planners use scenarios in EDGEBIC by User Solutions, each with the symptom that gives it away.

For the module, start with what-if scenarios explained. For the hands-on build, see how to build and compare scenarios, and for the boundaries, what a scenario can and cannot change.

1. Comparing Without a Baseline

Symptom. Every comparison proves that the alternative is better, and nobody can say by how much compared with doing nothing.

Cause. No Standard scenario. The charts line up two or three alternatives against each other, with the do-nothing case missing entirely.

Fix. Always create a no-override scenario named Standard and run it first. It does two jobs: it gives the comparison a floor, and it documents what the standard case looked like on the day the decision was made. In the documented case, the baseline is what turned "the second shift is faster" into "the second shift costs $600 more and saves nine days".

2. Stacking Levers Into One Scenario

Symptom. A scenario hits the date, and the shop ends up arranging overtime, a weekend, and a vendor because nobody knows which one mattered.

Cause. One scenario carrying three changes. The result is a single date and a single cost with no way to decompose either.

Fix. One lever per scenario. It costs two minutes and it is the entire point of isolating variables. In the documented comparison, separate scenarios showed the second shift landing August 5 at $9,830 and the weekend push landing August 8 at $9,590, which is what let the planner spend $240 to buy three days of protection.

3. Applying a Scenario and Never Making It Real

Symptom. The customer accepted the vendor scenario, the quote carried its dates, and the production run used the old routing.

Cause. Applying a scenario copies results onto the quote: estimated dates, hours, and costs. It does not change the product's routing, any work center, or the schedule, because the scenario's changes lived in a cloned copy of the routing that is discarded after the run.

Fix. Build the follow-through into the process: apply the scenario, make the real change, then convert. The real change means arranging the actual shift, adding a real per-day capacity override on the work center, or editing the routing in the designer. A scenario is a proposal; a commitment needs the world to change too.

4. Reading Lead Time and Ignoring Utilization

Symptom. The winning scenario's date slips on the first breakdown, and there was never any slack to absorb it.

Cause. The comparison presents lead time, cost, and utilization as three separate charts, and planners read the first one. A scenario that wins by two days while running a machine at full stretch for three weeks has no resilience at all.

Fix. Read all three before choosing. The utilization chart exists exactly for this decision, and a slightly slower scenario with room to recover is often the better commercial answer. Production bottleneck identification covers how to think about the constrained machine.

5. Skipping a Step That Something Depended On

Symptom. A scenario finishes impossibly early, and the number is so good that somebody quotes from it.

Cause. Skip removes a step from the scenario's cloned routing without rewiring whatever depended on it. A later step that was waiting on the skipped one can be treated as having no predecessor and scheduled earlier than the physical process allows.

Fix. Prefer Replace when the work still happens somewhere else and ModifyTime when it happens faster. Reserve Skip for steps with no downstream dependents, such as an optional finishing operation at the end of a routing. Whenever you do skip, verify the resulting dates against the physical process before quoting from them.

6. Overriding the Wrong Work Center

Symptom. The capacity boost is set to 150% and the scenario returns the same dates as the baseline.

Cause. One of three things. The override names a machine the routing does not use. A step override replaced that work onto a different machine, so the boost applies to something the job never touches. Or the scenario has not been re-run since the override was added, and you are reading the previous run's stored result.

Fix. Check the override row's work center against the routing the scenario actually simulates, then run it again. Results are stored per run, so re-running is always the first diagnostic.

7. Trusting Dates From Unconstrained Settings

Symptom. A scenario returns dates that look too good and nobody can reproduce them on the floor.

Cause. Usually the production settings rather than the overrides. A custom start date left in the past gives the engine a runway that no longer exists. Weekend production ticked on a scenario that was not supposed to test weekends silently adds days of capacity.

Fix. Review the production settings group before trusting any result. Two checkboxes and a date field explain most of the too-good answers, and both are easy to leave set from a previous experiment.

8. Comparing a Forward Scenario Against a Backward Quote's Target

Symptom. A backward quote and its scenarios seem to disagree even when the scenario has no overrides at all.

Cause. Scenario simulations always run forward. They start at the scenario's start date and report when the work finishes. The parent quote's finish-by framing does not carry into them, and a forward run may also use a different start date.

Fix. On a backward quote, compare each scenario's estimated end date against the customer's wanted date yourself. When you need the scenario to line up with the quote's own simulation, set the scenario's custom start date deliberately rather than assuming they match. Backward scheduling in EDGEBIC covers the direction rules.

9. Treating a Scenario as a Held Slot

Symptom. Two enquiries were tested against the same week's spare capacity, both were promised, and one is now late.

Cause. Scenario runs are in-memory only, and their results are discarded once the numbers are read. No capacity is held against a scenario or its parent quote, so both tests legitimately saw the same free hours.

Fix. Manage it as a commercial process. Re-run the winning scenario immediately before committing to a large promise, convert promptly once the customer accepts so the order takes its place in the queue, and treat a scenario date on an unaccepted enquiry as an estimate rather than a reservation. There is no reservation or hold mechanism to fall back on, so the discipline has to live in the sales process.

10. Enumerating Instead of Deciding

Symptom. A quote carries nine scenarios, three of them nearly identical, and the meeting to choose between them keeps getting deferred.

Cause. A routing with alternates at several steps has combinations that multiply fast, and each one has to be created and run individually. Building all of them feels thorough and produces paralysis.

Fix. Enumerate only the combinations you would actually execute. The documented working range is a baseline plus one scenario per realistic lever, which is two to four. If a scenario describes something your shop would never actually do on a Tuesday, it is not a decision option and it does not belong in the comparison.

Two Smaller Traps

Apply is refused. The message says to run the simulation first, and it means it: an unrun or since-edited scenario has no stored results to copy. Run it, then apply.

Scenarios named Scenario 2. The scenario name is all you see in the comparison charts. Name the lever: Second Shift on Mill, Vendor Cutting, Weekend Push. A chart labelled with three numbers tells you nothing three weeks later, and it tells a colleague reviewing the decision even less. The description field is there for the detail, such as which three weeks the evening shift would run.

Comparing across two quotes. Scenarios belong to one parent quote, and the comparison covers siblings within that quote. When two enquiries compete for the same week, note the numbers from each quote and compare them outside the charts rather than expecting one screen to line them up.

The Pre-Decision Checklist

Eight checks before you commit a date to a customer. For the full boundary list, read what a scenario can and cannot change. The quoting pillar covers the enquiry these scenarios hang off, and the EDGEBIC complete guide maps the platform.