To Build or Buy?  The Pros and Cons of Buying Off-The-Shelf vs. Building Your Own Case Management Software

In 2017 Handel will celebrate our 20th year in business. It really does not feel like 20 years since the day I sat up Handel’s first office in the basement of my house. We got our first break from customers who wanted us to build custom database solutions for them. Since I didn’t have a product to sell them, building custom software was the only way to stay in business. We initially developed a variety of custom software solutions including point-of-sale software (our POSIE POS software for local florists were an early hit), reporting software for bank portfolios, inventory management, and many other solutions long forgotten. Most of these solutions were so individually tailored that they were almost impossible to mass-market. However, they paid the bills and kept us in business during those early years. One day in 1998 an old college friend contacted me. She was working in the IT department of the human services division of a large Colorado county and they were looking for a database for managing youth in a juvenile diversion program. Perhaps because English is my second language or maybe because I had never had much exposure to the human services world, I neither knew what a “juvenile” was, nor what a “diversion program” was.  Not that this would stop me. I had bills to pay and a family to feed. “Of course I can do this” I thought. 2 months later, the pre-cursor to RiteTrack was delivered. The system did exactly what the customer had asked me to do and it worked really well. That is, until 15 or more employees used the system at the same time. Somehow in our negotiations we failed to discuss how many users would be using the system on a regular basis. The chosen solution was built on Microsoft Access. For all its power in terms of developing quick applications, Access at the time was not designed to support a large number of users, a task better handled by its big brother, Microsoft SQL Server. This was only one of many lessons we learned in those early years. Probably the most important lesson I learned: If you want to build a business you have to be really good at something. It is very hard to be successful at doing many different things for many different customers. The custom-shop model kept us alive for our first years and it led us directly to RiteTrack. Both good things because we would not be around today if we hadn’t started out this way. We chose to follow the path that RiteTrack created for us into the field of human services. We soon ditched all of our other efforts and became really good at one thing. A strange thing happened when we did this. Our business started to grow.

If you are a government agency looking to implement a complex human services software for managing the clients that you serve you are faced with a variety of choices. You can build a system in-house, you can hire a consultant to build a system for you, or you can choose from a variety of vendor-provided products. Unlike the late 1990s when we started out, the marketplace today offer “COTS” (commercial off-the-shelf) software for virtually any market niche. However, unlike the 99 cent apps you buy in an app-store, the type of social services government software we develop (often referred to as enterprise resource planning software, an unfortunate term in my opinion since most human services programs don’t think of themselves as an enterprise -a customer once asked if it had something to do with “Star Trek”) has to meet several complex requirements including business rules (rocket science has nothing on TANF eligibility), the number of different departments and users served, reporting requirements, security models, customizations specific to their particular county, state, or tribe, and many other variables. Large state software projects involving major government contractors frequently run into 8 figures ($10 -50 million is not uncommon). Needless to say, small government entities do not have total budgets (never mind IT budgets) that come close to such figures. In the perceived absence of existing COTS systems that can be had for much less, government entities often go the route of developing a custom solution system in-house or hiring a local developer with the expectations that the system will cost them a lot less. Unfortunately what may seem like a great deal up front ends up costing considerably more over time and exposes your organization to a great amount of risk.

The process often goes something like this:

Said project has a finite budget. A request for proposal (RFP) is put out. Vendors bid on the project. A local software developer comes in with the lowest bid. By law, you the customer has to go with lowest bidder. The local software developer has stellar credentials when it comes to having all the right technical skills but has no domain expertise (like us at the start, they have no concept of your domain, being it juvenile justice, child welfare, TANF or other). You on the other hand have all this knowledge but no expertise with complex software projects. Seems like a match made in heaven. Or not.

Having been on both sides of the fence, both as the custom software developer and later as the “COTS” vendor, we feel qualified to speak on this subject. While the low-bidder-local-custom-shop developer may look good on paper, there are a lot of hidden costs and risks associated with custom software projects.  We have seen some of these projects succeed, many fail outright and most never living up to the customer’s expectations.

Here are some of the common pitfalls of custom software projects:

Software developers are very good with what is in their technical toolbox whether that is mobile app development, web development, database design, or traditional desktop software development. However, the left-brain dominant traits often found in those attracted into the computer science field, such as problem solving, algorithmic thinking, and a general excitement for technology also can be a detriment to these same individuals trying to understand common problems faced by those who work in the human services field. As somebody who probably falls more into the left-brain category, I can assure you, 100s of projects in the human services field can not substitute for actually having been a social worker or worked in the field of human services. First, I would dare to say that those attracted to the field of computer science are generally disposed of the typical people skills required when serving other human beings. Second, until you have actually worked in this field, it is very hard to put yourself into those people’s role. So, no matter how well you communicate the job of a social worker, even the most well-meaning, right-brain inclinded software developer will never get a complete understanding of your needs.

For lack of anyone else in the organization who volunteers, you become the point person for overseeing the new software project. You went to school to get a degree in social work because you love helping people, yet, here you find yourself in charge of overseeing the implementation of a highly complex software system. You are constantly trying to stay one step ahead of the software developers you are working with, all the while tearing your hair out and wondering how you ended up in this situation. You find yourself Googling words like “scrum”, “agile development” and “procedural design”.

Complex custom software projects always come in ahead of schedule and under budgets. False. Most complex software projects where there is a great amount of uncertainty usually stick to the original design document? Again, false.

The truth is, when you are dealing with a vendor (or an internal programmer) who have been tasked with developing software for something they know very little about and you have been tasked with being the representative for your organization in charge of the project, something you have never done before, suggesting that there are a lot of risk factors would be the understatement of the year. These projects always start out with a lot of positive energy. This should be easy! We should have something up and running in two months. There are two primary reasons why projects like these rarely come in on time and on budget. The first category is that there is a lot of uncertainty with these types of projects and you simply can’t know what you don’t know. There are often a lot of surprises lurking around the corner. Once you got the eligibility matrix in place you realized that you had forgotten to account for some of the key data points required to calculate eligibility. Back to the drawing board. The second reason is what is commonly referred to as “scope creep”. That scenario goes something like this: We have already created a place for tracking staff and caseloads. While we are add it, it should be easy to add in a piece to track our staff’s various certifications. I once had a software developer ban me from ever using the term “should be easy” in the context of software development. Once one “should be easy” turns into ten “should be easy” you have a problem: It is no longer easy. Our recommendation is to have great initial design specs and save the “would be nice” and “should be easy” for a future phase.

This is somewhat related to the previous paragraph. If you wait until everything is perfect in your custom software solution, you will probably never go live. Nothing in life is perfect and this is rarely more true than when it comes to technology. Even the best developed most quality tested software will have unforeseen glitches once it goes from production into the hands of the end-users. You will never be able to foresee all the challenges your end-users will put you through. Furthermore, some of your design assumptions will always turn out to be wrong anyway, so no need to wait until everything is perfect. No matter how perfect you think it is, you will find something you forgot once you go live. Better find this out sooner rather than later.

When we implement RiteTrack for a client it is not uncommon that we replace an existing system that was developed in-house. The two most common reasons for switching to a new system are:

Working with a vendor who is providing an off-the-shelf system you are less likely to run into either of these situations. The vendor typically provides upgrades so that the software stays current. The vendor is less likely to disappear than an employee. While the latter does happen, we find that most vendors in our market space has been around for a long time. Sometimes companies get acquired but the software typically continue to exist under the new owner.

Another common issue we see in home-grown systems is that they are often not designed to easily integrate with other systems or they are not built using standardized data schema, thus making it hard for third-parties to pull information out, or for integrating with other systems.

There are many hidden risks and costs associated with building a human services software system in-house. While this option appears attractive on the surface, it often ends up being much more expensive than finding an existing solution from a vendor who has experience in your space. Worse yet, with a custom-built system you have little assurances to fall back on in the likely risk of failure. With a vendor, failure is typically not an option because the vendor stakes their entire reputation on their product. If you have any questions about this, I would welcome the opportunity to hear from you.