User Experience: The Missing Link in Scheduling

If you ask an executive in a care organisation about their biggest operational challenge, the answer is usually scheduling. Based on my assessments during consulting engagements, software vendors are approaching the problem from a scientific or algorithmic perspective rather than focusing on user experience. This backwards approach has resulted in software that doesn't address the practical realities of day-to-day scheduling and fails to leverage human input. Ironically, this failure requires more schedulers and customer support staff than necessary.

In a small operation with 100 workers, this inefficiency can waste hundreds or even over a thousand hours of worker time per month due to underutilised staff. Essentially, we’re wasting thousands of client care hours each year despite the hard-won funding. I've also noticed that organisations of this size need more schedulers to overcome the system's shortcomings. Additionally, some organisations have extra call centre staff to handle exceptions, many of which are avoidable.

Complexity theory distinguishes between a complicated system and a complex one. An automatic car is complicated but relatively straightforward to operate. Each part behaves predictably, and the operation of most parts doesn’t affect others. A gearless bicycle, while uncomplicated, illustrates complexity because steering affects balance, which affects direction, and all are influenced by speed. Changing any one of these controls has complex interactions with the overall operation.

Complex systems are hard to optimise mathematically, but complicated systems are not, especially with well-tested algorithms like those taught in university operational maths. While advanced scheduling problems can theoretically be both complex and complicated, I argue that in care, the problem is neither if we consider practicalities. In my experience, vendors have built their scheduling solutions to cover theoretical edge cases, resulting in software that doesn’t work well for routine, day-to-day realities.

First, let’s address the planning challenge, then we can deal with the exceptions that cause much of the waste and work in daily operations. In theory, if I draw a circle around a client’s address, there are several workers available on a given day to schedule services. We can then look at the available times for each worker and cycle through every permutation of matching workers and clients for a particular time slot, eventually optimising resource use.

In reality, it’s not practical to have a different worker visiting a client every day or a different timeslot for each visit. This significantly simplifies the problem for a scheduling algorithm. In an organisation with 100 to 150 workers delivering services under several funding schemes, I believe schedulers could handle most of the work without an algorithm if they had a better user interface.

A team leader recently demonstrated an example of this. The graphical view of worker schedules did not distinguish between ad hoc appointments and regular scheduled appointments. The team leader wanted to isolate regular appointments to create a consistent schedule and then manage the short-term exceptions separately. If she had this information presented clearly, she could have manually allocated regular slots for up to 50 people quite easily. Instead, she had to print an A3 page for each worker, showing all their appointments, and manually sift through them for patterns—a task that took her an entire weekend.

Another example of planning shortcomings is in the visibility and configuration of worker-to-client preferences. Most applications allow for recording positive and negative preferences. A positive preference means a client gets on well with a particular worker, while a negative preference indicates a client or worker prefers not to be paired, for various reasons. Although these preferences can reduce system efficiency, they are a reality. Handling them as an afterthought adds significant work to the scheduling process.

In reality, most systems bury these settings so deeply that accessing them regularly is difficult. This information is often not included when displaying work patterns to team leaders and schedulers during the planning process. Consequently, after initial schedules are generated, team leaders and schedulers typically have to manually reassign tasks to account for practicalities.

These problems are exacerbated when support personnel deal with exceptions on the day. The most common issue is redistributing client work triggered by a worker's short-notice absence, typically due to sickness. In theory, software offers the ability to redistribute this work with a single click. However, due to the limitations we've described, support staff often have to manually navigate through each remaining worker's schedule for each appointment in question to determine the best matches and then implement the changes. I've seen instances where redistributing the work of one person for one day required over 100 clicks across several screens, many of which were visited multiple times.

In the longer term, the best solution is for vendors to improve their user interfaces, working forward from user needs into the product's features rather than the current backwards approach. In the meantime, we can make dramatic improvements to utilisation and reduce the number of scheduling support staff required by building a better experience around the existing vendor platform.

While building this type of solution might seem daunting, it is quite straightforward because we're not duplicating the functionality of the underlying system. We're just providing a simplified interface to it. As discussed previously, this assumes you've purchased software with strong APIs. This is the type of project we could easily pilot in less than a month. It's feasible that the pilot could be gradually adopted without significant additional work and deliver major savings. To be conservative, I'd allow another month for enhancements and feedback.

In an organisation of, say, 100 workers, this approach could pay for itself in less than six months. Taking control in this way typically accelerates conversations with vendors. In my corporate life, we had great success with this approach for a customer onboarding problem that had been discussed with the vendor for years. Within a year of building our one-month solution, the vendor used our system as a specification and built similar features into the base product. While this might seem like duplication, it’s highly productive because it brings forward the business benefits of removing waste from the organisation.

It's a shame that this back-to-front approach to building off-the-shelf products is so prevalent, but if we accept this reality and take control of our own destiny, the benefits are great. This approach allows us to deliver more client care with the funding we've already secured.

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.