The KRS Club Management System is used by over 60 different gyms around South Africa, and in recent years, outside of South Africa too.
The Challenge
While the strategy for development of a product which is used by a varied range of users is tricky, supporting those users afterwards is what we often find the most challenging.
With a wide variety of people ranging from straight out of school receptionists, to financial directors of large chains of gyms we are kept on our toes with questions ranging from simple IT related questions like backups failing due to running out of hard drive space or forgotten passwords up to complex queries which require sometimes days of investigation.
As all of these queries are coming in daily and from multiple sources with their own priorities and expectations, it’s very easy to get stuck in the trap of dropping whatever you are working with and immediately trying to assist who ever phoned last.
At first, we found this to be the best and most logical strategy as since the person is already on the phone, assisting them now would seem to be the most efficient for us and best service to our clients. And if every answer could be solved while on that call and once the phone went down the issue was resolved, it may well have been the best strategy.
Unfortunately, this plan started to fall apart once when we encountered the longer and more complex issues which could not be resolved immediately. What would happen is, we’d start on a large item, get traction on it but before resolving it, we’d find ourselves dealing with a new “simple” query on the phone which should only take a few minutes to resolve.
After a few of these simple queries we’d inevitably end up encountering another larger task which would require investigation. As we were already on the phone with the client, this investigation would often already be starting before putting down the phone. Once the phone goes down – you’re now faced with the problem of having two half investigated issues which your focus has now been spread between. Neither are completed and both are underway, but from the client’s perspective, neither are completed and therefore about as much benefit at this point as not even started.
The solution
We started to limit our Work in Progress (WIP) per developer to only a few items at any point in time. This way, once an item was started, we committed to complete it before taking on a new item. There are multiple reasons that limiting Work in Progress has benefits ranging from: reducing time lost during task switching, no need to reproduce an environment setup for an investigation once it’s started, the ability for a developer to focus on a task until its completion and the ability to better predict the time expected to complete an item as we could now almost guarantee it would not have its progress halted by a new item taking priority.
This was adopted as a solution to our problems as now, rather than telling five clients that we were half way done with their work (while realistically we may have started some and had them subsequently shelved for days), we could now potentially tell two clients that their issue was resolved, another two clients that their item was currently being investigated, and the final one would be informed that their item was in the queue and estimated to be completed in X number of days.
This immediately seemed to be the silver bullet to us making our way through our work sooner but left out one vital step. Without sufficient prioritisation, one could potentially end up having all developers tied to tasks which are not particularly urgent, when a new high priority item comes in.
It’s here where the difficult decisions started. If we already had the max limit of WIP items on a developers name and they are of relatively average priority, is it better to complete what has been started before starting a higher priority item which has just arrived, or do we break the rule and add that “one more item” to the list.
There are strategies which specifically deal with this problem where the new high priority item be defined as an Expedite item which can bypass the limits on the Work in Progress, but knowing when an item is applicable to this and when its simply another item for the backlog is often a very tough decision.
This has led us to where we are today where we are finding more of our attention being turned to sufficient prioritisation both upfront and during the process to ensure that the tasks being started on are always the ones which will provide our clients the highest value soonest.
Part of our process we follow now involves trying out variations of process models and we wouldn’t be surprised if we’ll be finding even better and greater ways to handle this in future. If we come up with any new plans which work out better and are worth sharing, we will definitely be putting out more information in future, so watch this space!