COTS: How to avoid a hangover

Quite possibly the most important reason for an organization to purchase package software is to lower the Total Cost of Ownership (TCO) of its existing IT setup. On paper, this indeed seems like a win-win situation between customer and software vendor: in exchange for a (extra) maintenance fee, the vendor provides support and upgrades to the customer. But is COTS really the best way to go?

Because of the standard modus operandi, the implementation time can be shortened a great deal when compared to a classic custom setup. Yet, most Commercial of the Shelf (COTS) implementations – especially the Enterprise Resource Planning (ERP) ones – go awry. Recent studies show that 90% of all ERP implementations end up above budget and/or take up more time than planned. What is more, just 33% of these projects is considered to be a success.

Still, if a few basic principles are held into account, a COTS implementation doesn’t have to become a fiasco. Here are 4 recommendations that can help you prevent that from happening.

1. What?

Purchasing an all-in-one package seems like a standard excuse to bypass the requirements phase. But how can you properly consider all of the various options offered by vendors if you don’t have a clue what business needs need to be met? On the contrary, such a purchase should be seen as a golden opportunity to take a step back and question the current way of the doing things. Quite often, this exercise leads to surprising results and purchasing a standard package no longer is the best option.

Several things to keep in mind:

• Ask yourself: which business need do we want to meet with this software?
• Think outside-in, opt for a new customer experience, in which the customer you have in mind is the end customer (possibly not your direct customer)
• Go for a holistic approach (so don’t limit yourself to the silo for which the software will initially be used, e.g. finance)
• Don’t limit yourself to the existing software or modus operandi
• Involve current and future end users during this exercise
• Don’t forget the non-functional (quality) requirements such as performance, usability, security, etc.

2. Limit customizations to what’s absolutely necessary

A payroll admin company wanted to change its core payroll application (mainframe) using a modern ERP alternative. The analysis was done textbook-style and executed very thoroughly by a mixed team of end users and the company’s own business analysts. This resulted in a document of over 300 pages, which became the blueprint of an ERP customization that would initially take 1.5 years to complete.

Five years later, the implementation still hadn’t been completed, the budget had risen to ten times beyond its initial number and every standard upgrade of the ERP software led to more than 1000 (!) regression defects. Eventually, the decision was made to start a back-to-standard project to dramatically decrease the number of customizations.

Even though the software vendor wants to meet its customers’ wishes, it’s impossible to hold into account all of their requests and desires when doing an upgrade. That’s why, on the customer side, it’s important to do a solid regression test on each upgrade before implementing it.

3. Acceptance

“The implementation is being handled by a gold partner of our ERP software. They’ll also handle all of the testing, so we can sleep soundly, right?"

No you can’t! As the customer, it’s your responsibility to set up a thorough acceptance phase. Vendors perform their own tests and they are insufficient by default:

• They’re limited in scope: not all test levels are covered, such as end-to-end
• Do they guarantee your own interfaces will still work?
• Will you need to make extra modifications in your own systems, each of which needs to be tested?
• Their tests are not always representative, e.g. they have not been run on the customer environment, with real customer data …
• The left hand may be controlling the right hand or vice versa.
• If there’s not enough time, this is the first thing that’s being saved on

Make sure to agree beforehand (when defining your test strategy) with your vendor who’s responsible for executing which test levels and which kind of evidence they’ll provide to prove that these tests have been done successfully. Ideally, all QA activities of the project (COTS and internal systems) are being checked by a QA governance party, independent from the vendor.

Also important here is the test data, which needs to be used E2E and as such exist within the COTS system, but also on the side of the customer. It’s necessary to set up a test data process to make sure that, within a DTAP (Development - Testing – Acceptance – Production) environment, the data is placed correctly across all systems of the landscape.

Lastly, don’t forget to test non-functional things such as software performance.

The lack of a formal acceptance by the end customer may have serious financial ramifications. Once the implementation and after care phases are done, new customer questions/tickets follow the change request process, for which other rates apply. It’s not uncommon for the software budget to increase dramatically in this phase.

4. Data

“The software’s ready, all that’s left to do is transfer the data.”

A data migration project is a project by itself and should be considered as such at the start of a COTS implementation. A lot of vendors currently have the tools to help facilitate a data migration track, but still, it’s necessary that you do your homework. Here are a few quality activities that need to be considered apart from the migration itself. Keep them in mind and the odds of your data migration project to be successful will go up:

Apart from the aforementioned steps, it’s important to get a good view quickly on the quality of the data to be migrated. Data of inferior quality can have a huge impact on the project’s lead time.

Closing note

All of the tips listed in this article are not an exhaustive overview of all best practices to be applied when implementing a package software. The four points made absolutely are must-do’s which you can take up yourself as the end customer. That’s the best way to get in the driver’s seat and to impact the outcome of your project in a positive way.

Considering a COTS implementation yourself? Let’s discuss how we can help you make it a success.