Why IT projects fail: changing client expectations for technology vendors

Client expectations for their software and technology providers have got to change.

Major technology implementations are significant investments: money, people taken away from their day jobs, and opportunity costs. With all that at stake, why is there such an extreme lack of accountability for specific business results?  It is utterly baffling to me. How often do clients get demonstrable business value — features and functionality that actually make their business better in terms of customer relationships, revenue and profit? Not very often. There is not much good about the current recession, but here’s one potential silver lining: it is forcing more companies to think of IT decisions as business decisions that need to demonstrate an auditable link to driving growth and revenue for mission-critical operations.
Photo by hans.gerwitz
The rate at which business technology implementations are considered failures is north of 70%, according to multiple studies from McKinsey, AMR and Forrester. What would you do with a stamping press, paint line or vendor that failed 70% of the time?

Vendors simply have to stop BSing. And clients have to quit letting them get away with it. Technology, and software in particular, has to work as advertised, or clients should get their money back so they have a chance to work with something better. We can’t afford the old way anymore.

Two pitfalls that doom business technology projects: requirements gathering and the old “over-promise, under-deliver”
When clients change their expectations and clearly define the business outcomes by which the project must be judged, we clear the way to improve formative stages that are a two-step to frequent failure: requirements gathering and promised results.

Requirements gathering
Here’s something that happens at way too many companies: the vendor puts their client’s team in front of a whiteboard and encourages them to dream up software in a vacuum. They really don’t know what they want or the capabilities of the software in context of their actual business processes. They don’t know the capabilities of what’s out there, nor are they, during this critical process, asked to see their company in terms of the software. Their understanding is limited to what they know from their day-to-day experience and whatever chock-full-of-functionality marketing brochure they’ve seen last. In other words, they are limited to what they know, and that limited knowledge drives the outputs from the requirements gathering sessions. But what about what they don’t know? What about the possibilities? If there is a  software tool functionality that would eliminate three steps from a process, wouldn’t you want to explore that impact?

Requirements planning should be done within the context of the technology platform chosen — in this case, the software. Wouldn’t it be more powerful if you could react to the software by visualizing your company within it?  What if you could react to what works and what doesn’t in context of your actual job and responsibilities? Wouldn’t that be more meaningful than a whiteboard?  Wouldn’t you feel more ownership of the end product if you got to provide informed, constructive feedback and really help your team decide which features work and which are a waste of time?

Once we’ve made our choice and undergone implementation, the technology should then do what we all agreed it was going to do. When it doesn’t, this is when the “partnership” to which both sides professed early on starts to fall apart. Rather than focusing on addressing the problems or the misunderstanding, usually there is an investigation, fingers are pointed, and then the negotiations begin as to the solution. Not surprisingly, the new solution requires yet more money, and somehow, despite the best corporate negotiators, the customer ends up footing the bill. Only the software industry (and maybe the finance industry over the last couple of years) can look people in the eye, tell outright lies as to what is really going to happen, and then make the customers pay for the result.

Until the people who actually write the checks start refusing to perpetuate this dynamic — you demand more, you demand measurable results, you demand outcomes and refuse to pay if your investment does not deliver — then the majority of these projects will continue to be failures. Ultimately, the customers will lose an opportunity to become more competitive, both domestically and internationally. And that is a large and painful cost that rarely is identified and discussed. Changing our expectations and avoiding these pitfalls sets the stage for IT to truly improve your business.

The first step is simple: decide that you deserve better and act to make it happen.

One thought on “Why IT projects fail: changing client expectations for technology vendors

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>