1

Myths of software implementations:

Did anything change since 1999?

By Martin van Wunnik

August 4th 1999 & May 23rd 2012

This article is a slightly adjusted version of the article I wrote on August 4th 1999.

So, except for the modified wording in blue here below, it appears not that much has changed since the end of last century…

P.S. You can find the original 1999 version here:

http://www.slideshare.net/MvanWunnik/myths-and-realities-of-installing-

new-software-erp

2

Myths of new software implementations

Every company will face in its lifetime at least one major software purchase, be it an E.R.P or other solution. To obtain the claimed, and expected, increase in productivity and/or

sales, this new software will eventually have to be installed and implemented. However, several broken myths, listed here below, could make the management wonder why on earth they agreed with the purchase of this software in the first place.

Myth: A complete, detailed planning guarantees a fluid installation of new software.

Reality: The pre-defined planning will not be respected.

Most of the times too many excuses to sum up will, unfortunately, take care for the fact

that the planning will not be respected. This will lead to losses of a serious amount of blood (figuratively speaking), sweat and tears for all concerning parties during and after the installation of new software.

To minimize these liquid losses, the company and the supplier should prior to the start of

the project define a best-case scenario (which equals the above-mentioned complete and

detailed planning), but also a worst-case scenario. Together with the software supplier, this pessimistic worst-case scenario takes into account all the potential risks and

corresponding delays and thus defines a much longer, and maybe more realistic, project

time and cost implications. Off course, the risk that the worst-case scenario will become the actual scenario at a certain moment during the installation is very real. Both parties must therefore agree on the conditions when to switch from the best-case scenario to the

worst-case scenario. To avoid long, tiresome and frustrating close-to-zero productive discussions and meetings when the applicable scenario (best or worse) is not respected,

the company and the supplier must, again prior to the start of the project, officially agree

on the “penalties” for this event. These “penalties” could be in dollars, like e.g. an additional discount, free delivery of another piece of software (which by the way will also have to be installed eventually…). It might be better to define these “penalties” as

additional availability of the supplier’s consultants, free of charge.

Apart from the compensation issue, the company must avoid planning partial deliveries or deliveries according to priorities when dealing with less complex installations. You will see that this kind of step-by-step delivery shifts the essentials of the project to what should

and what shouldn’t be delivered on a specific date. Also, the supplier may start using this

schedule to postpone unfinished parts of the installation.

Myth: All aspects of the new software are documented.

Reality: The documentation is incomplete.

For the company to obtain the technical documents and users manuals is necessary, but will, unfortunately, prove to be insufficient during and after the implementation. All sorts of additional, unexpected and not yet described aspects will indeed come “floating to the

top”.

3

It is thus strongly recommended to officially agree with the supplier that next to the

standard set of documents and manuals, a final set of documents must be provided as an integral part of the installation. These final documents will include all the issues found

during the implementation and address the comments of the new users. If the supplier does not provide these final documents, it will be a task for the company itself. If no internal team has been appointed and no common, shared database for this purpose has

been setup, you are heading for Diversity. As the employees will be experiencing a very

steep learning curve at the same time, the risk is great that the documents to make the new software work will be scattered around in different formats over many different users,

all using their own method and grammar. This is not really recommended.

Without this final document set, it will not take long before the company gets into serious problems: the knowledge about the undocumented aspects of the new software will slowly disappear. New experiences and personnel change, within the company and at the supplier, will make sure that over a longer period of time, nobody will know how to make

the software execute a specific step. The only solution then is to have an expensive

consultant coming in and scrutinizing and analyzing everything all over again.

Myth: The new software works.

Reality: The new software does not work.

This one is my favorite! Again, a myth with many believers, but unfortunately proven wrong in this world. We can state with near to 100% certainty that any new software contains big and small errors (so-called “bugs”).

“Not everything has been tested”. For CEO’s, this statement is sometimes very difficult to understand and to deal with. To refer to a famous analogy, buying and using software is much different then buying and using a car. Simply because of this fast world we live in, it is economically sound for most software suppliers to present beta-versions, or even alpha-

versions, as finished products. There is no time to test all the tiny-witty details of the

software, let alone all possible interactions with other software or environments.

The company’s only way to address this economical situation is to be sure that it agrees

with the supplier on a structure to quickly resolve these bugs. For easier communications, this agreement should be best finalized before the start of the installation. This structure

can take the form of a telephone hotline, fixed contact person, easy access to FAQ-

database, guaranteed response time, guaranteed solution time (which might be very, very different from the guaranteed response time…), periodical on-site consultancy. Even with

an adequate debugging structure, the company must at all costs avoid users creating

“parallel worlds”. These “parallel worlds” allow the users to accomplish their tasks without the new software (e.g. print invoices from self-made worksheets instead of the new E.R.P package where the layout does not include all the necessary information). It is not difficult

to figure out the organizational, administrative and technical mess these not uncommon

“parallel worlds” generate.

4

Conclusion

Buying a new piece of software is just the very first step. As long as it is not installed and correctly running, you really do not want to analyze the return on investment (ROI). To

avoid a nightmare-generating implementation, I recommend several actions to be taken:

First of all, agree with the software supplier on a best-case scenario and a worst-case scenario, as well as penalties for not respecting the applicable scenario.

Next, be sure to get a final set of documents, addressing all the issues that are not present in the standard documents.

Finally, define a good jointly organized and staffed debugging-structure.

If you are not too discouraged by now and still plan to go ahead with your software purchase, I sincerely wish you all the best. Remember, nothing, or almost nothing, is so

enjoyable to say after a difficult implementation brought to a good end: “Well, we finally made it…It was a piece of cake”.

Martin van Wunnik – May 23rd 2012

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.