Stop me if you’ve heard this… Your company purchases packaged software from a talented vendor, installs it and then tries to use it but never realizes the business benefit that was expected.  You wanted working software, but ended up with shelfware! In this blog post we’ll discuss some of the ways that packaged software purchases fail and what can be done differently to be successful.

I’ve Purchased the Software, Now What?

If the IT project to install the software was successful, but your company is not receiving the full benefit of the software, then the project was still a failure.  There are many reasons why your organization may not be receiving the benefits it deserves.  Perhaps the users of the software weren’t properly trained on the software or changed business processes.  Maybe the software never made it out of the pilot phase.  Unfortunately, there are times when the software vendor overcommits or oversells the capabilities of their software. 

Let’s look at a few more ways why these projects fail in the first place.

• Software not used because it does not fulfill the original identified business need.
• Software application and/or technology looked innovative and we thought we needed it, but it did not fulfill a specific identified need.
• Software is not fully used because it is not understood.
• Software cannot be implemented without extensive customization.
• The application was never deployed to production (e.g. still in pilot or proof of concept phase) or was implemented, but not well or completely.
• The software was implemented and works, but is not connected to other systems.

Although there are certainly other reasons why a packaged software project may fail, luckily the ones listed above can be avoided very early on in the project.

Work Upfront = Success Later

First and foremost, the project needs a strong Business Case. More than just getting approval for resources, time and money, the Business Case is essential in communicating what the business need is.  Without having a clear understanding of the problem being solved you risk purchasing software that does not address the core need.  At each step in the process, you should be able to trace back to this core business need.  When you see software that looks “really cool”,  a quick comparison to the Business Case will reveal if the software will truly satisfy the need or will need to be shoehorned into the business to be used.

The next step that is often discounted is whether or not you really need to purchase a packaged solution. In many cases, the answer will still be “yes”, but by doing this due diligence you gain a better understanding of your own IT organization’s capabilities.  This make/buy decision process should help describe the enterprise architecture and where a solution may fit.  It may also identify existing systems that will eventually need to be integrated with.  Lastly, during this process you will be evaluating the packaged software market, becoming familiar with potential vendors.

Once a “buy” decision is made, the next step where many issues can be avoided is the RFP process. By knowing the right questions to ask, you can get a better understanding of  the true Cost of Ownership.  Just as questions about user functionality and how the software fulfills the documented business requirements are important, questions to help you better understand how the software will fit into the overall architecture and integration points are also very important. 

Some topics / questions that are sometimes overlooked include:

• What API’s are available to interface with the software and what documentation is available?
• What industry standards does the software follow or can communicate with?
• Does the software include tools for the import and export of data?
• What specific technology(s) and programming language(s) is it built on?
• How much and what type of training will be required to operationalize the software?
• What is the difficultly level of installing updates or patches?

When it comes time to select a particular vendor, I have found developing a structured scorecard is the most successful. Some projects that I have seen or heard about have relied too much on impressions, how well the sales presentation was delivered, or simply going with a “gut feeling”. By developing a scorecard with weightings that prioritize high value qualities and objective criteria, you can trust that the best application truly won out.

It is a Great Tool, But if it Doesn’t Talk to My Other Systems, it Does Me No Good!

It is rare that a piece of software will sit on an island and not need to communicate with other systems.  It is vital that your company has the technical expertise to integrate all systems together or to work with a trusted partner that does. Even though the packaged solution may be wholly contained, the effort to fully deploy and maximize benefits usually requires the ability to the define the overall architecture, have expertise in multiple programming languages, have experience with integrating many disparate systems, be able to perform data analysis and design BI solutions and reporting.

Last but not least, to truly make a piece of packaged software successful, we need to consider all supporting processes and governance for the new software.

For example:

• Who are the users of the new software?
• Who will maintain the software?
• Who has the authority to approve changes to the software and its data or the processes within the software?
• What are the Change Control and Release Processes for the new software and how does this affect DevOps?
• Do we need to establish new or different standards for using the software (e.g. coding, naming, or data standards)?
• What is the process for upgrading the packaged software?
• For all changes, what end user communication and training is needed?

With a structured approach to purchasing packaged software, you can ensure that not only is the correct business issue being solved, but that the right product is selected and installed. Most importantly you fully realize the promised benefits. 

What do you think?  What else makes a packaged software purchase more successful?

Interested in reading more, Check out Enterprise Content Management for Your SOA