Why solution mapping fails before it begins — a question of starting points.
Every solution map has a starting point. Almost no one notices theirs — and the starting point decides everything that follows.
Traditional solution mapping starts from the intended outcome and builds the framework expected to reach it. You gather what you are told about how the work happens, you lay out the steps, and you draw the arrows toward the goal. It is a forward map, built from a plan. Its question is: what path should produce the outcome?
The Hansen Model starts from the opposite end. It begins at the known point of failure and works backward — tracing the actual operating reality until it finds and removes the obstacles preventing the outcome. Its question is not “what path should produce the outcome?” It is: what is stopping the outcome that is already failing?
Same system. Opposite starting points. Opposite directions of travel. And the direction is not a matter of style or thoroughness — it is the whole difference, because of one fact that sounds obvious the moment it is said and changes everything once you sit with it.
The forward map cannot contain the obstacle.
A designed map contains only what someone thought to put in it. If anyone in the organization had known about the thing blocking the outcome, they would have designed around it already. So by construction, the obstacle is the one element the forward map is guaranteed to be missing. You can make that map more detailed, more rigorous, more beautifully rendered — and it will still be missing the same thing, because detail is not discovery. A finer portrait of a system is still a portrait of what you were told.
The failure is different. The failure is evidence. A delivery rate stuck at 51% against a 90% requirement is proof that something real exists outside the diagram — something no one declared, because no one knew to. Starting from the failure means starting from the only place that points at what the plan could not see.
[Figure: The Map You Design vs. The Map You Trace — the same system, mapped from two different starting points. One is a clean line to a destination; the other is a search from a failure that leaves the mapped process, loops back on itself, and surfaces the obstacles the plan could not contain.]
Consider the case that first proved this, in 1998.
A national defence maintenance operation was delivering next-day parts 51% of the time against a 90% contractual requirement, and it was about to lose the contract. The forward map was obvious, and everyone had it: order received → supplier sourced → parts ship → next-day delivery. Optimize that line — better systems, faster processing, tighter supplier management — and you get a faster version of a 51% failure.
I did not start from the intended path. I started from the failure, and asked a question that was nowhere on the map: what time of day do orders come in?
The answer was 4 PM — and “why 4 PM?” took me straight out of procurement, the process I had been hired to look at, and into the service department. There, technicians were holding their parts orders until the end of the day, because their performance was rated by the number of calls they responded to. Clearing calls came first; ordering parts came last. That behaviour lived in a department no one had put on the procurement map, and it set everything downstream in motion.
Back inside procurement, the pressure of those late orders had forced two habits. Buyers were sending roughly eighty percent of the work to small US-based suppliers with no cross-border customs experience, and they were cutting purchase orders against delivery dates the suppliers had never confirmed — because the queue had to be cleared by end of day. When a supplier missed, the order was either cancelled and re-entered in the next day’s queue as new work, or the buyer accepted an extended delivery date. Either way, the failure re-entered the system and regenerated itself, every single day.
Follow it further out, past procurement again, and each of those small suppliers used its own courier. There was no consolidated customs clearance — every shipment cleared independently, and every shipment could be held or mis-documented independently, by vendors who had never done cross-border work. The delay the service department created at 4 PM was now being multiplied at the border.
And then the trail left the operation’s four walls entirely, into finance — the last place anyone mapping a procurement process would ever look. The purchase orders captured the cost of the part only. The suppliers’ courier charges arrived separately, on the invoices. Finance could not reconcile the two — the true landed cost of a part was never in one place — and worse, the markup the contract allowed was calculated on the part cost alone. The shipping the PO never captured was quietly eating the margin. On transactions the program was booking as revenue, it was losing money.
The detail that makes it unforgettable is why no one had caught it: finance had done nothing wrong. They had separated part cost and shipping into two line items, each managed and each reconciling cleanly on its own. The loss existed only in the relationship between the two lines — and no one was looking at the two lines together. Competent accounting had built the blindness.
Now count the departures. The failure pulled me out of procurement into service, back into procurement, out again to the couriers and the border, and finally all the way out to finance — four crossings, each one triggered not by the brief but by what the last finding forced me to ask. No process map produces that path, because no one maps their way from a delivery SLA to a two-line-item accounting severance. You only reach it if you start from the failure and follow it wherever it goes.
None of it was on the forward map. All of it determined the outcome. The fix was not to optimize any single step — it was to break the loop and re-align the couplings the map could not see. Delivery moved from 51% to 97.3% within three months. The technology came afterward, onto a system that had finally been made real.
That is the difference the two maps make, and it is worth being fair about it. The forward map is not foolish. When what people tell you matches how the work actually happens, it is sufficient — and it is faster. It fails silently only when the two diverge, and it has no mechanism to notice the divergence, because it never questions its own source material. That is the real risk: not that it is wrong, but that it cannot tell you when it is.
“But we map failures too,” a good practitioner will say. “We do root-cause analysis.” Fair — but notice where conventional root-cause begins: inside the declared process, looking for the broken step within it. The Hansen start refuses to assume the cause is even in the mapped process at all. At the defence operation, the cause was not a broken step in procurement. It was a behaviour in a department that was never on the map. You do not find that by analysing the process harder. You find it by starting from the failure and being willing to follow it wherever it goes — including out of your own scope.
This is the same discipline I have described for twenty years in a different metaphor: the difference between a canvas and a camcorder. A designed map is a canvas — accurate the moment it is finished, and decaying from that instant, because the organization keeps moving and the map does not. Tracing from the failure is the camcorder: it keeps recording the operating reality as it actually runs. Every framework you own is a canvas. The obstacle is never on it.
So before you optimize the map you were handed, ask which map you are holding. If it was built forward from what you were told, it points confidently at the outcome — and it does not contain the reason you are not reaching it.
Start from the failure. It is the only starting point that knows something you don’t.
-30-
Truth Is Believing. Accuracy Is Knowing. Outcome Is Proof.™
What you have above is a high-level view of how the Hansen Model™ works. We provide a deep-dive, nuts-and-bolts MasterClass session available online or that can be scheduled in person for groups. To learn more about the MasterClass and end-of-course documented white paper, contact us at HPT@hansenprocurement.com.
Related
The Map You Design and the Map You Trace
Posted on July 29, 2026
0
Why solution mapping fails before it begins — a question of starting points.
Every solution map has a starting point. Almost no one notices theirs — and the starting point decides everything that follows.
Traditional solution mapping starts from the intended outcome and builds the framework expected to reach it. You gather what you are told about how the work happens, you lay out the steps, and you draw the arrows toward the goal. It is a forward map, built from a plan. Its question is: what path should produce the outcome?
The Hansen Model starts from the opposite end. It begins at the known point of failure and works backward — tracing the actual operating reality until it finds and removes the obstacles preventing the outcome. Its question is not “what path should produce the outcome?” It is: what is stopping the outcome that is already failing?
Same system. Opposite starting points. Opposite directions of travel. And the direction is not a matter of style or thoroughness — it is the whole difference, because of one fact that sounds obvious the moment it is said and changes everything once you sit with it.
The forward map cannot contain the obstacle.
A designed map contains only what someone thought to put in it. If anyone in the organization had known about the thing blocking the outcome, they would have designed around it already. So by construction, the obstacle is the one element the forward map is guaranteed to be missing. You can make that map more detailed, more rigorous, more beautifully rendered — and it will still be missing the same thing, because detail is not discovery. A finer portrait of a system is still a portrait of what you were told.
The failure is different. The failure is evidence. A delivery rate stuck at 51% against a 90% requirement is proof that something real exists outside the diagram — something no one declared, because no one knew to. Starting from the failure means starting from the only place that points at what the plan could not see.
[Figure: The Map You Design vs. The Map You Trace — the same system, mapped from two different starting points. One is a clean line to a destination; the other is a search from a failure that leaves the mapped process, loops back on itself, and surfaces the obstacles the plan could not contain.]
Consider the case that first proved this, in 1998.
A national defence maintenance operation was delivering next-day parts 51% of the time against a 90% contractual requirement, and it was about to lose the contract. The forward map was obvious, and everyone had it: order received → supplier sourced → parts ship → next-day delivery. Optimize that line — better systems, faster processing, tighter supplier management — and you get a faster version of a 51% failure.
I did not start from the intended path. I started from the failure, and asked a question that was nowhere on the map: what time of day do orders come in?
The answer was 4 PM — and “why 4 PM?” took me straight out of procurement, the process I had been hired to look at, and into the service department. There, technicians were holding their parts orders until the end of the day, because their performance was rated by the number of calls they responded to. Clearing calls came first; ordering parts came last. That behaviour lived in a department no one had put on the procurement map, and it set everything downstream in motion.
Back inside procurement, the pressure of those late orders had forced two habits. Buyers were sending roughly eighty percent of the work to small US-based suppliers with no cross-border customs experience, and they were cutting purchase orders against delivery dates the suppliers had never confirmed — because the queue had to be cleared by end of day. When a supplier missed, the order was either cancelled and re-entered in the next day’s queue as new work, or the buyer accepted an extended delivery date. Either way, the failure re-entered the system and regenerated itself, every single day.
Follow it further out, past procurement again, and each of those small suppliers used its own courier. There was no consolidated customs clearance — every shipment cleared independently, and every shipment could be held or mis-documented independently, by vendors who had never done cross-border work. The delay the service department created at 4 PM was now being multiplied at the border.
And then the trail left the operation’s four walls entirely, into finance — the last place anyone mapping a procurement process would ever look. The purchase orders captured the cost of the part only. The suppliers’ courier charges arrived separately, on the invoices. Finance could not reconcile the two — the true landed cost of a part was never in one place — and worse, the markup the contract allowed was calculated on the part cost alone. The shipping the PO never captured was quietly eating the margin. On transactions the program was booking as revenue, it was losing money.
The detail that makes it unforgettable is why no one had caught it: finance had done nothing wrong. They had separated part cost and shipping into two line items, each managed and each reconciling cleanly on its own. The loss existed only in the relationship between the two lines — and no one was looking at the two lines together. Competent accounting had built the blindness.
Now count the departures. The failure pulled me out of procurement into service, back into procurement, out again to the couriers and the border, and finally all the way out to finance — four crossings, each one triggered not by the brief but by what the last finding forced me to ask. No process map produces that path, because no one maps their way from a delivery SLA to a two-line-item accounting severance. You only reach it if you start from the failure and follow it wherever it goes.
None of it was on the forward map. All of it determined the outcome. The fix was not to optimize any single step — it was to break the loop and re-align the couplings the map could not see. Delivery moved from 51% to 97.3% within three months. The technology came afterward, onto a system that had finally been made real.
That is the difference the two maps make, and it is worth being fair about it. The forward map is not foolish. When what people tell you matches how the work actually happens, it is sufficient — and it is faster. It fails silently only when the two diverge, and it has no mechanism to notice the divergence, because it never questions its own source material. That is the real risk: not that it is wrong, but that it cannot tell you when it is.
“But we map failures too,” a good practitioner will say. “We do root-cause analysis.” Fair — but notice where conventional root-cause begins: inside the declared process, looking for the broken step within it. The Hansen start refuses to assume the cause is even in the mapped process at all. At the defence operation, the cause was not a broken step in procurement. It was a behaviour in a department that was never on the map. You do not find that by analysing the process harder. You find it by starting from the failure and being willing to follow it wherever it goes — including out of your own scope.
This is the same discipline I have described for twenty years in a different metaphor: the difference between a canvas and a camcorder. A designed map is a canvas — accurate the moment it is finished, and decaying from that instant, because the organization keeps moving and the map does not. Tracing from the failure is the camcorder: it keeps recording the operating reality as it actually runs. Every framework you own is a canvas. The obstacle is never on it.
So before you optimize the map you were handed, ask which map you are holding. If it was built forward from what you were told, it points confidently at the outcome — and it does not contain the reason you are not reaching it.
Start from the failure. It is the only starting point that knows something you don’t.
-30-
Truth Is Believing. Accuracy Is Knowing. Outcome Is Proof.™
What you have above is a high-level view of how the Hansen Model™ works. We provide a deep-dive, nuts-and-bolts MasterClass session available online or that can be scheduled in person for groups. To learn more about the MasterClass and end-of-course documented white paper, contact us at HPT@hansenprocurement.com.
Share this:
Like this:
Related