Project failure usually means the project missed it’s delivery date or exceeded the planned budget. It could also mean it did not meet the client’s expectations, but we will focus on delivery timeframe and budget in this article.
Before we start, just a bit of background: I’ve been involved in hundreds of software installation projects in my career. The ten reasons listed below are what I’ve seen as the most prevalent causes of failure.
Software installation projects fail for many reasons. Most of the time, failure can be prevented if you are aware of what to watch out for. Here are ten key reasons why many software installation projects fail:
1. Failure to check vendor references
One of the easiest things to do but is often bypassed is to check a software vendor’s references. Ask for a complete list of references and talk to or visit several clients to validate what you are trying to accomplish is actually being done by their clients. Solid client references equals credibility in my book.
Ask for clients who are actually using key features of the software that you have deemed important for your business. Too many times, new features are described to be part of the vendor’s functionality but when you start implementing the software you find it works very different than how you thought it did. A client reference will often provide valuable insight that helps you understand these nuances.
Take time to check critical feature/function and talk to clients about their implementation experience with the vendor. If there are problematic issues, learning about them before starting the installation is when you want to hear about these type of issues.
2. Unrealistic expectations
Often, operational units of the company are dead set on certain functionality without even understanding what and how the feature actually works in an operational setting.
Another scenario is the concept that the new software will eliminate all of our old problems and make it all better. More often than not, there are no silver bullets that solve all your problems, , , or if they do, they create additional issues you must deal with. You want to try and understand these dynamics early in the project.
A third situation exists when users want so much feature/function, they don’t realize the amount of complexity they may be introducing into their work environment.
Take a close look at what the expectations for a new software program are and be sure the due diligence investment is made to fully understand the ramifications of these decisions. Learning these implications at the front of the project is much easier than learning mid-stream or at the end of a project, , , that’s usually painful.
3. Lack of planning
Counting on the vendor to handle the project is the same as the ostrich burying his head in the sand when trouble approaches. It doesn’t work.
The IT department and the user departments must be fully involved in the project. Clear tasks should be developed with specific responsibilities, timeframes, and prerequisites.
To insure success, there should be a project leader on both the vendor side and from your company. Planning is a dynamic process, not an event. Once the project is planned and started, you have to focus on it consistently and adjust as needed to meet your stated objectives.
4. Lack of testing
The quick way to install any software is to simply load the software, build the files, and “turn it on”. That’s also the quickest way to disaster. It may surprise you that this actually takes place in many companies.
Testing and validating your assumptions is a critical step at every juncture of the installation. You probably need to:
- validate master file data
- balance and verify transaction data
- test certain features to validate configuration settings
- test certain operations to determine operational processes to use for productivity and best practices in using the new software.
Test plans should be defined so you know that every aspect of the new program works like you think it should when you “go live”. Otherwise, expect lots of surprises, , , and these surprises are generally not good ones.
5. Lack of committed resource
Lack of committed resources can occur at any stage of the project. It can occur from the vendor, from the User Departments, or even from your IT Department. It can also result from unforeseen circumstances such as illness, reassignment, change of business priorities, etc. Losing a key resource can create a huge obstacle to the project and jeopardize timing and cost.
When developing the project plan, be sure to work through the staffing plan for both critical skill and timing of when those skills are needed. There is usually some flexibility in a big project but watch this one closely.
The project manager needs to anticipate needs constantly to insure the project is getting the right resources at the appropriate time to keep the project on track.
6. Not establishing specific milestones
Large projects need to have specific deliverables that will be met at certain timeframes, , , key milestones help you gauge performance and stay on track. Part of the reason you do this is to help the team realize the success being made but also to set a framework that helps you manage big bottlenecks and to get certain prerequisite steps completed that position you to move forward.
7. Unaware the project is getting off schedule
You can’t be aware of everything taking place, or not taking place if you aren’t having regular project status meetings. They don’t need to be long drawn out affairs but you need to validate on a regular basis (I like weekly) that people are getting the things done that they are assigned to get done. Otherwise, there is a high probability the project is getting off track and will not meet its due date.
8. Not anticipating the bottlenecks
Bottlenecks are everywhere. A good project manager knows how to sniff them out and to anticipate issues that may lead to potential bottlenecks. Eliminating one bottleneck leads to two others which might even slow the project down more.
Great project managers are really good at identifying bottlenecks and proactively putting things into motion that either eliminate them or reduce their impact to the project.
9. Insufficient training
Training on how to use and manage a new software application is critical. In large complex applications, configuration management is especially important because the setup can have all kinds of ramifications and can even cause a department to lose hundreds of hours of productivity or large amounts of data.
You should include your smartest and best people in the configuration setup and management training and limit it to just a few people. You must determine how business application decisions will be made and who will implement such changes when it means changing the setup files or certain data definitions of your master files.
Large companies will have data administrators who are accustomed to these issues, but small companies are often surprised by the amount of work, knowledge, and effort required to manage a new software application.
10. Plan that is too aggressive
Strong project managers know to build in buffers that help them deliver a project on time. They know that things will happen and that you are going to need extra time and extra money at some juncture of the project.
Projects that are built with schedule and staffing with expectations that everything will go just as planned are doomed for failure from the start. Murphy’s Law of “if it can go wrong, it will go wrong” was probably created by a project manager.
Summary
There are many other reasons that will cause a software implementation project to fail; but if you address this list of ten, your odds of a successful project will be very good.
ITLever™ 