Last Fall, I wrote an article for Dice.com about the
top 5 reasons ERP projects fail: that was in response to news of a specific project shutdown. However, the topic as to why IT projects in general seem to be so failure prone is worth exploring as well.
As far as hard statistics as to how many IT projects succeed or fail; it's difficult to get a clear picture. Part of the reason this is the case is that often when a project is clearly going to fail it gets "redefined" rather than cancelled. That redefinition represents a re-baselining effort that dramatically scales back expectations with the hopes that the reduced scope can be met. Sometimes that works, other times re-baselined projects are later cancelled anyway. If our measure for success was the original set of expectations associated with a project, the likely rate of IT failure would be extremely high - perhaps in excess of 50% of all IT projects.
 |
| In IT, building bridges to nowhere is fairly common, but no less costly... |
This is a rather incredible statement of course, especially if we compare IT with most other types of projects across industries. What exactly does this level of failure really indicate though? It could represent any or all of the following factors:
- That the expectations of the stakeholders were out of touch with the reality of what their IT provider organizations could manage.
- The level of complexity was not properly gauged or managed.
- IT is changing so fast now that a project defined last year might require major changes if it is still 'in motion' this year.
- The project was driven more by the perception of some need than the reality of a need. This of course refers to all those projects that are spun up in response to industry hype without a clear set of requirements.
- The technology assumptions (driven from the expectations) were hastily made and then never challenged later (or perhaps more appropriately - no challenge was permitted).
While these five factors might be taken as the reasons that so many IT projects fail, they are in fact only the backdrop for the real reasons. Our focus needs to be directed to the fifth bullet point above - assumptions. Thus the five reasons we're focusing on here are related to why failure occurs after a project has been launched.
Even if a project wasn't launched under the best of circumstances, it still has a chance of succeeding if it is flexible enough. But what makes a project flexible? Is it the application of some Agile methodology or some other unique lifecycle management approach? Maybe not. Let's look at the real top five reasons that IT projects fail once they've begun:
- An inability to examine or challenge assumptions.
- A "silo" mentality.
- The inability to compromise.
- Technology-centric rather than capability centric perspective.
- Poor role definition and lack of project dynamics.
Let's look at these a little closer now...
1 - As noted previously, the inability or unwillingness to challenge assumptions is a huge issue on many projects. This is a problem precisely because of the manner that many projects get spun up (the factors listed previously). This is a little different than the traditional dialog on 'requirements' that's heard when explaining Agile methodology because in that conversation the focus is on the detailed design. Here the focus is on the big picture assumptions which in truth are much harder to face or deal with. In any project, there are perhaps less than 10 issues which will determine the success or failure of the effort. You may have another 10,000 detailed issues or requirements in a backlog and each of those may be dealt with successfully yet still not save the project from failure if the core issues aren't addressed. Those core 10 or so issues are almost always associated with the initial assumptions connected to the project.
Those types of issues include things like the original intent of the solution, preliminary technology choices and solution architecture decisions as well as organizational approaches. There is no one correct mix of all these types decisions that ensures a successful project and that's precisely why those decisions should be reexamined on a regular basis. In other words, we shouldn't view the first hectic weeks or months of a larger initiative as infallible exercises in perfect thought or planning, but for some reason, many people do.
2 - The Silo Mentality. This refers to projects that become over-compartmentalized; where each sub-unit views itself more or less divorced or separate from every other. While everyone on a project needs to understand their roles (point 5) by the same token they must also all share responsibility for the outcome. There is nothing sadder and less justified than internal finger-pointing when failure occurs. This is a problem that is easily corrected with the right leadership and project structure. Whenever you begin hearing various players within a large project stating that issues relating to them are someone else's concern or responsibility then you know the project has developed this problem.
3 - The Inability to Compromise - We talked about this in a previous post from the perspective of team leadership; here compromise has an even broader context. Compromise here represents compromise between teams, by leaders - as well as compromise on large, tough issues. Lack of compromise is one of the chief symptoms of an 'inflexible' project. People will always have excuses and cite deadlines yet invariably where compromise fails to occur, deadlines are shot anyway and often the entire project ends up being cancelled.
4 - Technology-Centric Projects - This may sound funny coming from an IT geek however it is nonetheless valid. Let's look at
Big Data as an example. What exactly does that new technology category mean to a business that wishes to jump onto the hype bandwagon? Does it imply faster data systems, better storage management or is it tied to specific Use Cases associated with that organization? If the expectations end up looking just like a Gartner article on who's doing what instead of Use Cases that illustrate how it can be exploited in your organization then you might say you've got a technology-centric project. The fact that you think everyone else is doing something shouldn't drive your decisions. If you've been stuck with a hype driven project then use the initial period to re-tune it to ensure that its aligned to your business. If you find that it's not then have the courage to reverse course if necessary (the earlier, the better - you can always come back to it later).
5 - Poor Role Definition and Project Dynamics - How you build the project is usually just as important as the underlying assumptions behind it. Understanding roles and how those roles and groups ought to work with one another is important. For example, an architect and a tech lead are two very different roles - one owns the technology the other designs the solution (completely different perspectives). Yet many organizations regularly confuse those two roles. Also, there's often not clarity in regards to who has oversight or leadership across groups. This last point relates 'project dynamics.' A flexible project still needs leadership - but leaders who act as facilitators rather than strict commanders. And the folks they lead need to be able to form working groups that have clear purposes and escalation paths to ensure corrective action can occur when needed (and not just on the little issues).
There are of course other factors involved in the failure of complex IT projects, but a large chunk of what tends to happen can be mapped to the issues raised in this article. In a future post, we will look at some of the warning signs associated with a project 'at risk."
Copyright 2013, Stephen Lahanas
