While you should generally discourage software modifications, sometimes they make perfect business sense. Remember, software exists to support the business, not the other way around.
When I was 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 I learned from that conversation 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 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 extend the project schedule.
The belief 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. The reason is vendors want clients to pay to upgrade their software without mods or anything else to get in the way. This way, the vendor can 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, especially if you keep 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, upgrade tools are 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 adapt it to your organization. Software vendors use buzzwords to describe functionality, but when you take a hard look, the functionality often 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 retested.
Always schedule and budget with the understanding that some mods could occur. Additionally, do not have a line item called “software modifications” (combine it with miscellaneous, contingency, or related project line items).
~~~~~~~~~~~~~~~~
Editor’s Note:
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.
