A Client Management Example of Building an Interim Solution

I recently advised a service provider on how to address issues with their client management processes. My recommendation was to build an interim solution to replace 13 spreadsheets currently used for tracking clients and case notes. There's a recently implemented client management system in place, which raises the question, "Why don't we just migrate these teams onto the client management system?"

Unfortunately, there are significant issues with the new system. It's unclear if it will remain in use, partly because it doesn't meet some basic requirements. While the software can capture case notes, it requires separate notes for each service. However, in-home care workers often provide multiple services in one visit and prefer to record a single case note.

Moreover, the system doesn't accommodate the typical service provider's information capture needs. Multiple teams deliver services under various funding programs and contracts, and the system's complexity hampers efficiency for workers and team leaders. For example, making notes at the end of a client session should take a few clicks, but here it involves over 100.

We’ve explored multiple workarounds, but these add extra burdens and reduce organisational efficiency. For instance: recording services and compliance report flags in an unstructured notes field since the product can't capture configurable fields for each program. This approach would create a massive amount of downstream work every month to clean data, reconcile, and work around the system's inadequacies—likely requiring more effort than the current spreadsheet solution.

There is an ongoing activity to reassess this product's basic fit. In this context, the next obvious question is, "Why don't we just wait for a strategic solution?" This question hints at outdated assumptions from the last millennium that haven't been valid for almost 30 years. The core assumption is: "It's too expensive to build something and then throw it away."

In the 60s, 70s, and 80s, this belief was generally true, making it a reasonable motto to follow instead of constantly assessing cost-benefit. However, the IT industry has changed fundamentally since then, and this motto is no longer appropriate. It is now costing us a huge amount of money in wasted human and organizational capacity.

Firstly, the pain of an ill-fitting solution is often neither clearly considered nor quantified and documented. Because we cling to that outdated motto, we don't even think about it. This leads to hidden costs that compound over time. These costs are very real as they reduce our capacity to deliver services, but we simply choose to ignore them. In this situation, there are two serious business costs to consider: risk and actual financial cost.

Client information for 13 programs and their respective teams is currently held in spreadsheets stored on a shared drive. This is common in the industry but poses significant risks. Spreadsheets with sensitive data are an easy target for anyone who breaches the building's physical security or compromises an employee's credentials via phishing. Many of these spreadsheets also contain medical case notes, making the situation incredibly fragile.

There have been several breaches in the charity sector in recent years, and such organisations are increasingly seen as "soft targets" due to practices like this. Small charities often lack the same controls around bank account access and invoice payment that are common in larger organisations. Consequently, with a couple of days of work, fraudsters, including hackers, can walk away with hundreds of thousands of dollars.

In some ways, the cost side of this business problem is more tangible. My most conservative estimate suggests we waste about two FTEs on the current spreadsheet solution. Various business processes, from first client contact through assessment, onboarding, and the first visit, involve multiple people working around spreadsheets and rekeying information. Most of these people are managers, not workers. Given the salary differential, we are effectively wasting 3 FTEs of client services every day. That's a lot of care!

Every day working around a spreadsheet-based solution should be burning a hole in our psyche. But because we don't spend enough time quantifying this, we pootle along, oblivious. We've established that there's a significant cost associated with the status quo and, therefore, a substantial business benefit in fixing it now. The next question is, "But doesn't it cost loads to build a solution?"

In reality, this question is rarely asked. It's another assumption based on data from the 70s and 80s. When we ask this question in the context of using cloud V2 technologies, the answer is often surprising to the uninitiated. We are not proposing to build a core system here, just a simple user experience – essentially replacing a couple of spreadsheets. It requires just a few pages (client, case note) and somewhere to store some data. We're talking about 2 to 4 weeks of time and between $20k and $40k if a small dev shop like mine does it for you. It would likely be even less if you have an internal developer.

Even with the most conservative benefit estimate of $120k per year (through increased capacity by lowering admin waste), and using the higher of the two cost estimates, we're looking at a project that pays for itself within four months (40/120 gives us one-third of a year). That's a fast payback considering most programs these days have a two-year payback period. So, the final question is, "Isn't it a waste of $40k if we end up throwing it away?"

Most likely, no, it is not a waste. Firstly, it's unlikely that we'll resolve the questions around the core system in less than four months. Even if we only consider the numbers, as long as it takes four months or more, it makes perfect sense to take control of our destiny and improve staff experience while dramatically lowering the cyber risk of having spreadsheets scattered across the organisation. Additionally, there's a very real possibility that the system will be judged as not fit for purpose. In this event, the timelines would extend markedly, increasing the value of an interim solution.

Even if the product is retained and fully adopted, having an interim user experience that works for all programs and teams will be invaluable in shaping the requirements we share with the vendor. In this case, I would recommend using the vendor's software as the system of record. This would allow us to replug the interim solution into the retained product, effectively repurposing most of our spend on the interim solution.

So, what I'm advocating here is to stop using the "buy, don't build" mantra of the last millennium. It's no longer applicable and distracts us from the real goals: increasing capacity and reducing cyber risk. Instead of relying on this outdated decision-making process, we should start every investigation with the question, "What is the justification for NOT fixing this problem right now?"

Andrew Walker
Technology consulting for charities
https://www.linkedin.com/in/andrew-walker-the-impatient-futurist/

Did someone forward this email to you? Want your own subscription? Head over here and sign yourself right up!

Back issues available here.