Project Assurance
Countless papers and articles were written on project success rates and why projects failed. All experts agreed on one thing: surely we have learned our lesson and things will be different moving forward.
I am not so sure about that.
Fast-forward ten years to 2010. The economic downturn and great recession have had significant impact on enterprise systems as many organizations are facing the need to upgrade. While the economy remains in uncertainty, spending on enterprise applications and IT has not changed. Most organizations have halted spending on enterprise business applications, because for the most part, the business can get by with what is in place.
In actuality, the longer an organization waits to upgrade its technology, the more the upgrade will cost. Also, similar to Y2K, several driving external factors are influencing the enterprise software decisions and will likely play a role in your next technology project: consolidation and shared services, software as a service and outsourcing.
Given the economy and other external influencing factors, it is likely that you will have a big project in your future. It may be an application upgrade, a transformation project or a move to an outsourced platform. In any event, it will be complicated. Many organizations are internally integrating systems that cross traditional business functions and externally have more vendor partners involved in technology projects. The result? A complex soup of internal and external project team members, motives and goals.
And here is that pesky statistic again: despite the cumulative knowledge gained from decades of implementing enterprise systems, industry analysts are still predicting that projects have a 70% rate of failure. That means you only have a one in three chance of succeeding.
On closer examination, we really shouldn’t be surprised. The reasons that projects fail are the same today as they were ten years ago: lack of top management commitment, unrealistic expectations, poor requirements definition, improper package selection, gaps between software and business requirements, inadequate resources, underestimating time and cost, poor project management, lack of methodology, underestimating impact of change, lack of training and education, and last, but not least, poor communication.
I can chalk up what happened with Y2K implementations to the fact that we really didn’t know what we were doing or to the oppressive deadline that forced things to happen too quickly. But today, we are still seeing 70% failure rates – and if these are caused by the same factors, something is fundamentally wrong.
Fifteen years from now, are we going to look back and wish we had done things differently?
Read more in our white paper: Preempting ERP Project Failure.
