August 30, 2016 • Rick Shepherd, CFE
If you’re weighing whether to build or buy case management software for your investigation unit or company, remember, “The best-laid plans of mice and men, often go awry.”
Perhaps if the Scottish poet Robert Burns were alive today, he’d be telling the cautionary tale of the field mouse and the plough in lyric form to managers wrestling with software “build vs. buy” questions. His famous verse, though, would probably be redundant in this day and age; the corporate landscape is full of debris left from failed, high-profile IT projects that started with the best intentions. Recent examples like Avon’s $125 million write down for their abandoned CRM/ERP project. The Los Angeles Unified School District’s $1.3 billion technology initiative debacle, and the $600 million lawsuit Bridgestone Tire brought against IBM for a system implementation Bridgestone claimed put their “entire business operation into chaos,” have become familiar admonitions to managers having to make software decisions.
And yet, with all these warnings we still see these scenarios played out in everyday corporate America; software that becomes shelf-ware, massive cost overruns, project delays, scope creep, poor architecture choices, etc., continue to plague managers. Separate studies by IAG Consulting and the Harvard Business Review show that some 68% of IT projects are considered failures, and that one in six have an average cost overrun of 200% with a schedule overrun of 70%. Why, then, if there are so many examples of these failures do we continue to see them?
When it comes to the choices inherent in building vs. buying software, much of the answer to that question lies in the analysis done at the start of the process. A practical and realistic reflection on your organization’s core competencies, the development of a seriously thought-out risk plan, and the proper search and scoring of alternative choices when it comes to software can help you avoid disasters and put you on the right track toward a successful outcome. When asked by investigation managers whether I think they should build or whether they should buy their case management software, I’ve used this simple matrix to illustrate a good approach to making the decision:
Essentially, the decision to build or buy comes down to how unique your needs are, (i.e. is there buyable software available that will meet most of your needs), and your level of expertise when it comes to software development. This second factor, (software development expertise), is an important consideration for anyone hiring a third party to develop software for them. If your core competency is not software project management, you might consider hiring an independent consultant who has expertise in software systems architecture and project management. They can review architecture and language decisions, keep the project focused and on task, review code, and make sure goals stay aligned.
The Evaluation Scorecard
Giving yourself the ability to score competing alternatives helps in the final decision process by providing an overall objective analysis. These scores can be weighted if desired. Ultimately, much of the emotional aspects of the decision can be eliminated. For example, a manager may fall in love with a feature in an off-the-shelf product that skews the decision toward that product. Likewise, an IT manager may be pushing for a build decision because of pride factors. Creating a scorecard like the one below can help allow rational thought to prevail. A simple scoring system of 0=feature does not exist, to 3=feature exceeds requirements, makes the evaluation easier.
Having a real plan to analyze risks and to deal with future threats to the project can go a long way in helping you attain a successful implementation of your case management system. Along the way, there will be mitigations to deal with, and if you anticipate and have a plan of action for them, you have a better chance of keeping your project on track. The key elements here are:
1) List all potential threats to the project,
2) Judge the impact of those risks and whether they warrant a consideration of alternative project choices, (e.g. buy instead of build)
3) Plan your response to those threats, the points that must trigger actions, and the people who will be relied on to take the corrective measures.
An independent third party professional can help you evaluate your risks and come up with a detailed plan for them.
Some additional things to consider when you are evaluating building vs. buying a system:
Maintenance: IT professionals who manage software development projects may expect maintenance costs to be around 35% of the development cost during the first year, 30% in the second year, and 25% in the third year. After three years, the cost usually goes up again to 30-35% every year. They also expect some re-engineering of the application after 5 or 6 years. This is rarely discussed when people are planning development projects, but the truth is, it’s an enormous expected ongoing outlay that needs to be budgeted. The cost of adapting, preventing, correcting and fixing the software can be substantial. This often points to an advantage to buying over building in the area of maintenance. With off-the-shelf software, these costs are typically fixed in the contract, and the underlying burden is spread out over many customers. For software that is built, only one customer is there to absorb the burden, and that customer is you.
Building a Security Model. How will this fit in with your client’s data security requirements? Unchallenged new software development must be strenuously penetration tested and certified. If you are housing personal, protected, or medical-related data in your system, you are at risk for a potential breach, and it would be an excellent idea to protect yourself from potential hackers. Depending on what the requirements are, this can get expensive. As a rule of thumb, allow an additional 2.5% of the original development cost per annum.
Documentation. Building a case management system is not like building a house or an automobile. In those examples, methods and outcomes are usually standardized and defined. With software development, targets are often moving, and unknowns are tough to anticipate. Methods vary widely, languages, architecture and platforms are diverse, as are approaches to executing and managing the project itself. Documentation is critical, and while it won’t allow you to avoid the potential anguish of changing a software developer or software development company, it will provide you with a critical starting point. Good documentation can also help reduce support costs overall, make for more efficient onboarding, and boost user acceptance. It’s costly up front, (allow 20% of total development cost and 5% per year to update for new features, etc..) but it’s worth the investment.
Testing. This is an element of the process where thoroughness is essential. Software is a series of interconnected codes that give you desired functionalities. If testing is not done thoroughly and comprehensively, unraveling new layers can be expensive and time-consuming when bugs and gaps are later found. It’s important to remember that the bulk of the testing burden generally falls on your shoulders. You should also know that it’s a task that is amongst the least-loved by anyone who has ever been through it. By necessity, testing is cumbersome and time-consuming, but it is important that this task is assigned to someone who can be dedicated to it and has an understanding of the overall vision for the project. Figure the cost of unit tests, integration tests, and manual user tests to add somewhere around 5-10% of the development budget.
Designing system models. This is an area fraught with dangers, as a wrong step in design means money sunk into a choice that needs to be undone or redone. Because of this, the design and architecture, the language chosen, etc., should be reviewed by someone who has independent expertise on system programming and architecture prior to the commencement of the engagement. Over the years, we’ve observed quite a few engineers head in the wrong direction, and it was costly for their customers. In general, if the main engineer on the project has less than 15 years of good experience, there is a high probability that mistakes will be made in some critical areas.
Timeframe for going live. Like every other aspect of business, time is money, and this is especially true with software development. Even if you assume you’ll be lucky enough to hit your hoped-for live date, consider too your investment in time and effort, and the lost opportunity of an earlier live date that other alternatives may provide. Delays often occur, and they are costly in terms of development dollars, management time, lost productivity and lost opportunities for productivity improvements. Very often these delays spill into 20-50% time blowouts and cost blowouts. When considering requirements, huge gaps often exist in what’s actually needed vs. what the original briefing with the developers scoped. A lot of elements that are “assumed to be in it” by the managers writing the requirements are likewise NOT “assumed” by the developers. If they don’t see it on paper, they don’t do it. A good software engineer can catch some of this up front with lots of extra questions, but most won’t realize the gaps until it’s about to go live and someone says, for example, “How are we handling forgotten passwords?”
Availability of resources. If you undertake a software development project you have to commit seriously to staff being available extensively to sit through meetings, give input, do user acceptance and application testing and to make sure everyone is on track. Training is often a factor in unstandardized software, whereas most off-the-shelf solutions come with a training program or module. This can be an enormous drain on time, but it’s important that you are willing to commit to it. If this area is underfunded, that will result in a product that won’t work for the user base. Even if people come along to the first few meetings, they often quickly tire of the slow progress and tune out. Things get missed this way, and the final product becomes insufficient.
When making the decision whether to build or buy case management software, many factors come into play. The key is corralling those elements into a real and objective analysis that can help you make the right decision and avoid common pitfalls.
About Rick Shepherd
Rick Shepherd, CFE is the president of Polonious Case Management Systems and has 25 years of experience in the investigation industry. Mr. Shepherd specializes in working with clients to incorporate technology into their business and improve their work processes. He helps firms implement solutions that improve their results, save money, deliver faster, and improve internal and external client relationships.
Contact Rick at 888-650-POLO(7656)