The Top 5 Reasons for Failed Software Implementations

On paper, software implementations can have a lot to offer. Take the example of project management software that promises to ease the planning and tracking of complex projects, optimize and balance the allocation of resources, and facilitate alternative plans. The good news is that these promises can all come true! The condition of course is that the implementation of the software respects various principles and avoids certain problems.

But not every software implementation is crowned with success – either immediately or even eventually. What then are the top reasons and pitfalls why they fail and how to avoid them? Here’s our take on a category by category, blow by blow basis.

1. Lack of Management Buy-in

While it’s just conceivable that a major software implementation can benefit an enterprise even if management support is absent, you’re likely to feel like you’re swimming in molasses: very tough, very tiring and it takes years to get anywhere. Management needs to be involved from the outset to ensure that the project is aligned so it contributes significantly to overall business objectives, to participate in the identification of business champions, and to hold the right people accountable for implementation success.

2. End-users Absent from the Implementation

While management needs to be there to nail the business benefit, the people actually using the software (and therefore triggering the afore-mentioned business benefit) are likely to be a different group. Keeping them out of the project until the system is installed and then suddenly presenting them with the log-in screen is a horribly effective way of building up resistance and resentment from the very people the software should be helping. Involving users from the beginning and having discussions of user needs, considering their comments and fostering the perception among these end-users that this is also their project, is far more constructive.

3. Underestimating or Mis-estimating Implementation Time

There is an unhealthily wide choice of ways to do this, ranging from the direct miscalculation or omission, to planning backwards from a drop-dead completion date, through to suddenly tripling the number of IT engineers to try to make implementation go faster. Any of these approaches will typically end in tears, or worse. A common variation on this theme is to cheat on testing (as in skipping it) when it becomes apparent that the original software implementation schedule cannot be met – this is a short term hack that can do long term damage.

4. Skimping on Technical Competence

A word of advice – don’t. If the technical competence you need to get the software working well is not available in-house, then talk to an external provider (for example, LoadSpring for P6 project management). A good provider will help you accomplish your software implementation cost-effectively, and even assist you in transferring competence and know-how to your organization.

5. No Change Management Process

Plan for it, prepare for it and get all the key people involved, because if you don’t you’re going to get into trouble. The bottom line is that change is bound to happen. What you need is a good process for dealing with it.  The crucial thing is to know beforehand how to handle such situations so as to minimize negative impact on the software implementation.

And now? Use your highlighter to mark anything above that might represent a risk to the success of your own implementation efforts. As they say, forewarned is forearmed!