Compromise to Optimise

We’ve worked with many organisations to help them solve their specific planning problem. One client we recently worked with inspired this post, because it is a great example of the importance of people when designing and implementing scheduling software.

We engaged with this particular client about 18 months ago. They were looking to transform their operation by designing and implementing as close to a ‘perfect’ optimising scheduler that could optimally plan and allocate orders to staff. We started as we do with every project by doing a deep dive into a number of areas of the organisation. Our team spent over 3 weeks completing a data analysis exercise which reported back to the stakeholders some cold hard facts on the mixture of work, the balance of night time working vs day time working, the effective spread of ‘fairness’ across workers — you name it, we discovered it and reported it back. It was an independent analysis of the state of planning — and the best bit was there was plenty of scope for us to implement some planning technology, using a Solver based approach to help solve the stakeholders’ problem.

The first step on this journey was our suggestions around how to approach the solution. We knew that a solver based approach necessarily required a reasonably simple model and soft constraints that the solver can bend to score different planning solutions. Our engineering caps firmly in place we described the utopian planning model, constraints and rules that would provide for maximum levels of optimisation and utilisation. We knew that there were some fundamentals the planner had to achieve — such as fairness of work distribution, night time working constraints and skills based allocation — but we were confident a solver could cope with these requirements.

But then, cold, hard reality hit.

The client came back and after a great amount of internal discussion it was recognised that certain fundamental, historical rules around the allocation of work were in place. These rules were contractually baked in to the fabric of worker agreements and the organisation itself. We couldn’t change these rules and we needed to be sensitive to the fact that in order to get any buy in from those workers conducting the work, any solution had to honour the rulebook.

It was a moment that we had planned for from the inception of the project, but the engineering purists in us had hoped we would be able to change. As it turned out we needed to rethink the entire solution and design a set of algorithms and planning technology that worked with (and codified) the rulebook of the business. Furthermore, we started to appreciate the level of human interaction between ourselves and the users and planners in the organisation. Levels of scepticism regarding the project were high, coupled with that familiar fear from staff that the software would “take their jobs”. We couldn’t be a faceless tech provider — we needed to 10x the “Human Ingenuity” part of our ethos and get to know the people who would be intimately using the technology.

It’s a great example of compromising. We had to compromise the ‘purity’ of the technical solution we had originally set out to deliver to take into account the operational environment we were deploying into. We believe that this is one of the key components other vendors miss (and is one of the primary reasons so much ‘automated scheduling’ software is turned off). We spent weeks on site with the planning team iterating and refining the technology. We’d like to think we got to know them as people and helped appease some of those completely understandable fears surrounding new technology.

Just as we learnt that compromising the technology was sometimes (often!) necessary we learnt that listening and understanding the people that would use the system was as key to its success.

These teams are critical in the adoption of the technology and it wasn’t just ‘good business’ to make sure they were involved and bought in — it was the right thing to do.

‍