Set a date when the discussion ends and the decision gets made, and say the date out loud at the start.
Consensus is the most oversold idea in project management, in my view. Leaders chase it because it feels safe, and the chase eats the schedule while everybody waits for a unanimity that was never coming. I’d rather hear everyone, set a date, decide and take the heat for it than watch a project stall out of politeness.
Why do digital transformation projects fail?
Several reasons, and the coordination problem is the one nobody sells a product for.
I’ve 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’s the most common cause I saw.
The coordination problem is different and it arrives earlier. Before anyone can build anything, a large number of people have to agree on what to build, and they won’t.
Every vendor in this market sells a structure that promises alignment. Workshops, discovery phases, stakeholder maps. Those produce documents. What they don’t produce is agreement, because the disagreement is real and no process dissolves it.
I think selling alignment as a deliverable borders on dishonest. A company pays for the workshops, gets a binder of stakeholder maps, and still has accounting and the warehouses pulling in opposite directions. The vendor goes home, and the internal project lead is left holding a disagreement nobody resolved and a schedule that already slipped.
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 don’t think that’s 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.
The accounting equipment was a set of old machines I only saw a couple of times.Share on X
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 didn’t 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 weren’t 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 isn’t 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’s a bit of both.
People hate hearing that, and I understand why. It sounds autocratic. The alternative is worse for everybody, including the departments that would have lost the argument, because a decision that never gets made hurts every one of them at once while the old paper system keeps grinding along.
How do you decide when people disagree?
Set a date, hear everyone before it, and decide on it.
The date 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 hurts more, because it arrives as an interruption and not as a scheduled event. Announce the date at the beginning. Say plainly that every department will be heard and that not every department will get what it asked for. The decision happens on that day. Then hear people properly. If people are overridden after a real hearing, they can survive it. If they’re overridden by somebody who never listened, you get the quiet non-cooperation that sinks the rollout six months later.
When a rollout fails from that kind of resistance, I put the blame on the leader who skipped the hearing. The staff did what people always do when they’re ignored. The person who decided without listening created the problem, and then usually blames the staff for it.
Who should be overridden in a transformation?
Whoever is protecting their own department at the expense of the whole. That’s 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.
Enough of them, made carelessly, and a project acquires a set of people who won’t sabotage it and won’t help it either.
Some requests survive that question and get adopted. Most get modified. A few don’t 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 instead of 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 won’t sabotage it and won’t help it either. Carelessness is what I can’t forgive in a leader here. Overrides come with the job. Making them casually, in public, with no explanation, burns people who were only defending the work they’d been asked to do, and the project pays for it long after that leader has moved on.
A small company feels this more sharply than a large one. At forty people there’s 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 in detail, instead of 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 isn’t making decisions, they’re just issuing them.
| Move | Why it matters |
|---|---|
| Hear everyone properly before the decision date | People overridden after a real hearing can survive it |
| Ask out loud what a request costs everyone else | The person overridden has at least seen why |
| Explain the reasoning to whoever lost, privately and in detail | Announcing the outcome to a group burns people |
| Give ground where the cost to the whole is low | A leader who never concedes is just issuing decisions |
| Never override casually, in public, with no explanation | Careless overrides leave people who won’t help the project |
My take
Unanimity isn’t coming, so stop waiting for it. I moved a company off paper and onto computers, and no version of that project satisfied every department. Announce the decision date up front. Hear everyone properly, decide, and tell people that not every department gets what it asked for. Override whoever is protecting their own turf at everyone else’s expense. When a rollout fails from resistance, blame the leader who skipped the hearing.
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 structure for that in the mid-1990s, and the structures that exist now don’t 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 still a coordination problem, and I get angry when companies spend their whole budget on the technology and treat the people part as an afterthought. The software is the part you can buy. The decision date, the hearing and the explanation afterward are the parts a leader has to do in person, and skipping them is how good systems end up failing.
People will disagree, and deciding anyway is the manager’s job. Street-Smart Management Wisdom follows three managers through the calls you are about to face, across fourteen chapters.
