Hint: it’s not the software

This stat is repeated to the point of exhaustion, but it’s still true that 85% of digital transformation projects fail.

Maybe they outright blow up, but more often, and more insidiously, they just don’t stick. The company ends up backsliding to their old ways, diminishing the improvement to nothing more than a slightly faster horse that they overpaid for.

This is avoidable.

I’ve been in and around at least 100 of these projects over the last 10 years. Many succeeded. Way too many died off way after the project was deemed a success. There were a few proper disasters that shouldn’t have even started. I took 4-letter words to the face a time or two. One year, I named my fantasy football team after a certain person that made a lot of days very difficult… Let’s just say that stuff is more indicative of an unhealthy relationship than anything else. It should be a partnership, not a sh*t-slinging contest.

I’ll save the war stories for a happy hour someday. For now, here are the most common and most damaging mistakes that I see.

Losing the Balance of Power

Whenever there’s a disruption to the status quo, there’s a power shift. The impact of this will depend on how political your organization is. So when there’s a larger change, there can be infighting and power grabbing. Be aware of that.

But the more avoidable and more common issue is the imbalance of power between the company and whoever they’re working with on the implementation, consultants and/or software providers. Let’s look at what happens when any of the 3 might have too much power.

If the company keeps all the power, keeping the service companies in a completely subservient role, the outcome:

• misses out on good ideas from elsewhere in the industry
• focuses on speeding up what is already done, not whether what is already done is actually useful or if there is something missing completely
• is totally dependent on the buyer‘s ability to manage bias, perception, change, and battle the status quo

If the consultant gains too much power, the project:

• includes too many nice-to-haves prior to the core objective being complete
• diminishes the importance of the company’s unique situation and the software’s true capability
• sets up for additional phases, not for a finished solution

If the software provider gains too much power, the project:

• becomes about implementing software, not solving problems
• solves any problem encountered with more usage, more features of the software providers tool(s)
• ignores work needed beyond the software like process work, reporting, visualization, roles/responsibilities

None of these are good. They all lead to less than ideal results, if not failure. This is why building a strong partnership with real trust and aligned incentives is critical to driving a successful project.

Underestimating the Status Quo

Companies become the way that they are for a good reason. Inertia. Whether it’s a year or 100 years. 10 people or 10,000 people. The events, emotions, personalities, and problems that have shaped the current state are more complex and more powerful than we realize.

It may not be a good reason, but there’s a perfectly logical reason for the way things are. Maybe it’s an insecure, over-protective VP that doesn’t want the transparency that integration would require. Maybe it’s a mad scientist in finance that got wayyy too excited about finally getting that excel sheet to work.

Whatever it is, we have to respect it. And do our best to understand it.

The most common occurrence here is a failure of communication and stakeholder management. You and your team are fired up, believe in the vision, see the path, and LOVE the solution you’ve found. You go about the project, on time, under budget. Then you have a hard time getting data from that other team. Then the manager that you need to build a report for won’t show up to a meeting. Finally you’re left with a cool new tool that your team loves, no one else cares about, and you have a hard time justifying it at renewal time.

This disrespect of organizational inertia usually drives the next mistake…

Claiming Victory too Early

Culture = behavior, so process changes are cultural shifts. It can take 2 to 5 YEARS for a change like this to be so ingrained in the company that it just continues without intentional effort. This is about habit change, and that takes time. Especially for groups of people that need to change at the same time.

If there is any real change management work done (there probably isn’t), it’s usually slapped on to the end of the project and is nothing more than making sure that Rick and Karen’s spreadsheets have some time in hospice before passing away.

When we make a change, it should be in line with a grander vision of where the organization is trying to go. Along the way to a successful project, there are barriers to change (see status quo) that made the project harder.

After the implementation, all of those barriers remain as forces that will be trying to push you backward. Turnover, bad data, changing business requirements, etc…

That bad data. That stubborn spreadsheet. That adjacent system that made actual integration impossible (duct tape, bubble gum, and excel macros don’t count). That information that lies in 4 peoples heads and no where else.

This project being finished doesn’t make these problems go away. They’ll still be there, continuing to make it harder to stick to the new way of doing things, long after you send the consultants on their way.

Just because you’ve finished the last step on the project manager’s task list, does not mean that you’re safe.

If the new way of doing things isn’t on solid footing with systems in place to sustain it, it will fall.

Avoiding the Fate of Failure

When working through any kind of organizational change (process improvement, software implementation, culture building, whatever…) these are the things that are top of my mind. It’s especially easy to miss the human risks when it’s “just a technical project.”

But it always come down to people.

The teams that systemize against these issues are the ones who succeed in making lasting change. Change that builds momentum. Change that is not just an improvement, but a catalyst.

It’s very easy to forget about these problems when the project status report is all green and shows 90% complete. This is why strong change leadership, not just change management, is so critical.

Instead of becoming another statistic on a long list of flops, ask yourself 3 questions:

• Are those that are driving the change actually incentivized to make the project as successful as possible?
• What is our process for understanding, mitigating, and eventually resolving the existing conditions that are working against us?
• What is the difference between project completion and project success

Trust me, you don’t need a million bucks and a dozen new grad MBAs to answer those questions.