“Re-arranging the deckchairs on the Titanic”: Why the launch of the new Energy Performance of Buildings Register is important
MHCLG officially launched these two services today:
Together they make up the Energy Performance of Buildings Register (hereafter, EPB). They’re technically in private beta, but because of the way certificates are generated, they’re actually in use by everyone. The team talked about launch day on the MHCLG Digital blog.
The launch-day blog is only our second digital blog about EPB, although hopefully there will be more to come. The first was about the technical choices we made. It’s gathered a few comments since we moved off the old service, most of which seem to think building a new service was a mistake. One person complains about change, another asks for UPRNs (coming soon), and the first comment gave this piece its title.
I can see where the Titanic commenter is coming from. Energy Performance Certificates are supposed to help you save energy, but that’s assuming you as a house-buyer or renter look at them — which you probably won’t. Are there other things the government should be focusing on fixing? Short answer yes; long answer, let’s not go into it.
And yet, I think it’s very important that we launched this service. It gives us a basis to help improve energy in the future, the full dataset is really useful to a lot of people and we can easily get at that data now, but more than that:
It’s an exemplar
GDS’s transformation programme (2013–2015) “sought to transform 25 major transactional services to make them digital by default and simpler, clearer and faster to use.” These were called the exemplar projects.
I was in the right place at the right time and ended up as the Delivery Manager of one of the Home Office’s three exemplar services, Registered Traveller. If you don’t know (and you probably don’t), Registered Traveller is a service that allows frequent travellers from certain non-EU countries to get through the EU gates at airports.
I joined the project after we’d already passed alpha. It was a massive agile team, mostly contractors, and we had GDS people embedded full time to help make problems go away. I remember asking just before I joined the team what my boss and our other Delivery Managers thought the point of exemplars was. The reason I asked this was that the Home Office had a lot of other digital projects running at that time, of which this was merely one of the best funded and resourced. Looking at Registered Traveller made me think that an exemplar project was just a project that could spend as much money as it wanted and had the luxury of time to change programming languages half way through development or completely re-work the user journey to make it slightly easier for the small number of probably highly digitally literate people who would be using the service.
I think a lot of my perspective was coloured by how relatively unimportant the user need for Registered Traveller felt to me. I was also extremely new to building digital services and didn’t understand how important it would be to have a service that had been built well, rather than fast. But it’s still possible that the Home Office — a big powerful department that quickly grew its digital skills — didn’t need exemplars to show it how to build digital services. It needed spend controls and the Standard.
Meanwhile, at MHCLG … the digital revolution didn’t happen until much later.
We’re a policy department. We don’t really have transactional services. When I joined MHCLG two years ago, I took over responsibility for five digital services: all of which were built in the same proprietary tech-stack, almost all of which had been designed as copies of older services. One had passed a GDS alpha assessment on its second try, but had since sought an exemption from the beta. None of the others had passed any assessment.
None of the five were the Energy Performance Certificate Register. This was being run by a contract manager in a policy team. For a long time, the project to do something about the fact that the ten-year contract had already come to an end was called ‘The Re-procurement Project’ (you can see it in this DOS brief). I sat in boards where I was asked what mitigating factors I could highlight to counter what was considered the project’s top risk: that we weren’t experienced at building digital services.
EPB is very different from anything we’ve built before in these ways:
- It’s going to go for a GDS beta assessment — and should pass because it’s been built to meet the user needs of citizens, in good technology, by an empowered service team many of whom are civil servants who will continue to work on this service after it goes live and are led by a full-time Service Owner from the relevant policy team
- It’s accessible
- We own the intellectual property and all the technology is open source
- It’s running on GOV.UK PaaS
- It has analytics
- It has LOTS of automated tests
- It costs less than half of what the old one costs to run
If you work in a digital team in government, many of these hopefully seem like givens; they weren’t to us.
July 2018, Discovery: GDS doesn’t trust us (for good reason)
EPB probably wasn’t supposed to be one of my services, and still sort of isn’t. (I mostly take responsibility for services that benefit the whole Department, rather than this service which is specific to one area). I seized the opportunity to be involved with this public-facing service when the policy team wanted help writing a Digital Outcomes and Specialists (DOS) brief (advert) for what was probably an alpha. They’d said they’d done a bit of discovery already.
I’d just come from working at GDS on the Digital Marketplace. I loved procurement! We wrote the brief and posted it.
There were lots and lots of problems with it.
The first was that it was for an alpha. I’d confidently stated that if there was more discovery to do, we could just extend the alpha a bit. Our GDS spend control contact was watching like a hawk and immediately got in touch asking us to take it down, as we hadn’t done discovery. What the policy team had done before did not count.
We took the brief down. Posted a combined discovery and alpha brief … which we were told to take down, because we weren’t allowed to publish a brief covering two phases at once. This was blatantly not true for other Departments and I later found out was a condition imposed on us because GDS didn’t trust us not to just outsource the whole thing to a company, like we had before and wanted to put up as many blockers as possible to this happening. This is super fair, because this is almost exactly what the Department tried to do a few months later. It was the right thing to do. But being forced to re-procure for each phase was incredibly time-consuming.
There were lots of other reasons we had to take down the brief after those first two times. I don’t remember why. I remember seeing digital government people judging us for it on Twitter. At the time, I said nothing, although inside I was fuming. (I’d worked at GDS the month before! I was trying to do the right thing! We were a tiny Department doing our best. Why couldn’t people go and make fun of DOS briefs published by the Home Office or something?)
Anyway. We procured the discovery. We ran the discovery. It was slightly underwhelming — four weeks isn’t long enough IMO, and the team told the policy stakeholders that nothing much needed to change. (Really??) Still, it was enough to proceed to alpha.
November 2018 — April 2019: an alpha that doesn’t pass assessment
A different team won the right to do the alpha. They ended up having to do a lot of discovery again … because they hadn’t been involved with it.
At this point, I introduced the first civil servant into the team — a product manager! Matt had worked as a Product Owner on one my other services (after it was launched, the design decisions had been someone else’s and he was doing a great job making it better) and I’d hired him directly into Digital. EPB wasn’t one of our most important services, but I was still allowed to put him into the team, which was something I really wanted to do because it would give him the chance to be surrounded by digital people and work in the way I wanted everyone in digital to work. (Exemplar, innit?)
I’m not going to talk about what happened in the alpha that much — in part because I wasn’t there. My job is mostly behind-the-scenes, in the gaps between the phases. (The beta team chose an iceberg for their mission patch, because so much of what the service really is isn’t visible. The public-facing website is just a tiny part. So too, for me, the work of building a good digital service, which — partly, because I didn’t have to do it — I think is the easy bit. All this other really hard stuff happened below the surface.) I will say, the team were delightful. They did some things well, some things less well, but they were thinking like a digital team. Overall, I thought they would pass.
They invited to me to go the alpha assessment with them. It was in the Treasury building and there was no TV to do the demo on or projector, so I had to walk back to our building to get a projector.
We’d done a mock led by Tom Bates, who works for us (hooray!) but who had been a Digital Engagement Manager at GDS for some years. That means he’s seen a hell of a lot of alpha assessments. Tom thought they would pass.
The board meetings were still really difficult. Both the supplier (who was a supplier, but who was also… part of a team) and Matt the Product Manager and I (not suppliers at all) were being treated as suppliers by a policy team used to working with suppliers. People wanted us to do things for them, and they wanted to know why not if we didn’t do it right. Of course, we said repeatedly both what we thought was true and what we knew the board wanted to hear: we would pass.
I got a phone call from our Digital Assessment Manager the evening of the assessment telling me that we’d failed. (“Didn’t pass” — whatever.) You can read the report online, of course.
This was a horrible shock. It took a few weeks for the report to be sent to us (due to assessors being on holiday, nothing to do with me), during which I spoke to quite a few people at GDS. I wanted them not to change the report to say that we’d passed, but to be as kind as possible to the team because I feared what would happen when the report was circulated.
One of the things we failed on was not having a plan for either user research or technology in beta, but we’d been specifically asked by GDS (for good reason!) not to do a single procurement for a team who could do both alpha and beta. There was no way at this stage we could get more than one civil servant onto the team, so to this day, I think it would have been wrong to produce such a plan. I’d advised Matt to wait and build one with the people who’d be doing the work.
We needed to do more on design — but we’d committed to not just building a copy of the prototype we showed at alpha, we’d continue to iterate it. We hadn’t done enough usability testing? We’ll keep testing in beta. I thought the alpha we brought to that first assessment showed that we were trying to do things right, and as an assessor, that’s the kind of thing I’d pass a team for at alpha.
Is it the panel’s right to fail us? Of course. Don’t I care about quality? I do!
Am I still upset about failing? Of course I am :(
Let’s talk more about what it meant.
April 2019 — June 2019: Alpha 2, in which failure is not an opportunity
Often, as assessors, we talk about how failing can give a team the support they need to make changes that were blocked by the organisations they work for — I have definitely seen this happen. At other times, we talk about how failing a service will cause the team to lose any credibility they have with the organisation, even though the team tried their best and the organisation stopped them reaching their potential.
In this case, I was really worried the latter would happen. In the end, it didn’t have as much of an effect on my team as I’d feared — perhaps because our assurances we would definitely pass had never been believed. The supplier did definitely (and unfairly) lose credibility with the policy team. The other possibility mentioned above (blockers finally removed!) didn’t really happen either, though.
What did happen was that I had no contractual vehicle to do more work on the alpha, in order to return for another assessment. I’ve never seen anyone talking about this before, although I assume it must have happened to others!
The contract was for a certain amount that covered alpha only. We’d already used the one allowed extension to give us more time to prepare for alpha. I could not legally bring the team back.
This was basically a disaster, although I downplayed it at the time.
Fortunately, by April 2019, we’d hired a team of civil servants to do something completely different (apply User-Centred Design to policy!) and Paul Downey’s Digital Land team had both a developer and a content-designer: the roles we didn’t have. I’d recently lured my friend Kev from Cabinet Office (previously GDS) to come and work for us as a Technical Architect, and I put him on the team too. Then left him there.
I’m really grateful to everyone in my management chain and to Paul D that all these people were allowed to go and work on trying to pass the alpha again, instead of whatever they were doing before. I’m also grateful the supplier of the first alpha allowed us to directly hire their user researcher through the Management Consultancy One framework. They didn’t need to do that, but it helped at a time when we needed help.
Again, not going to talk too much about the work that was done in alpha 2. The team experimented with some interesting designs for the certificate, which were ultimately unacceptable as they didn’t feature the iconic steps. When the re-assessment happened (with as much of the original panel as possible), we were still criticised for not having a plan for beta, even though we still didn’t have a beta team in place. But this time they agreed to let it slide.
It probably doesn’t need stating but my big learnings from this period: Don’t say you’re going to pass, because you literally don’t know. Don’t leave yourself no way to recover if you don’t pass!
June 2019: Money for the right kind of beta is approved
Passing the alpha assessment was a major credibility win in exactly the way failing hadn’t been as much of a credibility hit as I’d assumed.
Matt and I also had another win around this time in that MHCLG gave us permission to spend money on a beta (GDS would then give us permission to spend the money that MHCLG had given us permission to spend because that’s how government works). This sounds like a boring part of the story, but I actually think it’s the most interesting part.
Here’s what happened:
The policy team hired an external business analyst to write a business case for beta. Even though the case was: we have to have it, here are some options, this one is both the cheapest and will pass spend controls so we should do it. Or should have been. (I have a lot to say about the business of writing business cases, which I won’t say here.)
I thought I’d already convinced everyone we should go for a disaggregated contractual model, host on GOV.UK PaaS and hire civil servants. This is much easier to do when you can say ‘Cabinet Office says you have to take responsibility for your digital services’ — thanks GDS!
The previous contract was what’s called a concession contract, which means that MHCLG didn’t ever pay for the service to be built. What we did was put a contract in place where the supplier got money from (in this case) the fees paid every time someone needs a new energy performance certificate. The supplier would collect the money and cover the costs of running the service, and then also make a profit on the costs to cover the cost of building the service in the first place. This incentivises the supplier… not to change the service very much. It also outsources most, if not all, decision-making and ownership to the supplier. For these reasons, it’s generally not the kind of contract you should use for building a digital service that is compliant with the Digital Service Standard. But it’s good if you don’t want to think much about your service. I was aided in arguing against this kind of contract by some of our excellent commercial people.
But for some reason, because we were supposed to be considering all the options again at beta, the concession contract suddenly appeared back on the table as an option. As did, putting out a single tender that would cover the whole service: development, hosting, phone line, the lot.
In the end, I offered to write the business case for beta so that it would say what I wanted it to say, which was that all these other options were very nice or something, but realistically disaggregation and MHCLG-ownership was the only option. At the time, I definitely thought: “I’m the Head of Digital Delivery!! I shouldn’t be doing this!” More than once. We’d also already paid someone else to do it, but it was worth it to get that control. Matt and I wrote the business case with the help of Alice, who had just joined my team.
The business case went to what’s called Investment Sub-Committee (ISC), which is a meeting where important people from MHCLG (including our Director, Paul Maltby) scrutinise big-money business cases.
I thought we were writing a Full Business Case — which is essentially the final one you have to do (like the ‘beta’ of business cases; we all know ‘live’ rarely happens). At some point, the one we’d written was turned into a Strategic Outline Case, which meant later there would have to be another Full Business Case written by another business analyst, but the important thing was that our case was approved enough that we could procure a beta team. On the condition … that the policy team hire a full-time Service Owner for the service.
This is the kind of impactful change that failing a GDS assessment could have made. Great move by ISC! Alice was asked by the project board to help them understand what a Service Owner was — she wrote this blog about it.
I was invited to be on the interview panel, and we hired Dean. He joined just after procurement for beta. A third supplier (so the fourth team) was appointed and started work on the beta with Matt and Kev and Dean— they were, also, very good.
September 2019–onwards!
From my perspective, this is where it gets good and where I stopped needing to be involved.
I stopped going to the project board after I heard one of the policy team say something like, ‘I can’t see a reason why we shouldn’t deliver before the end of the legacy contract’. That was when I knew we were going to be all right.
We’ve just gone live with what is essentially a private beta …. that everyone can use. (So… public beta? Except we still need to do an assessment.) It’s been a year since the beta development team started.
During this time, the Department has re-focused to support a potential no-deal Brexit twice. On both occasions, I feared that any civil servants we’d put into the EPB team would be seen as non-essential and asked to work on supporting Brexit. Thank you to those who protected them from this re-assignment and let us continue!
Also, COVID happened, obviously.
Also, a bunch of setbacks that were nothing to do with the team we’d appointed: things like systems that had to connect to ours that nobody had mentioned, and data being stored wrong in the old system so it couldn’t be moved to ours and we had to go back to a really really old database. I saw these setbacks as more wins, honestly. Each one proved to me again that we were right to build in an agile way (but of course!) rather than writing a list of requirements up front, which would have failed to cover this happening.
When the second Full Business Case went to ISC, it included a recommendation that we should hire a full civil servant team to run the service, rather than relying on contractors. Today, all the roles in that business case have been filled apart from one final developer. We put that job ad back out recently and applications closed last week.
GOV.UK PaaS has been amazing. I know a lot of other government departments have their own platforms already, but for us — a department without many digital services — it could not be better value. I highly, highly recommend it.
The team have been amazing. The Service Owner has been amazing. And together, they have built an exemplar that we can point at, and say: MHCLG can build digital services, and we build them like this.
