Software modifications must be discouraged but sometimes they make perfect business sense. Remember, software exists to support the business, not the other way around.
As an inexperienced project leader back in the 1980’s, I once informed an executive at a large aerospace manufacturer we were going vanilla with our enterprise software implementation. Absolutely NO software modifications or enhancements allowed I 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?” 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 can really go vanilla do it. I am not encouraging software modifications because they take time and cost money. However, regardless of what the 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?
In many cases, software modifications are not a huge deal 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 have made a conscious decision to expand scope, incur additional cost and extent the project schedule. There is nothing wrong with this since they did it for good business reasons.
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 the client related software and plenty of consulting services with each upgrade.
While software modifications increase the difficulty of software upgrades, in many cases this issue is over-blown. This is particularly true when keeping the number and complexity of mods under control. 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. Finally, do not assume the promise of future software functionality will replace the need for mods. Even if the functionality is delivered, do not be surprised if mods are required to make it work for your organization. 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 refuse to address customer issues associated with modified programs, and for good reasons. However, most vendors will assist when the issue is critical and 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 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 is politically incorrect and sends the wrong message-again no one is encouraging mods). Bake it into miscellaneous, contingency, or related project line items.
Steve Phillips runs another blog at the IT Toolbox and offers some really great insight on doing technology projects. Visit his site for more info.
- business case for ERP modification
- business program modification freeze for erp deployment
- erp mods important