Software Development Services Part II: Case Studies
Last month Bryan Firestone talked about the “scary” parts of software development for labs. I’m going to go a little deeper and offer a case study, but I do want to re-iterate one of his key points: Often we see labs immediately assume that they need to build software from scratch. My first job with a new client is to explore off-the-shelf solutions first, which is always the more inexpensive route to go, even when they need to be customized a bit. After exploring that and determining that something does need to be built, it’s my job to make sure it’s not only built well but functions in all the ways needed – including being able to handle future, unanticipated situations.
My first question to every client: What is the mission critical function of your operation? What are your needs? What systems are already available? We’re often involved with projects where the client have a specific problem to solve, and it’s usually an operational issue involving IT. There are operational workloads to consider, as well as what systems have to be implemented. The choice to build it or buy it impacts a client’s long-term needs.
Often a client will have it in their head of what they want a brand-new system. If they’re right, and the need is pointing toward building something specific just for them, then we have to explore the “Is it worth it?” question. Exploring other ways to achieve the same goals might not only lead to significant savings, but results in better, more efficient processes. Of course, sometimes we have to blast through the “But we’ve always done it this way!” roadblock.
Tech is not a hobby to me. So while I’m a technical guy who knows code, I’m coming at it all from a business perspective. For example, I’m going to question building a $1 million new custom system to make $1.5 million. That’s not enough ROI for me. It needs to make $10 million to make sense. As my associate Mike Pratt likes to say, a lot of clients think they know what they want, but sometimes we need to bring them back to earth and really dig into what the needs of the lab are, and determine the best solutions for those needs.
Off the Shelf v. Custom
Off-the-shelf solutions usually require some configurations. Salesforce, , for example, was originally known as a highly customizable CRM platform. It has a foundational layer that allows one to customize and build workflows and store huge amounts of data. So they have become the giant they are because they realized the platform could be used in a broad array of business applications. So they pushed out their underlying technology as the product with the idea that any industry can their needs. It has certainly been valuable in our work, and can be a cost-effective, flexible solution.
But that’s just one idea we might bring to the table. The most important value U.S. HealthTek provides from my viewpoint is that we’re not tied to any one technology. We come with an open mind and a deep understanding of all the tools available. It’s a benefit because some consultants are married to specific software, and I’ve seen situations that rapidly devolve into what can only be described as trying to fit a square peg in a round hole.
As Brian wrote last month, the number one reason to build a custom software system is when it offers proprietary advantages over your competition. So once U.S. HealthTek and the client decide to go the custom software route, we take all the precautions to ensure its success. For example, I’m always on the lookout for “scope creep.” This is when a builder starts on a two-story house and half-way through, the owner decides she wants a walk-out basement. Well, the foundation has already been poured, and now things have to be torn up. Any “Oh, by the way we need it to do this” after the fact runs up the cost and complicates the goal and the deadline. We ask all the right questions up-front to avoid having to tear up your foundation.
If I’m told by a client that I need to capture basic data from patients like names, dates of birth, etc. – well, there are many options available for that situation. But if it also involves validating a driver’s license and social security number, then the government is involved, making it a more complex situation.
One example is with our good friends at XIFIN. They had a Third Party Administrator (TPA) that handled all transactions manually. Associates would make calls to businesses, who would then call DSI Labs and send manual requisitions. Sound like a big logistical nightmare? It was. The emails that followed … the faxes! So XIFIN had the idea to create a portal that would basically automate all of this. Building it internally wasn’t feasible, and there was nothing off the shelf for their needs. But there were good reasons to go custom on this solution, and we were glad they came to us.
It took a year for us to complete the portal, but when it was it was done, it was completely automatized for their specific needs. And it got great results, making them a leader in the country when it comes to TPA. The initial costs were not insignificant, but that is where they decided to invest their money. ROI? It saved them a ton of manual labor (and costs associated with it) and differentiated them from their competitors. Today they are handling 10 times the amount of business as they were before.
Business Before Building
I tell people I’m not necessarily an application developer – I’m a logistical guy who can develop and implement custom software. I figure out the core of the problem, and determine whether it needs a hammer or a nail gun. Code is not a means to an end. It’s just a tool to solve problem. But thoroughly understanding your problem is what we’re good at. Let’s have conversations where we’re thinking forward, and decide together the tools that are needed to get you to the solution your organization needs. Then it doesn’t have to be scary at all.