Set a date when the discussion ends and the decision gets made, and say the date out loud at the start.
Why do digital transformation projects fail?
Several reasons, and the coordination problem is the one nobody sells a product for.
I have written elsewhere about the testing failure that kills transformations, where systems pass every check and then fall over under real load. That one is technical and it is the most common cause I saw.
The coordination problem is different and it arrives earlier. Before anything can be built, a large number of people have to agree on what gets built, and they will not.
Every vendor in this market sells a framework that promises alignment. Workshops, discovery phases, stakeholder maps. Those produce documents. What they do not produce is agreement, because the disagreement is real and no process dissolves it.
What did a company look like before computers?
Paper, in quantities that are hard to picture now.
When I arrived at a major national retailer in the mid-1990s, the company ran on paper. Paper in the accounting room. Paper manifests at the warehouses. Accounting, human resources, everything, done by hand.
The printers produced hundreds of reams a day. My recollection is a pallet of paper, every single day, and I do not think that is an exaggeration.
The accounting equipment was a set of old machines I only saw a couple of times. Strange devices that reminded me of an abacus.
My job was to put my arms around the project and manage the pieces, working alongside the development person, the store person, and the network person. Nobody called it a digital transformation, because the phrase did not exist yet.
Can you get consensus from every department?
No, and the attempt is what kills the schedule.
Hundreds of people across departments that had never needed to agree on anything suddenly had to agree on how the company would work. Accounting wanted one thing. The warehouses wanted another. The stores wanted a third. Every one of those positions was reasonable from where the person stood.
They were not being difficult. Each department had built its process around what paper allowed, and each had legitimate reasons for its own way of working.
What I learned is that unanimous agreement is not available at that scale. You reach a consensus quickly and then you decide. Sometimes you override people and sometimes you go along with them, and usually it is a bit of both.
How do you decide when people disagree?
Set a date, hear everyone before it, and decide on it.
The date is what makes the rest work. A discussion with no end runs until somebody with authority loses patience, and the decision that comes out of that is worse and lands harder, because it arrives as an interruption rather than as a scheduled event.
Announce the date at the beginning. Say plainly that every department will be heard, that not every department will get what it asked for, and that the decision happens on that day.
Then hear people properly. Being overridden after a real hearing is survivable. Being overridden by somebody who never listened is what produces the quiet non-cooperation that sinks the rollout six months later.
Who should be overridden in a transformation?
Whoever is protecting their own department at the expense of the whole.
That is easy to write and hard to identify, because nobody experiences themselves that way. The warehouse manager arguing for warehouse requirements is doing his job. The accounting lead defending an accounting process is doing hers.
The test is whether the request survives the question of what it costs everyone else. Ask it out loud, in the room, and let the person answer.
Some requests survive that question and get adopted. Most get modified. A few do not survive, and those are the overrides, and the person on the receiving end has at least seen why.
What does a transformation cost in trust?
Some, always, and the cost is worth naming rather than pretending it away.
Every override spends a little of the relationship with the person overridden. Enough of them, made carelessly, and a project acquires a set of people who will not sabotage it and will not help it either.
A small company feels this more sharply than a large one. At forty people there is no distance to absorb it. Everyone knows who got overruled, and the person who lost the argument is sitting across the table at lunch.
Two things reduce the cost. Explain the reasoning to the person who lost, privately and specifically, rather than announcing the outcome to a group. And give ground where the cost to the whole is low, since a leader who has never conceded anything is not making decisions, they are just issuing them.
Does the technology matter less than the coordination?
For that project, considerably less.
The machines we chose and the software we built were consequential and they were solvable problems with known methods. Getting hundreds of people who had run a business on paper to accept a new way of working was neither.
Nobody had a framework for that in the mid-1990s, and the frameworks that exist now do not solve it either. They organize the conversation, which has value, and then somebody still has to decide.
Strip away thirty years of vocabulary and a transformation is a coordination problem wearing a technology costume. The technology part is the part you can buy.
The Guides That Get Your Book Written, Published, and Sold
Four short, practical guides on writing, publishing, and selling your book, plus the occasional note when there's something worth your time. No fluff, no daily inbox clutter. Drop your email and they're yours.
We use MailerLite to manage our list and send these emails. Your address is used only to send you what you signed up for. We will not sell it, share it, or use it for anything else, and you can unsubscribe anytime.