As an inexperienced project leader back in the 1980’s, I once informed an executive at a large aerospace manufacturer we are going “vanilla” with our enterprise software implementation. Absolutely NO software modifications or enhancements allowed I proudly proclaimed! His response stayed with me and still rings true today…
“Steve, you mean to tell me we are going to allow a one million-dollar software package dictate how we run a fifteen-billion dollar business?” Quite frankly, I was lost for words. Finally I said, “if we modify the software, future upgrades could be more difficult to implement.” His response… “So what? I need to run my business.”
The lesson is… you need what you need! Software is intended to support the business, not the other way around.
Make no mistake; if you really can go vanilla without crippling your business, absolutely do it. I am not encouraging software modifications because they take time and cost money. However, regardless of what the vendor’s sales people tell you, no software package is infinitely flexible and configurable.
At the same time, we all know software must address the key business requirements. This “zero tolerance for modifications” philosophy is fine for those that do not have to live with the software limitations. So what is a project manager to do?
No Big Deal – When Managed
In most cases, software modifications are not an issue when properly controlled and managed. After all, no one writes a single line of custom code until at least the project manager and the executive sponsor say so. In other words, proposed modifications should be well defined, business justified (vs. alternatives) and then approved by senior management (with a full understanding of project impact).
When executives approve a mod in this manner, they are making an informed business decision to expand scope, incur additional cost, and extend the project schedule. There is nothing wrong with this decision since they did it for good reasons. The truth is these are the kind of decisions executives make everyday. So why is ERP software any different?
Myths and Half-Truths
The religion that software modifications are universally evil comes mainly from the software industry. In fact, software vendors can make you feel like a criminal when you sheepishly tell them you modified the software (dumb old me). The reason is vendors want clients to upgrade their software and do not want mods or anything else to get in the way. The idea is to sell related software and plenty of consulting services with each “free” upgrade.
While software modifications increase the difficulty of software upgrades, in many cases this issue is over-blown. First, whether we like it or not, many organizations never upgrade their software. Others may do it only once over the entire life of the system. Also, there are upgrade tools available today that make the process of retrofitting custom code much easier.
Second, do not assume the promise of future software functionality within a new release will replace the need for mods. Even if the functionality is actually delivered, do not be surprised if mods are required to make it work in the real world. Software vendors use buzzwords to describe functionality, but when you take a hard look many times the functionality doesn’t go far enough.
I will not discount the fact that some software vendors initially refuse to address customer issues associated with modified programs, and for good reasons. However, most vendors will assist if the issue is critical and when push comes to shove. Also, keep in mind that some vendors will fully support custom modifications as part of their business strategy.
Furthermore, the risk of compromising support from the vendor becomes less of an issue when enhancements are designed to minimize the impact on existing system code and tables. Finally, no custom code should go into production unless it is thoroughly tested and then tested again (and maybe again).
Always schedule and budget with the understanding that some mods could occur. Do not have a line item called “software modifications” (this sends the wrong message-again no one is encouraging mods). Bake it into miscellaneous, contingency, or related project line items. Also remember, it is a given 95 percent of the reports requested by the users will be modifications to standard reports or totally custom.
———————————————————————————————————————–
Steven Phillips is an ERP professional with over twenty-seven years of implementation experience. He is the author of the book “Control Your ERP Destiny” available at Amazon, Apple iBooks, Google Books, Kobo, B&N and many other international booksellers.
For more on ERP software and implementation visit the ERP Software research center page. Download the free Top 20 ERP Software Report for a comparison of the leading ERP software solutions.