Myth: A complete, detailed planning guarantees a fluid installation of new software. Reality: The pre-defined planning will not be respected. Myth: All aspects of the new software are documented. Reality: The documentation is incomplete. Myth: The new software works. Reality: The new software does not work.

1. Piece of Cake: Myths and Realities of installing new software
Every company will face in its lifetime at least one major software purchase, be it E.R.P, Internet-
based solution or whatever. To obtain the claimed, and expected, increase in productivity and/or
sales, this new software will eventually have to be installed. 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 installation. All sorts of additional,
unexpected and not yet described aspects will indeed come "floating to the top”.
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 installation 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
1

2. 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.
Being a customer, 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, easy access to FAQ-database, guaranteed response time, guaranteed
solution time (which might be very, very different from the guaranteed response time…), periodical
onsite 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 that “parallel worlds” generate.
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. To avoid a nightmare-generating
installation, 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 debugging-structure.
If you are not too discouraged by now and still plan to go ahead with your installation, I sincerely wish
you all the best. Remember, nothing, or almost nothing, is so enjoyable to say after a difficult
installation brought to a good end: “Well, we finally made it…It was a piece of cake”.
Martin van Wunnik
August 4th 1999
2