A lot of people shy away from talking about failure because they like to pretend that it doesn’t happen. But tech initiatives, even small ones, have a lot of moving parts, so there are quite a few reasons things can go awry.
I wanted to write about those reasons and how you can fix them or, better yet, prevent them.
But first, let’s make sure we’re all working from the same definitions.
For the purpose of this blog, a tech initiative is defined as any multi-step project or initiative where change management and tech are central, and the goal is increasing the value you get from business technology. (Yeah, that was a mouthful.)
Next, what constitutes failure?
I thought about this definition quite a bit. I decided that failure occurs when progress toward the desired result is not possible—or is longer possible—or the cost of it outweighs its value.
Failure can occur in a few ways.
For example, you might discover your actual needs differ from your understanding of your needs at the beginning of the project. That could happen in the aptly named discovery process or because your understanding of the technology was not accurate.
It’s also possible you set an unattainable goal. However, many times, while you may have a goal that’s technically unattainable, you can still inch very close to it. For example, you can work toward real-time data as long as you realize that there will be some level of lag that’s dependent on how quickly the information gets into the system.
That leads me to the #1 client mistake I see coming into an initiative: they put the tech before the business process, rather than vice versa.
Yeah, yeah, I know—if you’ve read another Lift blog or listened to an episode of The RevOps Show Podcast, you’re probably thinking, “I’ve heard that before. Many, many times.”
And we’ll never stop saying it.
That’s because the key to success is ensuring that your business process drives your tech. You simply can’t skip this step.
If you do, at best, you’ll waste time and money. At worst, you’ll totally crash and burn.
And let’s face it: most of us, even those of us who know better, will usually think something like, “I need an email automation tool!” It's easy to fall into the “shiny object trap” when you haven't thought through the business process.
That’s usually when you need to take a deep breath and switch to a jobs-to-be-done-focused mindset that ensures you are thinking about the result, rather than the tech.
For example, if you think you need something to automate email but haven't thought through your email strategy, then you could end up with a tool that schedules emails. Great—but you might soon realize it doesn’t have the personalization you really need.
Even if you’re completely confident about your real need, dig a little deeper into the job to be done. Once, a client told us with utmost certainty: “We need a rewards platform.” However, when we dug into the business process, what they wanted was to track referrals, which they could do with a CRM.
2. Not involving the right people in the process
To understand the entire process and map it correctly, you must involve the people who do the job. If you don’t know and understand every step along the way, you also won’t know what jobs need to be done. No one person knows everything that’s involved, so this must be a collaborative process that leads to a greater understanding of your current process. You must have a handle on that process in order to successfully “hire” tech to facilitate and improve it.
3. Not clearly envisioning success
After you understand the status quo, think about how you’d measure success. If you don’t have a clear picture of what that looks like, how will you know if you’ve achieved it? You want to be sure you have a measurable goal.
When I'm doing this type of thing, I close my eyes and envision myself in the future. What's it going to look like? I document that. I also think about what things would be like in the future if nothing changed.
4. Believing the tech implementation is the end
It’s easy to forget that a tech implementation is not just tech implementation. It’s also a change initiative, which means you’re changing the process and way people do their work.
Sometimes clients panic because it’s a month after the launch, but employees haven’t fully adopted the tech. That takes time, training, and effort; it isn’t instantaneous.
Remember the bullet above when I said to envision success, so you can measure it? Behavior is an important part of that process. Ask yourself what actions constitute success.
Once those are clear, think about how you’ll need to train employees to achieve those goals. The two go hand-in-hand.
5. Over- or under-focusing on automation
Not to sound like Goldilocks, but you want your focus to be “just right.”
People who overfocus tend to think that automation is a magic wand that will solve every issue. On the other hand, you didn’t hire technology to be a very expensive spreadsheet.
You should expect a realistic level of automation that will serve your needs. That may be something as simple as pulling data into a graph for easier visualization.
6. Too few feedback loops
Your process should include opportunities to provide feedback, so you can identify impact and assess whether your implementation is having the effect you planned or hoped for. (Remember that from #3?)
If your project lacks identified feedback loops or enough usage of loops, you're essentially flying blind when trying to assess performance and effectiveness.
7. No appropriate tech process
Some companies have no process for implementing tech (which is an issue they’ll want to correct asap). Some companies do have a process, but it won’t be the right one for this implementation.
Other businesses may be set, although it’s a rare group that has the right process for implementation and fully understands every step—from digging into the business process to adoption and utilization.
Most companies benefit from partnering with a company that implements technology. It’s important to find a partner with experience in both exploring the business process and driving utilization and adoption. And, of course, you need someone who will help you dig into the real job to be done.
8. Failure to prepare for problems
Anyone who tells you there won’t be problems is naïve or lying. There will be, especially in a large project. However, if you did the necessary blue work, those problems will be much smaller.
Try to anticipate what could go wrong and document some mitigation techniques. For example, do you need to ensure your IT department has the necessary resources and understands the timing so you can make your launch date?
As you’ve probably gathered, most of these mistakes spring from a lack of preparation, including failure to map what you currently have or envision your end result.
I believe most of these spring from putting the tech before the business process, which is why it’s ranked at #1. It’s crucial to really dig into the process and discover what jobs are to be done and why. Then, and only then, can you start to think about solutions.
