The Customer Data Service (CDS) system was launched last November. It allows us to transfer data in near real time between the multiple contractors who deliver the National Careers Service (NCS).
In previous blogs we’ve looked at the benefits of CDS for customers, the benefits for SFA and our contractors, and how CDS could potentially be used across the civil service. I’m going to look at some of the lessons learned on this project.
What we delivered and what we learned
CDS is a messaging service that enables data to be transferred between the systems used by any of the contractors in near real time (within five seconds). It works very well. For the technically minded, it’s a JBoss Fuse Enterprise Service Bus.
CDS was a challenging project, both in terms of the scale of the work and its technically complexity, but also because of the number of contractor organisations involved. For Joe Billington, the senior manager ultimately accountable for this work, the project could only be deemed successful when CDS was working and being used by every type of contractor.
So what did we learn over the course of this significant project?
Be clear on the scope of services you’re buying
We went through a careful procurement process to find a supplier to work with us on the CDS programme. The chosen supplier won the bid on quality and cost.
As the programme progressed, some of the SFA team weren’t happy with what the supplier was delivering. The products were OK but did not fully cover what business logic was needed in contractor systems for the integration to work effectively and consistently from end to end. Our supplier did not believe that this was part of their remit.
Our procurement documentation hadn’t been clear enough on the scope of the services we wanted. At this point we took the difficult decision to pause the project and revisit the contract.
A waterfall project can become agile, and it’s worth doing
Once the project was on pause, we began the process of agreeing a revised contract with the supplier based on a new approach.
Because of the size and complexity of the project, we had some concerns that problems or gaps wouldn’t become apparent until services were tested from end-to-end. To reduce this risk, we decided to move from a waterfall to a coordinated agile approach. Rather than delivering the whole service with a big bang, we ran a pilot with five contractors (covering all types of contractor role).
Collaborate, collaborate, collaborate (and not just with the technical people)
There were a lot of stakeholders in this programme. Collaboration was key and on the whole worked very well. However, at the start it was generally the technical people from each stakeholder organisation who were involved. We really hit gold when operational people got involved and saw that this was not just a new IT system, but a new service which could benefit them and their customers. Stakeholders’ sense of ownership of the service grew significantly.
Engagement was enhanced further when stakeholders found they could talk to the Product Owner, David Cant, to influence the work we were doing and how things were being done.
Once they were more involved in the programme, the operational stakeholders also realised they needed a longer training and operational deployment period for the new service. For them the programme was only complete when the service was live and they were using it.
A common problem?
CDS solved a problem which we suspect many civil service organisations face: how to transfer data in near real time between multiple contractors. As far as we know, the CDS project is unique across the civil service, but I’d be interested to hear from others working on similar things.
The solution we developed is scalable and transferable - we’d be happy to share what we learned with others.
This post is part of a series on the Customer Data Service: