This article is a slightly adjusted version of the article I wrote on August 4th 1999. So, except for the modified wording in blue in the text, it appears not that much has changed since the end of last century…

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
1

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”.
2

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.
3

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.
4