It was to be a great digital leap for Germany’s biggest discount grocer. Instead, after seven years and €500 million, Lidl’s new inventory management system with SAP is dead on arrival. Now everybody is asking why.
Big technology projects fail at an astonishing rate. Whether major technology implementations, postmerger integrations, or new growth strategies, these efforts consume tremendous resources over months or even years. Yet, as study after study has shown, they frequently deliver disappointing returns—by some estimates, in fact, well over half the time. These reports show that 25 percent of technology projects fail outright; that 20 to 25 percent don’t show any return on investment; and that as much as 50 percent need massive reworking by the time they’re finished.
And the toll these failed projects take is not just financial. These defeats demoralize employees who have labored diligently to complete their share of the work. Reputations are lost, and legal issues arise.
But the question is why. Why do so many technology projects fail—and fail so spectacularly? From my experience, it’s usually not technology problems that derail technology projects. I am of the opinion that most technology project failures can be attributed to poor management, while only a small percentage are due to technological problems. Reports seem to support my theory.
Below you will find the reasons for project failure that I’ve encountered most in my work as a project recovery consultant.
1) Poorly defined (or undefined) done
Project failure starts when we can’t tell what “done” looks like in any meaningful way. Without some agreement on our vision of “done,” we’ll never recognize it when it arrives, except when we’ve run out of time or money or both. Without a clear and concise description of done, the only measures of progress are the passage of time, consumption of resources, and production of technical features. These measures of progress fail to describe what business capabilities our project needs to produce or what mission we are trying to accomplish. Capabilities drive requirements. Therefore, without first identifying the needed capabilities, we cannot deliver a successful project, and it will end up a statistic, like all the other failed projects.
2) Poorly defined (or undefined) success
Besides not having defined what done is, one of the more common problems I see with IT projects is an ill-defined goal or definition of success.
A project can only be successful if the success criteria are defined, ideally upfront. Unfortunately, I have seen many projects that skipped this part completely. When starting on a project, it’s essential to work actively with the organization that owns the project to define success across three levels:
1) Project delivery
2) Product or service
3) Business
A company will say they want to improve customer service, for example, but no one ever bothers to say what that looks like. Shorter call times? Fewer calls? Higher customer satisfaction? How will you know when you’ve succeeded? If you don’t know, you’re doomed to fail.
Related: When is my project a success?
3) Lack of leadership and accountability
Too often, technology projects are deemed “IT” projects and relegated to the IT department, regardless of what the project actually is. But for any project to work, it needs strong leadership from the top down. If a project doesn’t have buy-in and support from C-level executives as well as specific department leaders, it’s difficult to get employees on board and hard to know who is in charge when leadership questions arise.
The moment projects are dubbed “IT projects” and left to the IT department, a lack of accountability can also develop. Executives may wrongly believe that they can’t understand what’s happening, and leave it to the tech guys to figure out. This is a mistake. If your tech team can’t adequately explain what’s happening on the project or why it’s needed, that’s a huge red flag. And if the executives aren’t driving the project and holding the team accountable, it can easily spiral out of control.
Related: How to establish an effective Steering Committee (and not a Project Governance Board)
4) No plan or timeline
How can we get to “done” (see above) on time and on budget and achieve acceptable outcomes? We need a plan to get to where we are going, to reach done. This plan can be simple or complex. The fidelity of the plan depends on our tolerance for risk. The complexity of the plan has to match the complexity of the project.
Without a clear timeline and plan with milestones, any project (but technology projects in particular) can wander off the original path and meander through many detours and dead ends. A clear plan and someone to keep track of it is vital for keeping these projects moving forward.
Also, the famous watermelon reporting (green from the outside and bright red from the inside) is far more likely to happen when there is no clear plan and measure of progress.
“Plans are useless, but planning is indispensable.” – Dwight D. Eisenhower
5) Insufficient communication
As mentioned above, someone on the tech team needs to be able to explain the project details regularly to the “non-tech” executives and other stakeholders. It’s vital for someone on the team to have strong visualization and storytelling skills in order to communicate clearly and regularly what’s happening with the project.
Related: Outsourcing technical competence? and 10 Principles of Stakeholder Engagement
6) Lack of user and performance testing, or failure to address feedback
The thing about technology projects is that ultimately, they’re made for people, not machines. A lack of real-world user testing before launch is a common problem. The software engineers, solution architects and business analysts think they know what users want, but users may have an entirely different set of needs and problems. Once user testing is conducted, the project has to prioritize addressing the feedback, or the end user won’t be happy—and ultimately won’t use the technology created for them.
On a similar note it is essential to test under expected load very early. Even the best system won’t be used, or be very ineffective, when it is just too slow.
Related: Start your project with a Walking Skeleton and It’s never too early to think about performance
7) Solving the wrong problem
I’ve seen this time and time again with IT projects: companies think they’re creating something to address the problem, but it turns out they’re addressing the wrong problem. In our customer service example, if the company decides that shorter call times is the metric for improved customer service, employees become incentivized to get off the phone as quickly as possible, which may or may not actually improve customer service. Yes, call time decreases, but customers may be even less satisfied than before.
“We fail more often because we solve the wrong problem than because we get the wrong solution to the right problem.” – Russell L. Ackoff
Related: Understanding your problem is half the solution (actually the most important half)
8) Trying to adapt standard software to business processes instead of the other way around
Adjusting standard software to quirky business processes is a recipe for disaster. Going back to the Lidl SAP project, apparently one of the biggest problems was a “but this is how we always do it” mentality at Lidl. Changing the software necessitated reassessing almost every process at the company, insiders say. But Lidl’s management was not prepared to do that.
Unlike many of their competitors, Lidl bases its inventory management system on purchase prices. The standard SAP for Retail software uses retail prices. Lidl didn’t want to change, so the software had to be adapted. Many more accommodations had to be made, and the more changes there were to the code, the more complex and more susceptible to failure the Lidl software became.
Performance fell, and costs rose. Altering existing software is like changing a prefab house—you can put the kitchen cupboards in a different place, but when you start moving the walls, there’s no stability.
“Something I learned in ERP for dummies: Don’t customize software to your process unless the process is your competitive advantage.”
9) Continuing to pursue bad ideas
In Hollywood, they say it’s easy to make a bad film from a good script but impossible to make a good film from a bad script. Though you won’t always recognize a bad idea straightaway, once you do, never assume that you’ll make it work or believe that you’ve put in too much effort to change course. The sunk cost fallacy is real.
For large or high-risk projects (what is large depends on your organization) it should be mandatory to do business case validation before you dive headfirst into executing the project. The minute you recognize that an idea won’t work, you have to pull the plug. It’s usually impossible to fix a bad idea, and you’ll only waste time, money and energy trying to put lipstick on a pig.
Related: No validation? No project!
10) No real decisions and death by committees
A project often has multiple parties interested in its outcome and groups may even have divergent goals and expectations. I once spent months working with multiple enterprise and solution architects on a new data analysis and modeling platform, only to have our carefully crafted design dismantled by the company’s various heads of department demanding changes to meet their individual needs. Our problem was that we failed to establish who really owned the project and therefore didn’t deal with potential conflicts and disappointments in advance.
Feedback and governance is an essential part of any project. But decision-by-committee rarely leads to the best outcome. Every project should start by establishing clear, workable goals and give one person the ultimate ownership and accountability for meeting them.
Related: Many decisions are no decisions (and this makes projects difficult)