If you’ve been following my blogs on the dashboard , you’ll know that I’m not in the love with giving any one organisation a monopoly on finding pensions and delivering data to one or multiple dashboards. It’s like giving BT a monopoly on phone lines (didn’t work out well).
But I am a fan of BT when it competes and am a BT customer for the services I can choose. I will probably end up an Origo customer for pension finding – even if there are multiple dashboards, because – like BT – Origo are the industry standard.
So when I met Origo last week, it was a friendly meeting. It reminded me of my early meeting with PADA (the precursor to NEST) who similarly wanted to run a monopoly of workplace pensions, and have since slipped into the workplace pension ecosystem “primum inter pares”.
This article is about an alternative to the single pension finder service and has come out of a few days thinking – following my meeting with Anthony Rafferty.
A Tech- Spint
One idea is for a Tech-Sprint between those wishing to provide the plumbing for the pensions dashboard.
In product development, a sprint is a set period of time during which specific work has to be completed and made ready for review.
This is not my idea – it was given me by a certain bearded Scotsman who I won’t embarrass. Here is how it might work.
The Tech Sprint could be started as soon as a planning meeting was completed. The planning meeting would determine what the role of a pension finder will be, in my view each pension finder would not just manage the dashboard ecosystem but help build it.
For dashboards to work, all the data providers need to be connected with the dashboards using data gateways called APIs, you can only go through these gateways to collect the data you need if you can identify yourself and those you are collecting data for.
Building the identification kit and the APIs should be collaborative – we really do need consistency here or else we will get into the kind of VHS/Betamex debacle that messed up video.
So the Tech-Sprint would begin with a project to agree the data standards for verification and for the APIs. Collaboration on this mini-sprint will be essential – not just to the successful creation of the standards – but to future participation in sprints – you’ve got to be in it to win it
What does success look like?
It strikes me that whatever the procurement exercise, the criteria for choosing a pension finder will risk being totally spurious. We neither know what the challenges of pension finding will be nor the capacity of each candidate to deliver.
If we don’t know the question – how can we know the answer.
The best way to establish winners and losers is to set each provider to work.
For me, the key test for a pension finder is whether it can find pensions speedily and accurately. For those pension finders who pass muster , the proof of the pudding will be in their capacity to deliver.
A no-lose strategy
In setting up a tech-sprint to a single pension dashboard, the DWP would be adopting a no-lose strategy.
If it proves that a single pension dashboard provider emerges as the unanimous champ, then we they will have a case for a monopoly.
If there is a competition – then the DWP, the pensions industry and the consumer will be a winner.
And the point is that we will know a whole lot quicker than if we go through a cumbersome procurement process.
The old-school process has no place in the delivery of a new-school pension dashboard product.
Let’s adopt this strategy.