To no surprise to anybody close to the project it’s finally been accepted that the Pensions Dashboard Program needs to be delayed. Take it from me, it needed to or August would have been a disaster.
And in the next few days you will see commentators telling you why it happened. Some will be right, but some will be wrong. Here I will debunk a few of the claims you will see and lay out, as somebody pretty close to the whole thing, what the actual issues are.
Pensions providers didn’t want it so they broke it – Wrong
Not true. Most open pensions providers in the DC market actively pushed for Pensions Dashboards. But far more importantly, it’s not got to providers or administrators yet. The problem is that it’s taken much longer than planned or expected to deliver the central service.
It’s because pensions data is rubbish – Wrong (sort of)
To be fair this may come up later but the delay has got nothing to do with data quality. Exactly no pensions data has been connected yet. It’s because the service that the PDP are building with their technical partners is months and months late.
It’s because the IT is actually quite complicated – THIS!!!!
In hindsight it’s apparent that not enough time was allowed to actually build the main central finder service. Turns out to create a stable platform that can draw data from hundreds of different organisations securely and send it to customers in seconds takes a lot longer than you might think. Especially when you have multiple organisations involved in building all the constituent parts. Every single working part needs to um… work. And work as the next part expects. The program just isn’t there yet.
Government is not very good at IT projects – Sadly also this
I’m not interested in sticking the boot into people I know have worked hard and diligently to try to make this work. My experience with the people on the project is good. But they have been trying to push water uphill.
The problem is, as I see it, that there is a huge inertia in Government projects due to all the people needed to sign off anything. Combined with a process that starts with a project delivery date then decides what work it needs to do to achieve that. This leads pretty much inevitably to unrealistic plans and delivery schedules.
However, my biggest criticism is also that Government is not very good at working with non-Government parties on big IT projects. There is a cultural instinct to keep everything in house and to keep people who could be partners at arm’s length. For example, every slip of the program has always only been relayed to providers and ISPs at the last minute. This has caused a lot of problems for firms that are trying to make sure they can properly comply with Pensions Dashboard regulations.
So what should happen now?
The first step in fixing a problem is admitting you have one. We have at last admitted that Dashboard needs to be delayed.
As to “next” here are my three key requests:
- Don’t demand a new staging date right away.
This is what got us into the problem in the first place. Take time to understand what a realistic delivery date is for a stable platform and then allow at least 6 months after that for the first staging date.
- Accept help.
The PDP and DWP should allow other stakeholders to be involved in the process and not keep them at arm’s length. There are people who really know their stuff on big IT integrations in the pensions industry in providers and ISPs who can help.
- Remember the prize.
It’s absolutely still worth delivering pensions data on demand in one place to customers and helping people find lost pots. It’s just taking longer than we thought.