Why IT Projects Fail and How to Avoid the Headache
In a 2017 report from the Project Management Institute (PMI), 14 percent of all IT projects fail. However, this metric only tells part of the story. Of the projects that didn’t fail outright, 49% were late, 43% exceeded their initial budget, and 31% didn’t meet their goals.
According to PMI, there are six factors that must be met for a project to be deemed successful:
- It is delivered on time
- It is delivered on budget
- People use it
- The stakeholders are happy with the solution
- All goals are met
Here are the three most common pitfalls we’ve identified and how to avoid them:
1) Unclear Project Objectives
It is a problem as old as time – an organization has identified a pain point and begun efforts to formulate a solution. The truth is, many companies embark upon more initiatives than they should. This causes projects to suffer on the front end when all of the dependencies and goals are determined. Without a clear backlog of goals and their respective priority, a project is doomed from the start.
The solution: It is the role of the executive team or project sponsors to determine the organization’s long-term goals and the strategy for reaching those goals. It is important that these goals are clearly defined so that the project may be aligned with these goals. A good practice is to rank project priorities so that the solution can reflect these values.
2) Lack of buy-in from end-users
You’re fed up with your current ERP system. It is buggy, it’s old, and it doesn’t integrate with your shiny new Google for Business suite of products. You determine that it’s time for a change. That’s just fine; most initiatives are birthed from the mind of an executive. The problem only arises when the end users lack the input for this new system. When management fails to include end-users in the planning phases those users will naturally lack buy-in.
The solution: Establish a core group of end-user representatives that can echo the sentiments of the entire group. This will accomplish two things; it will solve the issue of buy-in as well as the added benefit of identifying features that management may have overlooked.
It is important that an organization do more than its due diligence to identify as many risks as possible.
3) Unexpected Risk
Risk can rear its ugly head in a variety of ways. Let’s use a software implementation project as an example; given the intangible nature and uniqueness of software, it is inherently difficult to estimate and create a schedule. In software projects, we tend to see requirements inflation. These requirement inflations typically consist of features that were not identified at the beginning of the project – this has the potential to threaten timelines and estimates. It is a fact of IT that you can never identify all of the risks at the onset of a project. So what is there to do?
The solution: Obviously, it is important that an organization do more than its due diligence to identify as many risks as can be foreseen. For all of the other problems that will inevitably show up, it is important that unforeseen risk is built into schedules and estimations. This “wiggle room” when scheduling and estimating will alleviate most if not all unforeseen risk.
