Myths of software (ERP) implementations: Did anything change since 1999?


Published on

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…

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

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Myths of software (ERP) implementations: Did anything change since 1999?

  1. 1. Myths of software implementations: Did anything change since 1999? By Martin van Wunnik August 4th 1999 & May 23rd 2012This article is a slightly adjusted version of the article I wrote on August 4th1999.So, except for the modified wording in blue here below, it appears not thatmuch has changed since the end of last century…P.S. You can find the original 1999 version here: 1
  2. 2. Myths of new software implementationsEvery company will face in its lifetime at least one major software purchase, be it an E.R.Por other solution. To obtain the claimed, and expected, increase in productivity and/orsales, this new software will eventually have to be installed and implemented. However,several broken myths, listed here below, could make the management wonder why onearth they agreed with the purchase of this software in the first place.Myth: A complete, detailed planning guarantees a fluid installation of newsoftware.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 factthat the planning will not be respected. This will lead to losses of a serious amount ofblood (figuratively speaking), sweat and tears for all concerning parties during and afterthe installation of new software.To minimize these liquid losses, the company and the supplier should prior to the start ofthe project define a best-case scenario (which equals the above-mentioned complete anddetailed planning), but also a worst-case scenario. Together with the software supplier,this pessimistic worst-case scenario takes into account all the potential risks andcorresponding delays and thus defines a much longer, and maybe more realistic, projecttime and cost implications. Off course, the risk that the worst-case scenario will becomethe actual scenario at a certain moment during the installation is very real. Both partiesmust 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 productivediscussions 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 agreeon the “penalties” for this event. These “penalties” could be in dollars, like e.g. anadditional discount, free delivery of another piece of software (which by the way will alsohave to be installed eventually…). It might be better to define these “penalties” asadditional availability of the supplier’s consultants, free of charge.Apart from the compensation issue, the company must avoid planning partial deliveries ordeliveries according to priorities when dealing with less complex installations. You will seethat this kind of step-by-step delivery shifts the essentials of the project to what shouldand what shouldn’t be delivered on a specific date. Also, the supplier may start using thisschedule 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, butwill, unfortunately, prove to be insufficient during and after the implementation. All sortsof additional, unexpected and not yet described aspects will indeed come “floating to thetop”. 2
  3. 3. It is thus strongly recommended to officially agree with the supplier that next to thestandard set of documents and manuals, a final set of documents must be provided as anintegral part of the installation. These final documents will include all the issues foundduring the implementation and address the comments of the new users. If the supplierdoes not provide these final documents, it will be a task for the company itself. If nointernal team has been appointed and no common, shared database for this purpose hasbeen setup, you are heading for Diversity. As the employees will be experiencing a verysteep learning curve at the same time, the risk is great that the documents to make thenew 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 seriousproblems: the knowledge about the undocumented aspects of the new software will slowlydisappear. New experiences and personnel change, within the company and at thesupplier, will make sure that over a longer period of time, nobody will know how to makethe software execute a specific step. The only solution then is to have an expensiveconsultant 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 provenwrong in this world. We can state with near to 100% certainty that any new softwarecontains big and small errors (so-called “bugs”).“Not everything has been tested”. For CEO’s, this statement is sometimes very difficult tounderstand and to deal with. To refer to a famous analogy, buying and using software ismuch different then buying and using a car. Simply because of this fast world we live in, itis 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 thesoftware, 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 agreeswith 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 structurecan 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, verydifferent from the guaranteed response time…), periodical on-site consultancy. Even withan adequate debugging structure, the company must at all costs avoid users creating“parallel worlds”. These “parallel worlds” allow the users to accomplish their tasks withoutthe 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 difficultto figure out the organizational, administrative and technical mess these not uncommon“parallel worlds” generate. 3
  4. 4. ConclusionBuying a new piece of software is just the very first step. As long as it is not installed andcorrectly running, you really do not want to analyze the return on investment (ROI). Toavoid 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-casescenario, 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 notpresent 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 softwarepurchase, I sincerely wish you all the best. Remember, nothing, or almost nothing, is soenjoyable to say after a difficult implementation brought to a good end: “Well, we finallymade it…It was a piece of cake”.Martin van Wunnik – May 23rd 2012This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. 4