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 to 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 one in six have an average cost overrun of 200%, as well as 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 answers to that question lie 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 third party 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 objective overall 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 to make rational thought prevail.  A simple scoring system of 0=feature does not exist, to 3=feature exceeds requirements, makes the evaluation easier.

THE EVALUATION SCORECARD

Risk Analysis

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 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 actions.

An independent third-party professional can help you evaluate your risks and come up with a detailed plan for them.

Other Considerations

Some things to consider in your evaluation:

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 3rd year. After 3 years, the cost usually goes up again to 30-35% every year. They also expect some sort of reengineering of the application after 5 or 6 years. This is rarely discussed when people are planning development projects, but the truth is, it’s a very large ongoing outlay that needs to be budgeted. The cost of adapting, preventing, correcting and fixing the software can be substantial. This often points to the advantage of 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 customer’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. It would be a very good idea to protect yourself from potential hackers. Depending upon 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 many of the pitfalls associated with the potential anguish of changing a software developer or software development company, it will provide you with a very important 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 completely, unraveling new layers can be expensive and time-consuming if bugs and gaps are later found. Unfortunately, the bulk of the testing burden usually falls on the shoulders of the buyer of the software. It’s also a least-loved task for them. 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. The design and architecture, language chosen, etc., should be reviewed by someone who has independent expertise on system programming and architecture prior to commencement of the engagement. This area is indeed fraught with dangers, as a wrong step in design means money sunk into a choice that needs to be undone or redone. 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 a business, time is money, but this is especially true for software development. Even if you’re lucky enough to hit your hoped-for live date, consider as well your investment in time and effort, and the lost opportunity of an earlier live date that other alternatives may provide. If there are delays, which is often expected, 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 what’s needed, huge gaps often exist in what’s really 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 not likewise “assumed” by the developers. If they don’t see it on paper they don’t do it. A good software engineer will catch things upfront with lots of extra questions. Most, however, won’t realize the gaps until it’s about to go live or has gone live, and someone asks a question like “How are we handling forgotten passwords?”

Availability of resources. If you undertake a software development project you have to seriously commit 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.

Summary

When making the decision whether to build or buy case management software, there are many factors that come into play.  The key is corralling those factors into real and objective analysis that can help you make the right decision and avoid common pitfalls.