Avoiding the pain of major software purchases

The pain of a major software purchase

This project was supposed to be easy...

Credit: 123RF Stock Photo

Major software purchases can cause significant pain to the organization, employees and, of course, the project sponsors. We look at why this happens, and how to avoid that pain in the first place.

Cloud or off-the-shelf: major software purchases like ERP seldom deliver all that is hoped. The first signs of trouble are when the implementation does not proceed as planned. When the software finally goes into production, the results are distinctly underwhelming. While outright failures happen, partial failures are much more common. These projects suffer from many or all of the pains below:

  1. Implementation takes significantly longer than planned
  2. Costs are substantially over budget
  3. New software disrupts business more than hoped
  4. Expected functionality is missing
  5. Users are unhappy
  6. Anticipated cost savings are unrealized
  7. Inferior or even negative ROI based on the TCO

While egregious examples surface in the technical press, this is only the tip of the iceberg. Most organizations don’t like talking about their failures and do their best to hide them. These partial or outright failures can be career damaging, especially for sponsoring executives. People often do their best to move on to new projects, or even change companies before the full extent of the problem becomes apparent.

Root cause

The root cause of these pains can be traced back to an inadequate requirements analysis. Requirements that should have been discovered in the analysis phase at the start of the project are instead found during implementation. When the new software does not meet these “new” requirements out of the box, workarounds need to be developed. It is the developing of these workarounds that delays the implementation. Since major software implementations are usually carried out by consultants, this can substantially increase the costs of the implementation.

The law of unintended consequences

Many project managers are forced to defer work to save time and money when they see the change orders and associated costs accumulating. When the software finally goes into production, it causes a much greater disruption to the business than was hoped because expected functionality is missing.

In addition to learning the new system, users now have to face the fact that the new software does not even come close to the hype. Serious functional holes mean much more work for them. Instead of the promised efficiencies, they find they have to work harder and longer to get around the missing functionality. It is no wonder that users are unhappy and complain loudly!

Another unintended consequence of an inadequate requirements analysis is that the organization does not select the software that best matches their particular needs, leading to more workarounds that must be developed. Sub-optimum functionality means many of the expected benefits of using the software are missing. For the same reasons, promised cost savings remain unrealized. Since the project was usually sold on these benefits and cost savings, this over selling and under delivering leads to further dissatisfaction.

The final straw on the camel’s back is when the ROI is examined. Implementation cost more than expected (maybe additional software modules had to be purchased) and cost savings didn’t materialize. Some people, like the CEO of Foxmeyer Drugs that was bankrupted by a failed ERP implementation, regretfully conclude the project should never have been undertaken in the first place.

Avoid the pain

Whether you do the work during the implementation or the requirements analysis, the work is going to be done. Therefore, move the work to the requirements analysis phase at the start of the project and use the benefits of a comprehensive requirements analysis to your advantage. Remember that requirements are to software selection as foundations are to a building. We all know what eventually happens when foundations are inadequate.

Use the technique of reverse engineering features into requirements to ensure you find all possible requirements, even unknown ones. With a comprehensive requirements analysis, you have set the stage to select the software that best fits your particular needs. In spite of what vendors tell you, no software is perfect! Use the gap analysis to set realistic organizational expectations. Realistic expectations are critical - if users get what they expect, they are not unhappy!

A comprehensive requirements analysis contains every single significant functional requirement. It also has how important each requirement is, to whom it is important and why it is important. Pass this information over to the implementation team so they can develop an accurate project plan. If a good job has been done, no new significant requirements will surface during implementation.

A comprehensive requirements analysis at the start of the project minimizes the pains of a major software purchase and leads to a successful production rollout. Cloud or off-the-shelf software, the project will be within budget, on time and deliver the expected benefits. Never forget that successful projects pave the road to a successful career.

This article is published as part of the IDG Contributor Network. Want to Join?

CIO.com and Drexel to honor 50 analytics innovators. Nominate your project today!
View Comments
Join the discussion
Be the first to comment on this article. Our Commenting Policies