Click to learn more about author Leon Adato.

Technical projects fail – but they don’t fail because of technology. They fail because of planning.

The numbers vary on how many transformation efforts fail, but most experts agree it’s high. One estimate says it reaches 84%. Billions have gone up in smoke, despite all the flowcharts and the PowerPoint presentations.

The technology didn’t fail, though – because it’s never the technology. I’m comfortable saying this because if you were working on a purely technical problem, you’d fix or replace the broken part until it worked. Because this is what tech pros do, every day (and night and weekend): They make tech work. There are caveats, such as poor product quality and technical debt. But tech isn’t the enemy. Planning is.

As Bob Lewis has often said, there’s no such thing as a technology project. There’s only a business project with a technology component to it. Transformational changes can involve a move from on-premises to the cloud. Or the C-suite wants a company-wide adoption of some new application promising to change the way you do business.

Know What Your Business is About

The people at the top need to first understand their own businesses. Transformation often fails because the C-level executives don’t have a clear sense of what their business is.

If you ask the CEO of Coca-Cola, or Ford, or Netflix, or Etsy, or any of those companies, “What kind of business are you?” They could tell you in two or three sentences what their business is.

This thing we call “digital transformation” (a frustratingly vague term meaning many things) is fundamentally about enabling the overarching vision of a business – and  making this vision operate more efficiently than ever before. But still, many efforts fail.

So, which is better: To force through change – pound it through the bureaucracy and do it quickly? Or is a slow and extremely gradual approach better? In other words, should you be the turtle or the hare?

The answer is neither.

Don’t Be a Turtle Or a Hare

Job 1 for you is to know that when you move too quickly, you’ll likely fail. Move too slowly, and you’ll also fail. Don’t try to be a turtle or a hare.

Hares are dominant in Silicon Valley. They say, “Move fast and break things.” Now, the rideshare hares are sorting through their lawsuits. The social sites are playing a game of delay, deny, deflect –and dealing with the resulting PR nightmare. Cities are regulating the home-share sites, too. Those sites moved fast and broke things –and now all of us must do the clean-up.

Many legacy companies envy this approach. They want to be thought of as disruptors of their spaces, not as staid legacy businesses. So, they launch a proof of concept and decide they’re hares. They move fast and break things – and pull the levers on their transformation projects before they’re ready. Then the trouble starts.

Turtles aren’t any better: Move like molasses in today’s environment and you’ll end up with someone eating your lunch. There are countless examples of companies who were in the Fortune 500 a few years ago, only to end up with their divisions getting chopped up and sold off to the competition like LEGO blocks.

There’s no magic one-size-fits-all formula (or even one-size-fits-most). But add two words to “Move fast and break things.”

Add the words “in test.”

Move Fast and Break Things… In Test

Implement your change in a test plan or a proof of concept or a pilot. Learn from the process. Then (maybe) roll out your project –including any lessons learned –gradually, to two sites, three sites, four sites, and so on.

Base your plan on what the business can tolerate from a financial and a disruption standpoint. Also, base it on how much the company can handle while stuck in the awkward in-between stage where you are half-in, half-out of your transformational project.

Those are the overarching principles. Here are some further principles on how to manage for change:

Hire the Best People

As a manager, your job isn’t to be smart. It’s to make the hard choices and then stand by those choices when the going gets rough. This means you must have a staff you trust. If you don’t have the best people, you’ll need to fix that.

Hire by experience, sure. But also hire by potential. If a person has something extraordinary about him or her, don’t be a pedant about the small stuff on the resume.

Speak in Terms of Goals

Inform your staff what the business goals are. Don’t tell them how to reach those goals. And if possible, don’t tell them a project deadline.

Just inform them of what you need to accomplish. Ask your staff openly and honestly, “What do we need to do to get there?”

And when they tell you, believe them.

Plan “Until Meteors”

After listening to your staff, figure out how to make the plan happen. Consider all of the variables, all of the options. Do this by asking yourself, “And then what?” until you have solved for every possibility you can imagine.

Stop when you’re asking, “What if a meteor from outer space strikes the data center?”

You also need to ask those “then what” questions about your people. While planning for staffing, you could ask, “So we’re going to need to have ten more developers. And then what?”

The answer could be to bring staff on for the initial project and keep five of them long-term. And then what? Then they’re probably not going to be developers anymore. They’re going to be part of the operation staff, doing bug fixes.

And then what? You’re probably going to have a plan for rotating those people out, because if they like developing, they’re not the same personality type as somebody who prefers to maintain code. And then what? You could move the interns up the ranks.

And operate this way until meteors. Do the same thing with processes. Do the same thing with technology. Simply ask, “Okay, and then what? And then what?”

Remove All Obstacles “Until Meteors”

Most of the time, what’s brought before a manager are the problems and complaints. You still must listen to what your staff complain about. And monitor what they don’t talk about, too. If you don’t see vacation time being taken, it’s a sign something’s wrong. It’s also not normal when employees don’t take sick time. A transformation project is going badly when people can’t manage their schedules.

So, make your staffers take vacations and call in sick when they are sick. You should have planned for it, anyway. And look for every way you can think of to back up your staff when they need you. Don’t whine about the budget, either. Remove every obstacle in the way of your staff, until meteors.

Transformation projects don’t have to fail. The technology is there – and the tech works. But it must be in line with the corporate goals. And it must be planned alongside your IT staff. Never try to be a nimble hare or a deliberative turtle, either. Keep the way clear, so your staff can get the job done right.