Organizational Inhibitors: Derailing Change
RSR uses The BOOT Methodology© as a framework in all our research. Frequent readers will recognize the BOOT. It’s an acronym and a model, and the model really works:
- B=Business Challenges retailers face that drive change. These are most typically external to the enterprise. A generic, common business challenge retailers face is “improving customer service while holding the line on costs “. In today’s world, customer service is the scarce commodity.
- O=Opportunities arising from those challenges. These are of course, ways to overcome those challenges. In the case of the customer service problem, while the obvious solution seems to be in-store, in fact tailoring merchandise assortments to local demographics, psychographics and tastes works too. In essence, opportunities can mitigate or eliminate the challenges retailers face.
- O=Organizational Inhibitors that keep retailers from taking advantage of the opportunities they identify. These are internal, rather than external challenges. They can range from “it all costs too much ” to, “not enough people to solve the problem. “
- T=Technology Enablers are available to facilitate taking advantage of opportunities, assuming a retailer can get past the organizational inhibitors it faces. Certainly, following our example through to the end, in today’s large retail chains, it’s virtually impossible to economically tailor assortments without the aid of enabling technologies.
RSR believes that Retail Winners (those that outperform their competitors and the industry as a whole) unconsciously work the BOOT to their advantage. Our benchmark studies consistently show this is true.
I‘d like to take a few minutes today to talk about one of four BOOT elements. Of all of them, it is easiest to gloss over Organizational Inhibitors. The survey answers tend always to be the same. There are ROI hurdles. Our technology infrastructures are a mess. In fact, if we are to believe several years of survey responses, technology infrastructures are the most significant inhibitor to change. But what is easily overlooked is how those infrastructures got that way, and the vested interest the enterprise might have in keeping them that way.
Resistance To Change: It’ll Get You Every Time
When I was a CIO I learned a valuable truth: You never like your old system as much as the day AFTER you replace it with a new one. That’s true for the user community, and in fact, it’s often true for the IT group as well. It may have been held together with baling wire and chewing gum, but it was OURS. It had nuances no package could have, and allowed us to do unique and special things. And Susan in IT, hey, she knew that home grown payroll package like the back of her hand. And Doug, well he could tweak that merchandising report like no one else.
Why does this matter? It matters because it defines the difference between technology success and failure. Resistance to change can trump EVERYTHING, and bring the business to its knees.
How else do we explain how ten apparel manufacturers successfully implement a package, and an eleventh fails to implement the same package, blaming revenue shortfalls on a poor implementation? Perhaps the IT department didn’t gel well with the systems integrators hired to do the implementation. Perhaps the users didn’t document exactly what they did “in the old system “. And maybe even worse, perhaps standard operating procedures had fallen so much into folklore that no one even really knew who did a particular task, and why it was critical to the running of the enterprise. What if all of the above was true? Most likely there were mixed emotions about implementing a new infrastructure anyway.
Let’s face it. Some people say they like change. Truth be told, NO ONE likes change. It makes people uncomfortable. This is a truth of life.
RSR does not do quadrants, waves or any other vendor evaluations. In fact, I’ll go out on a limb here and say that most of today’s mature software applications (suites and point solutions) work. They’re successfully used by tens, if not hundreds of companies. Yet periodically, we still hear reports of high profile failures. From time to time, a company will still blame a poor quarter on a system implementation.
Everyone Is Coin Operated
I know we’re preaching to the choir here, but it’s still worth noting: subtle resistance to change can completely derail a project. It’s easy to create Service Level Agreements (SLAs) for vendors and for day-to-day IT operations, but it’s not so easy to create them for new implementations.
There’s only one choice. And that’s to tie every single involved party’s compensation to the success of a new implementation. Start with systems selection and drive all the way through to post-implementation support. The business executives, the actual line staff, and the IT group should all have skin in the game. Of course, this requires executive level support. The correct word is “mandate “. But it also requires a coalition on the ground. It requires teamwork and willingness. Willingness doesn’t mean “happiness “. As I said, no one really likes to change.
There is no longer any excuse for failed implementations of mature technology solutions. None. That may sound radical, but I have seen what the willing can do. I have also seen how the unwilling can sabotage even the best technically drawn out project plan. Before you embark on ANY system implementation, ask yourself… are we willing? If not, it might be better to wait. You can’t wait forever, but it’s important to wait until the organization can grit its collective teeth and push through it. There is really no other way.