I want to share with you a technique I used to overcome some serious implementation resistance we had on a digital transformation project.
We had built a new system for transactional processing and had run several pilot transactions involving real customers and real employees using the system. These transactions went through without the sky falling, though there were some rough edges to address here and there.
We wanted to keep running more transactions through the system, so that we could learn from the real-world usage, but many of the people involved, even some on our own transformation team, were against it. We were having weekly calls at that point, but it seemed like every call we looked at the status for an hour and then promised to something about it the next week. And then the next week we would rinse and repeat, getting nowhere.
So I decided to call a much shorter, daily meeting (I called it a ‘daily scrum’ even though it was mainly business people), and started a new list, called the ‘Why Nots’. Instead of asking everyone their progress, I would ask them why they objected to putting another transaction in the system, repeatedly asking ‘why not’ until we arrived at something actionable.
The conversations would go something like this:
Me: “So John, I want to put the next transaction on the new system, why not?”
John: “Well James, Joe from accounting hasn’t signed off.”
Me: “Ok, so why hasn’t he signed off?”
John: “Because we haven’t given him a demo of the accounting features yet.”
Me: “Why haven’t we given him a demo of the accounting features?”
John: “Well, I haven’t had the time to schedule it yet.”
Me: “Ok, so the ‘why not’ on the list is that we haven’t scheduled a demo with Joe from accounting. Who do you think should take care of this?”
John: “I should do it, because he works in my office.”
Me: “Great, thanks.”
It turned out that well over 50% of the ‘why nots’ raised were actually action items for the people who raised them. It turns out that people raise objections about things they understand, and the things they understand are in their domain, and their domains tend to be their responsibility. They were complaining about action items not getting done, when they were the ones who needed to do them!
The next largest category of ‘why nots’ were imaginary problems. For instance, we would get an objection that we hadn’t built a certain integration yet. I would ask why they can’t process the transaction without the integration, and I would be told that actually they can. And so we would end up marking it as resolved, because it wasn’t a real blocker to implementation.
So we ended up with a list of over 100 ‘why nots’ in a couple of days, with over half of them completely resolved in the same time span. It quickly became clear which ‘why nots’ were really serious and those got immediate attention. Anything that required additional development got scheduled in the subsequent sprint, and once that finished we had restarted processing transactions again!
James Miller Burgess 