7 Real Reasons Why Tech Projects Fail

What is failure? It can mean to be unsuccessful in achieving your goals, to neglect to do something, or to cease to work properly. But failure can be measured relative to goals because goals are mutable. We can set goals in advance, change them mid-course, change them after the fact, and weight each element of the goal differently. This pre-hoc, ad hoc and post-hoc mutability enables us to adapt technology project goals and achieve success.

Technology Project Failure and Success

Let's consider failure in terms of the “Objectives from Key Results”—or OKR— approach. (I like OKRs because they have objectives and KPIs built in, and they're simple to state.) The classic OKR technology example is the one about putting a man on the moon by the end of a decade.

The project had multiple failures and six accidents, including the deaths of three astronauts on the road to success. Was the overall goal of the project achieved? Yes. Were there failures along the way? Yes. Were the six key failures along the way enough to consider the overall project a failure? No. Why not? Because the overall goal of the project was weighted more heavily than the failures. The overall goal was actually more important than human life because of the cold war and other critical issues of the day. This is a case of pre-hoc decisions and relative priorities. Relative prioritization can ensure that almost any technology project succeeds.

It reminds me of the Lewis Carroll's famous quote, “If you don't know where you're going, any road will get you there.” Often the road chosen for defining success is the one that has worked out, not the multiple roads that didn't. We must try to look deeper into technology project failure rates.

Let’s look deeper at seven key reasons for tech project failures in terms of change management:

1. Project not defined or defined enough

It might seem surprising, but we've got to start with "why." Set up your OKRs, and get alignment using Prosci’s 4 P’s Exercise. Sometimes that takes a while, but it's worth it. Think through the answers to, “Why are we doing this?” “Why are we doing it now?” and “What happens if we don't?” We need an alignment and a laser-like focus on that.

Al's Change Management Notes: Prosci's 4P's Exercise

2. Lack of leadership

Often tech projects are seen as “IT projects” and are relegated to the IT department. That's not right. IT projects are business projects. For success, we need a strong primary sponsor being active and visible, building a coalition, and communicating. And, for that primary sponsor’s peers, the leaders of every business function in the organization should be active and visible throughout the change. It can't ever be considered just an IT project.

3. Lack of accountability

This is related to number 2, when technology projects are seen as IT projects and suffer from a lack of accountability outside the IT department as a result. But again, IT projects that impact people are not IT projects—they’re company projects. And that means we need strong change management for success. Don't forget that return on investment comes from three key areas: speed of adoption, alternate utilization, and proficiency and use. That's all about adoption, so we've got to get people through their ADKAR process for these projects to be successful.

The Prosci ADKAR Model

4. Inefficient communication

Of course, in change management, communication is key. The number one difference between a regular tech project communication and a change management communication is that you will identify the audience first before crafting the message. That speaks to Prosci's 5 Tenets of Change Management. Organizational change is the sum of individuals making personal decisions to engage, adopt and use a change or not.

It's also worth remembering John Kotter's quote, “If you can't communicate the vision to someone in five minutes or less and get a reaction that signifies both understanding and interest, you're not yet done.”

Also, look at some of Prosci’s key communications research findings:

• You’ve got to use different methods and ensure that face-to-face communication, including virtually, is one of them.

• Remember that an employee's immediate supervisor, or people manager, is the best person to provide communications about what the change means for them.
• Senior business leaders must state the business reasons for the change constantly. Hopefully, the communicator is credible. The message should be open and transparent, and sent between five and seven times.

5. No plan or clear time scale, or poor planning and timelining

There's a key change management insight here. When is it that we start to get the business benefits of a people-dependent project? Well, the goal's going to be at go-live time, so that means we've got to have our people at Ability in the ADKAR Model. By go-live day, people have to be jumping out of their seats, metaphorically, saying, “I cannot wait for this new thing, for go-live day. It's going to help me in these ways. I'm Aware. I Desire to participate. I have the Knowledge, and I have the Ability.” It's only at Ability that we get start to realize our business benefits.

6. Lack of user testing, or failure to address feedback

From a change management point of view, we need to be laser focused on the end-user Desire element of the ADKAR Model. My metaphor is that no matter how fancy and technologically advanced the car is that's being constructed, if nobody embraces adopts and uses it when it comes out of the factory, you may as well have given everyone a bicycle.

7. Solving the wrong problem

Sometimes companies think they're creating something to address the problem, but it turns out they're addressing the wrong one. Start by defining the “why” up front and keep a laser focus on ADKAR, particularly the Desire element. What is it that people on the front lines of your organization are telling you is the problem? What is it you need to solve?

To Improve Is To Change

It has been said that 25% of tech projects fail outright, 20% to 50% show no ROI, and up to 50% need massive reworking when finished. But pre-hoc, ad hoc and post-hoc rationalizations and reprioritizations can help to make any technology project a success when you have the right elements in place. As Samuel Beckett once said, “Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.”