Designing an outcomes-based method for collaborative technology projects
In the run-up to starting as Director of the new London Office of Technology and Innovation (LOTI), I’ve been reflecting on what makes technology-focused projects succeed or fail, and how collaboration between multiple organisations is different from one organisation working alone.
In this article, I’d like to share some thoughts on why:
- Projects are best framed in terms of the outcome they wish to achieve, not the problem to be solved or the solution to be implemented.
- Seeking to replicate and/or scale ‘best practice’ is a risky strategy.
- Projects that involve multiple organisations are necessarily different than projects run within one organisation.
I’ve shared these thoughts with LOTI’s member boroughs for their consideration. I now share them here to see if they resonate with readers’ experiences of working in this field.
Starting with the end in mind
When people come up with ideas for public service improvement projects, they tend to frame them in one of three ways.
A PROBLEM to be solved. (e.g. “We’re getting lots of complaints from residents that they can’t get through to our contact centre.”)
A SOLUTION to be implemented. (e.g. “What we need is a chatbot to handle routine requests.”)
An OUTCOME to be achieved. (E.g. “We want our residents to be able to effectively and efficiently get the information they need from us.”)
However they originate, I believe all projects should be framed in terms of the outcome they want to achieve, for three reasons.
1) Defining a desired outcome gives meaning to a problem or proposed solution.
A problem is only a real problem if it prevents a desired outcome from being achieved.
A solution is relevant and useful to the extent that it leads to a desired outcome.
Put differently: in the absence of a desired outcome, everything and nothing is a problem and everything and nothing is a solution.
Failing to address this makes scope creep all but inevitable.
2) Defining a desired outcome provides an anchor point that can remain fixed while problems and potential solutions can change.
During a genuine process of discovery about the nature of problems and the development of potential solutions, it’s highly likely that new things will be learned that will lead to changes in a project’s understanding and approach.
Those changes are natural and beneficial.
However, they risk being chaotic unless we can relate them to a fixed anchor point: a desired outcome.
That anchor point ensures that any changes lead to a process of trial and improvement (i.e. with each change we’re getting better aligned with our desired outcome) rather than endless trial and error (the ‘pointless pivot’, as we might call it).
I’ve seen this play out in projects that have adopted the double diamond approach without defining a desired outcome. The traditional approach of discovery and development can feel directionless.
3) Defining a desired outcome helps avoid implementing inappropriate solutions.
It’s very common for organisations to wish to replicate or scale ‘best practice’ solutions that they have seen succeed elsewhere. (Indeed — almost the entire field of public sector innovation assumes this is desirable.)
Just look at this city’s amazing approach to data! Witness how that organisation has halved its costs of delivery with this new venture! See how these organisations have transformed their approach using this new technology! If only we could adopt that same solution, we too could enjoy its benefits.
However, I believe the best practice emulation strategy has serious risks.
When we have seen a best practice solution work elsewhere (e.g. an organisation’s adoption of a particular technology), what we have actually seen is a solution working in a specific context and with a specific set of conditions.
That context and those conditions will almost certainly not be identical for a different organisation.
This is even truer when seeking to scale best practice across multiple organisations. In this case, no one individual will have complete knowledge of the context and conditions in every organisation. Moreover, the very act of collaborating creates a different context.
It’s also possible that the solution we see in context 1 is not the entire solution.
We might only be seeing the innovate or exciting part that appears in the press release or case study, or which is most visible. In digital transformation projects, this will often be the new tool or technology.
There may be other vital enablers of that solution (such a new process, a better policy or range of incentives) that are hidden to the outside observer.
Finally, in the case where multiple organisations wish to collaborate to scale best practice, it may be that the right solution is not a local copy of a good idea, but something new and joint.
So what should we do when we see examples of best practice solutions that we’d like to emulate?
I’d argue that the proper role for an example of a best practice solution is to provide inspiration for specific outcomes that we could enable. (Remember: a solution is relevant and useful only to the extent that it leads to a desired outcome.)
If one or more organisations are motivated by achieving that specific outcome, they should then return to the start of the process to explore the nature of the problems, conditions and context as they exist for their organisation(s).
Next, they should explore what initiatives would represent an appropriate solution to their problems, which may or may not include the solution that provided the original inspiration for the project.
If we were to draw this as part of the double diamond approach, we can add on a first step: defining our jointly desired outcome.
When setting out on projects that expect to have a significant technology component, I’d suggest we also try to head off the risk of ignoring the hidden enablers of a great solution by building in an explicit prompt to consider the non-technical aspects of the problems and solutions.
We can add this into our outcomes-focused double diamond, as below:
Finally, if wishing to visualise this like a project journey, with the desired goal considered as our destination, we might flip the diagram around and portray as the road below:
Readers of my articles will know that I specialise in writing blogs that disagree with my previous blogs. I have no doubt that my thoughts on this will evolve over the coming months.
In the meantime, I’d welcome your thoughts, ideas and feedback on the above.
