A companion to The Canvas and the Camcorder. That post asked why technology fails in every era. This one answers a narrower question: where, exactly, does the failure begin?
It begins earlier than anyone thinks. Not at go-live. Not at configuration. It begins at process mapping — the step everyone treats as neutral.
Ask most organizations when their technology project started going wrong, and they will point to the rollout. But the rollout only revealed the problem. The problem was painted in months earlier, in the room where someone drew a picture of “how the organization works.” Because that picture is never as neutral as it looks. It is the first brushstroke on the canvas — and the question you ask while drawing it decides whether you end up with a portrait of your organization or a portrait of your software.
This is not a new observation. Nineteen years ago, I wrote about a conversation that captured the problem exactly:
In a recent conversation I had with a senior level executive, the individual lamented the fact that they currently have 2 full-time staff dedicated to making a PeopleSoft application work within their procurement organization. This of course limited or confined their efforts to focusing on the application itself instead of looking for ways to better understand and refine their core practice.
— Procurement Insights, June 2007
Two people whose full-time job was serving the software rather than improving the practice the software was supposed to serve. The technology has changed completely since 2007 — PeopleSoft was the name then; it is a different name now. The failure has not changed at all.
Two questions, two completely different maps
There are two ways to map a process, and in the room they feel almost identical. They are not.
The first asks: How does this organization actually create value? It starts with the operating reality — the decisions, the exceptions, the way work truly flows, and the incentive alignment among every agent involved, human and AI, internal and external — and draws that.
The second asks: How do we fit this organization into our technology, with the least customization and the fastest go-live? It starts with the tool and draws the organization to match it.
Both produce a document called a “process map.” Both look professional. But the first is a picture of you. The second is a picture of you posed to fit a frame that was chosen before anyone looked. The industry keeps drawing the second and calling it the first.
And here is the tell: if a specific technology or technologies are being considered or already selected before the mapping begins, you are almost certainly drawing the second map. You just may not know it yet.
Two things go wrong — and they are different
When technology holds the pen during discovery, two distinct failures occur, and it is worth separating them, because they compound.
The first is distortion. The map is bent, at the moment it is drawn, toward what the software already assumes. Steps that don’t fit the tool get smoothed over. Exceptions the tool can’t handle get labeled “edge cases” and set aside. The resulting map isn’t a decayed snapshot of your organization — it is a snapshot of an organization that never quite existed, already posed to match the product. It was wrong the instant it was captured — before any actual implementation had even begun.
The second is drift. Because the tool was chosen first, the whole exercise quietly changes its goal. Mapping stops being “understand the organization so we can accelerate it” and becomes “fit the organization to the technology so we can install it.” The objective drifts from accelerating success through technology to implementing technology — and those are not the same goal. One serves you. The other serves the timeline.
It does not have to end that way — and the proof, again, is in the archive. In 2007 I wrote about how the Commonwealth of Virginia approached its eVA e-procurement initiative:
As a result, they avoided the trap of eVA becoming a software project as Bob put it, and were thereby able [to] shift the emphasis from an exercise in cost justification, to one of process understanding and refinement.
— Procurement Insights, September 2007
They refused to let the tool become the project. By holding the emphasis on process understanding and refinement — the operating reality — rather than on cost-justifying and installing the software, they drew the first map, not the second. Nearly two decades ago.
But when the drift is not refused — when both distortion and drift take hold — the outcome is predictable. Distortion corrupts the picture. Drift corrupts the purpose. Together they guarantee that the expensive new system will be a faithful rendering of something that was never true — which is precisely why it fails on contact with the real operating floor.
The fix is a sequence, not a technique
The correction is almost embarrassingly simple, and almost nobody does it: map the organization through its own lens, before the decision to automate.
Not before the technology is identified, selected, and implemented — before the decision to automate at all. Because that map is what should tell you whether automation is even the right answer, and if it is, what actually needs it. Before a shortlist, before a demo, before a single vendor is in the room to bend the pen. The first map is owned by the organization, drawn from its own operating reality, answering one question only: how do we actually create value?
Only then do you go looking for technology — and now everything has changed. The technology is chosen to serve the map, instead of the map being drawn to serve the technology. You are no longer fitting yourself to a tool. You are finding a tool that fits you. That reversal is the entire difference between a system that accelerates you and one you spend three years adapting to.
This is the first concrete activity of what I call Phase 0™ — the work that happens before technology enters the conversation. Not readiness in the abstract. A specific, ownable deliverable: your process, mapped through your lens, while the room is still free of anything trying to sell you a frame.
You are not falling behind
Technology is not going away — and that includes AI. It will be waiting for you. Which means no one is falling behind anyone, because the companies that gain the upper hand and succeed are the ones that map themselves first, and only then introduce the technology and map it in.
So think about taking a “what time of day do orders come in?” approach — starting with how the work actually happens, before anything is automated. That is Phase 0™.
I tell the story of where that question came from — and the result it produced — in this conversation.
One honest caveat
None of this means technology never gets a say. A map drawn in total ignorance of what is buildable is a fantasy, and eventually feasibility has to enter the room. The point is not never consider technology. The point is sequence and ownership: the operating map comes first, drawn through your lens and owned by you; technical feasibility enters later, as a constraint on choosing the tool — never as the lens that drew the map.
The failure was never considering technology. It was letting technology hold the pen during discovery.
So ask the question
Before your next initiative — before the demos, before the shortlists — ask the one question that determines everything downstream:
Are you mapping to technology, or is technology mapping to you?
If a tool is already in the room when you start drawing, you have your answer. And you have time, right now, to put the pen back in your own hand.
Operating logic before technology. It was always the sequence. Process mapping is simply where that sequence is won or lost.
Truth Is Believing. Accuracy Is Knowing. Outcome Is Proof.™
-30-
Related
Are You Mapping to Technology, or Is Technology Mapping to You?
Posted on July 7, 2026
0
A companion to The Canvas and the Camcorder. That post asked why technology fails in every era. This one answers a narrower question: where, exactly, does the failure begin?
It begins earlier than anyone thinks. Not at go-live. Not at configuration. It begins at process mapping — the step everyone treats as neutral.
Ask most organizations when their technology project started going wrong, and they will point to the rollout. But the rollout only revealed the problem. The problem was painted in months earlier, in the room where someone drew a picture of “how the organization works.” Because that picture is never as neutral as it looks. It is the first brushstroke on the canvas — and the question you ask while drawing it decides whether you end up with a portrait of your organization or a portrait of your software.
This is not a new observation. Nineteen years ago, I wrote about a conversation that captured the problem exactly:
Two people whose full-time job was serving the software rather than improving the practice the software was supposed to serve. The technology has changed completely since 2007 — PeopleSoft was the name then; it is a different name now. The failure has not changed at all.
Two questions, two completely different maps
There are two ways to map a process, and in the room they feel almost identical. They are not.
The first asks: How does this organization actually create value? It starts with the operating reality — the decisions, the exceptions, the way work truly flows, and the incentive alignment among every agent involved, human and AI, internal and external — and draws that.
The second asks: How do we fit this organization into our technology, with the least customization and the fastest go-live? It starts with the tool and draws the organization to match it.
Both produce a document called a “process map.” Both look professional. But the first is a picture of you. The second is a picture of you posed to fit a frame that was chosen before anyone looked. The industry keeps drawing the second and calling it the first.
And here is the tell: if a specific technology or technologies are being considered or already selected before the mapping begins, you are almost certainly drawing the second map. You just may not know it yet.
Two things go wrong — and they are different
When technology holds the pen during discovery, two distinct failures occur, and it is worth separating them, because they compound.
The first is distortion. The map is bent, at the moment it is drawn, toward what the software already assumes. Steps that don’t fit the tool get smoothed over. Exceptions the tool can’t handle get labeled “edge cases” and set aside. The resulting map isn’t a decayed snapshot of your organization — it is a snapshot of an organization that never quite existed, already posed to match the product. It was wrong the instant it was captured — before any actual implementation had even begun.
The second is drift. Because the tool was chosen first, the whole exercise quietly changes its goal. Mapping stops being “understand the organization so we can accelerate it” and becomes “fit the organization to the technology so we can install it.” The objective drifts from accelerating success through technology to implementing technology — and those are not the same goal. One serves you. The other serves the timeline.
It does not have to end that way — and the proof, again, is in the archive. In 2007 I wrote about how the Commonwealth of Virginia approached its eVA e-procurement initiative:
They refused to let the tool become the project. By holding the emphasis on process understanding and refinement — the operating reality — rather than on cost-justifying and installing the software, they drew the first map, not the second. Nearly two decades ago.
But when the drift is not refused — when both distortion and drift take hold — the outcome is predictable. Distortion corrupts the picture. Drift corrupts the purpose. Together they guarantee that the expensive new system will be a faithful rendering of something that was never true — which is precisely why it fails on contact with the real operating floor.
The fix is a sequence, not a technique
The correction is almost embarrassingly simple, and almost nobody does it: map the organization through its own lens, before the decision to automate.
Not before the technology is identified, selected, and implemented — before the decision to automate at all. Because that map is what should tell you whether automation is even the right answer, and if it is, what actually needs it. Before a shortlist, before a demo, before a single vendor is in the room to bend the pen. The first map is owned by the organization, drawn from its own operating reality, answering one question only: how do we actually create value?
Only then do you go looking for technology — and now everything has changed. The technology is chosen to serve the map, instead of the map being drawn to serve the technology. You are no longer fitting yourself to a tool. You are finding a tool that fits you. That reversal is the entire difference between a system that accelerates you and one you spend three years adapting to.
This is the first concrete activity of what I call Phase 0™ — the work that happens before technology enters the conversation. Not readiness in the abstract. A specific, ownable deliverable: your process, mapped through your lens, while the room is still free of anything trying to sell you a frame.
You are not falling behind
Technology is not going away — and that includes AI. It will be waiting for you. Which means no one is falling behind anyone, because the companies that gain the upper hand and succeed are the ones that map themselves first, and only then introduce the technology and map it in.
So think about taking a “what time of day do orders come in?” approach — starting with how the work actually happens, before anything is automated. That is Phase 0™.
I tell the story of where that question came from — and the result it produced — in this conversation.
One honest caveat
None of this means technology never gets a say. A map drawn in total ignorance of what is buildable is a fantasy, and eventually feasibility has to enter the room. The point is not never consider technology. The point is sequence and ownership: the operating map comes first, drawn through your lens and owned by you; technical feasibility enters later, as a constraint on choosing the tool — never as the lens that drew the map.
The failure was never considering technology. It was letting technology hold the pen during discovery.
So ask the question
Before your next initiative — before the demos, before the shortlists — ask the one question that determines everything downstream:
Are you mapping to technology, or is technology mapping to you?
If a tool is already in the room when you start drawing, you have your answer. And you have time, right now, to put the pen back in your own hand.
Operating logic before technology. It was always the sequence. Process mapping is simply where that sequence is won or lost.
Truth Is Believing. Accuracy Is Knowing. Outcome Is Proof.™
-30-
Share this:
Like this:
Related