A lot of this separation is baked in at the buying stage too. Discovery and alpha are often tendered as separate lots or separate call offs, so the supplier who finds the skeleton is frequently not the one allowed to start moving it, and the handover costs months. It would be interesting to see more buyers procure a single small team for a short combined discovery and alpha, with a clear break clause, rather than paying twice to relearn the same service.
Jack, your distinction between finding a problem and having the power to change it is particularly useful. The Notify example shows how a trial can work through staff effort while exposing what would have to change to make it routine.
There may also be an accountability problem at that transition. A temporary experiment can be authorised without permanently changing budgets or responsibilities. Adoption requires someone to own the costs, disruption and possibility of failure. Meanwhile, the costs of continuing with the existing system can remain dispersed across staff and service users.
Great piece man. I feel like we are returning to the concept of thinking by making. What I love is the examples of what you learnt from the making in the system itself. We’ve been creating provocatypes because in the true Dan hill nature the Trojan horse will uncover all the issues you know are there but can’t quite articulate. Which discovery was supposed to help with. Then you have the other consequence but you’ve built it already. No more investment. No it’s an old system that needs a lot more than this. 😳
And if I can recount what I and colleagues have learned to do when appropriate. We do spend time with front line teams understanding the nature of their current service. But, and this important, we understand it from a very different perspective to the one everybody already does. We look at it from an outside-in perspective, and we do that applying a systems thinking lens. So, doing the understand phase, but doing it very differently, and not in a room with designers.
As an example, when doing this with an integrated neighbourhood team, we found that the current service simply did not record the true nature of what mattered to people. We found that the referral is then made by simply selecting the easiest item on the list of referrals. We found that for 71% of people, the whole end to end case did not deal with the real issues so much that the person had to make a new failure demand.
And your point about learning when we actually do something is a key part of the comparison between the current way of working and the new approach. Often, we can only do that comparison when we test and learn.
Thanks for highlighting this, and the potential folly of simply falling into a trap of following a pre-defined method.
A lot of this separation is baked in at the buying stage too. Discovery and alpha are often tendered as separate lots or separate call offs, so the supplier who finds the skeleton is frequently not the one allowed to start moving it, and the handover costs months. It would be interesting to see more buyers procure a single small team for a short combined discovery and alpha, with a clear break clause, rather than paying twice to relearn the same service.
Jack, your distinction between finding a problem and having the power to change it is particularly useful. The Notify example shows how a trial can work through staff effort while exposing what would have to change to make it routine.
There may also be an accountability problem at that transition. A temporary experiment can be authorised without permanently changing budgets or responsibilities. Adoption requires someone to own the costs, disruption and possibility of failure. Meanwhile, the costs of continuing with the existing system can remain dispersed across staff and service users.
That is the mechanism explored in The Observatory’s https://observatoryanalysis.substack.com/p/public-sector-innovations-problem.
Your argument raises a useful further question: as experimentation gets faster, who has the authority and resources to act on what it reveals?
Great piece man. I feel like we are returning to the concept of thinking by making. What I love is the examples of what you learnt from the making in the system itself. We’ve been creating provocatypes because in the true Dan hill nature the Trojan horse will uncover all the issues you know are there but can’t quite articulate. Which discovery was supposed to help with. Then you have the other consequence but you’ve built it already. No more investment. No it’s an old system that needs a lot more than this. 😳
A very good point Jack.
And if I can recount what I and colleagues have learned to do when appropriate. We do spend time with front line teams understanding the nature of their current service. But, and this important, we understand it from a very different perspective to the one everybody already does. We look at it from an outside-in perspective, and we do that applying a systems thinking lens. So, doing the understand phase, but doing it very differently, and not in a room with designers.
As an example, when doing this with an integrated neighbourhood team, we found that the current service simply did not record the true nature of what mattered to people. We found that the referral is then made by simply selecting the easiest item on the list of referrals. We found that for 71% of people, the whole end to end case did not deal with the real issues so much that the person had to make a new failure demand.
And your point about learning when we actually do something is a key part of the comparison between the current way of working and the new approach. Often, we can only do that comparison when we test and learn.
Thanks for highlighting this, and the potential folly of simply falling into a trap of following a pre-defined method.