Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

1999: Myths and Realities of installing new software (ERP)


Published on

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.

Published in: Business, Technology
  • Be the first to comment

  • Be the first to like this

1999: Myths and Realities of installing new software (ERP)

  1. 1. Piece of Cake: Myths and Realities of installing new softwareEvery 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/orsales, this new software will eventually have to be installed. However, several broken myths, listedhere below, could make the management wonder why on earth they agreed with the purchase of thissoftware 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 theplanning will not be respected. This will lead to losses of a serious amount of blood (figurativelyspeaking), 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 projectdefine a best-case scenario (which equals the above-mentioned complete and detailed planning), butalso a worst-case scenario. Together with the software supplier, this pessimistic worst-case scenariotakes 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-casescenario will become the actual scenario at a certain moment during the installation is very real. Bothparties must therefore agree on the conditions when to switch from the best-case scenario to theworst-case scenario. To avoid long, tiresome and frustrating close-to-zero productive discussions andmeetings when the applicable scenario (best or worse) is not respected, the company and thesupplier 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 ofsoftware (which by the way will also have to be installed eventually…). It might be better to definethese “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 deliveriesaccording 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 ona specific date. Also, the supplier may start using this schedule to postpone unfinished parts of theinstallation.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 ofdocuments and manuals, a final set of documents must be provided as an integral part of theinstallation. These final documents will include all the issues found during the installation and addressthe comments of the new users. If the supplier does not provide these final documents, it will be atask for the company itself. If no internal team has been appointed and no common, shared databasefor this purpose has been setup, you are heading for Diversity. As the employees will be experiencinga very steep learning curve at the same time, the risk is great that the documents to make the newsoftware work will be scattered around in different formats over many different users, all using theirown 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. Newexperiences and personnel change, within the company and at the supplier, will make sure that over 1
  2. 2. a longer period of time, nobody will know how to make the software execute a specific step. The onlysolution then is to have an expensive consultant coming in and scrutinizing and analyzing everythingall 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 thisworld. 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 understandand to deal with. To refer to a famous analogy, buying and using software is much different thenbuying and using a car. Simply because of this fast world we live in, it is economically sound for mostsoftware suppliers to present beta-versions, or even alpha-versions, as finished products. There is notime to test all the tiny-witty details of the software, let alone all possible interactions with othersoftware or environments.Being a customer, the company’s only way to address this economical situation is to be sure that itagrees with the supplier on a structure to quickly resolve these bugs. For easier communications, thisagreement should be best finalized before the start of the installation. This structure can take theform of a telephone hotline, easy access to FAQ-database, guaranteed response time, guaranteedsolution time (which might be very, very different from the guaranteed response time…), periodicalonsite consultancy. Even with an adequate debugging structure, the company must at all costs avoidusers creating “parallel worlds”. These “parallel worlds” allow the users to accomplish their taskswithout the new software (e.g. print invoices from self-made worksheets instead of the new E.R.Ppackage where the layout does not include all the necessary information). It is not difficult to figureout 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 correctlyrunning, you really do not want to analyze the return on investment. To avoid a nightmare-generatinginstallation, I recommend several actions to be taken. First of all, agree with the software supplier ona best-case scenario and a worst-case scenario, as well as penalties for not respecting the applicablescenario. Next, be sure to get a final set of documents, addressing all the issues that are not presentin 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 wishyou all the best. Remember, nothing, or almost nothing, is so enjoyable to say after a difficultinstallation brought to a good end: “Well, we finally made it…It was a piece of cake”.Martin van WunnikAugust 4th 1999 2