We selected the right software for our industry, but the results are still disappointing. This is often the case where the right product was selected but with the wrong support / implementation philosophy. All corporate-wide software solutions (ERP, CRM, etc.) require some modifications. These modifications can be reports, interfaces, and basic established parameters within the code. It is a different ball game once the core code or database itself is revised.
Before addressing some of my concerns on the software philosophy, let me summarize my background in this area so that the reader can better understand where I am coming from. In my professional career, I lead the software development team for a financial software company. I was also the senior IT executive of a Fortune 500 company and served as CIO for several companies. Software development is an area that I am very familiar with.
In-house development of mission critical software is a high risk and costly means of obtaining software additions. Even with the resources of a Fortune 500 company, I would be most reluctant to modify critical components of an off-the-shelf solution.
Once you start down the path of customization, the programmers see everything as a coding issue. “If all you have is a hammer, everything looks like a nail.” -Bernard Baruch. Then the inevitable “ticket” system develops coupled with its associated lack of addressing issues. This situation creates the infamous fact that the users start doing their work offline in spreadsheets or, even worse, manipulate / adjust the data offline, thereby, jerry-rigging the system and generating additional non-value added time in reconciliation of data, ad infinitum. This is a slippery slope for a mission critical application.
This customization approach may be fine for a software development house that has literally hundreds of team members to test and document the code, but internally with a handful of programmers, it is a high risk. Furthermore, numerous studies have documented that internal customization is by far more expensive and riskier.
In summary, the challenges with internal development are:
Quality of coding
Changes to the solution are generally costly
Keeping current version of the original product
Testing of the code
Disaster Recovery Plan should be tested twice per year
Version control, internal and external. Upgrading to the newest version of the software product may become a monumental undertaking once you deviate from the core code. How will you keep up to date on current technologies?
No economies of scale with a small pool of users driving enhancements. Software development is not part of the company’s core competencies.
Risk of losing knowledge base with no backfill
Forward compatibility of customizations are challenging
Internal battles between competing internal projects for budgets to handle software development and ongoing support
Difficulties in supporting new technology platforms that are on the horizon
Are you reinventing the wheel?
When evaluating whether to buy or build, it’s critical to thoroughly understand total costs during the software lifecycle — typically seven or eight years. (Typically, 70 percent of software costs occur after implementation.) A rigorous lifecycle analysis that realistically estimates ongoing maintenance by in-house developers often tips the balance in favor of buying / out-sourcing.
The late Dick Benson, a top direct marketing consultant and author, summarized it best: “You should do only what you do best in-house, and outsource the rest.” This ability to focus on core competencies can mean the difference between a software project that is bogged down by non-application specific details, and a project that successfully hits milestones and makes it to completion.