Faced with an ever-growing list of demands, how does a delivery team decide what to do? It’s a challenge that every delivery team in every organisation has to grapple with. Corporations have to trade off initiatives that will grow their business against ones that will manage risks and keep them compliant against others that will improve their productivity.
In local government, we have the same conundrum – how do we innovate, keep the lights on our key applications and infrastructure, remain compliant and efficient; and how do we choose between delivering an initiative that will keep children safe and one that will keep our city clean? All with a limited group of people and funding. Interestingly, I’ve not found anyone yet who has completely cracked this, and I am not arrogant enough to think we can, but like everyone else, we are learning from others and having a go at it in our own way and here’s how…
Fixing the plumbing
After the natural ‘pause’ that happened on non-COVID work during 2020/21, we started getting lots of backed-up project requests through our ‘front door’. It led to us having a backlog of almost 50 projects awaiting assignment (typically we would have 100ish projects in flight at any one time). The first step was to take a hard look at those requests. We identified some that were duplicates or could be grouped, others where the value was pretty questionable, and of course those that were essential and had to get into delivery quickly. We were able to reduce that list to well below 30. A good start.
Next, we set about making sure that we don’t get into the same situation in future. That meant putting more rigour around what gets through the front door. That involved working with our Business Relationship Managers to define a robust set of questions that would prompt a greater depth of understanding of the request before it was agreed to be put forward. Not rocket science but we now routinely want to know what outcome is required; what its link is to the Council Plan and our digital strategy; whether it is legislative; what the benefits will be and to whom, and more. The result has been two-fold. (1) we have significantly stemmed the flow of requests into the front door because we are forcing people to think hard about why they want/need something; and (2) we are armed with some great information which then helps us to categorise and score each request.
Categorisation and scoring
Which brings me on to the next step we have in place – yep, categorisation and scoring! In terms of categorisation, we use the following:
- JDI – these are typically initiatives driven by legislation or policy – and just have to get done, no questions asked
- KSOR – meaning ‘keeps the show on the road’ – typically where something is needed in order to keep our organisation running – and where, if we don’t, we risk service failure
- Discretionary – typically these are innovation or productivity projects that don’t have to be done but which will bring improvements to our services.
There is one sub-category we use called ‘Big Rocks’. These can span any of the above categories but are called out as particularly large deliveries. This is important for us because, like the analogy of the rocks and sand in a jar, there are only so many big things you can fit in before you run out of room – or in the case of delivery, out of head space and leadership!
Scoring then helps us to form a view of the relative importance of something – so that when it comes to allocating resources we have as much info as we can have to ascertain what to start next. We keep these pipeline projects under regular review with our business relationship managers so that we capture any subtle changes around urgency, etc. We apply scores according to the following framework. It’s work in progress and we tweak as necessary as we learn something new, but I expect it will settle down over the course of the next 6 months or so.
First we assess the value scale, applying a score of 1-3 against all criteria that apply:
Then we do the complexity axis:
What we end up with is a something like this helpful visualisation of that gives an at-a-glance view of what we should and should not be working on:
The reality is that our business relationship function is pretty mature and helps to avert hopeless projects before they even reach us, meaning that thankfully we don’t end up with much in the red category. But we do get lots in all other areas, which is where turning this into a different view that helps us with the allocation. That’s the view below:
Our weekly allocation meetings use this view, plus information we have about resource availability, to help us to make decisions on what to allocate to the next available project manager.
As well as helping us to allocate things in the right order, we are now able to keep customers updated much more easily on where their project is on the list and when it’s likely to be delivered in relation to others. It has removed the ‘loudest voice in the room’ form of allocation and made it possible for us to objectively justify why we will do one project over another. In a world where we are resource and budget-constrained, this is really helpful.
Next steps
So what next? Yep, we have made some great progress but we are not done yet. The next step is to be able to get projects onto a delivery plan so that we can give more confidence in when we are likely to be able to deliver each project. This will be a big challenge because our resource analytics are not very mature – so we will probably need to iterate the approach over time. As ever, the whole approach to prioritisation and allocation is, and will continue to be, as much an art as it is a science.
Will keep you posted on how we get on, and would be interested in thoughts and advice on other approaches!