Developing a minimum viable Business Index

Hackney has  successfully completed our MVP for the Business Index (BX) a couple weeks ago and now we’ve had our project retro, I thought I’d share some thoughts after reflection. This is my first experience of working in an agile way, along with other team members in Data & Insight. There was much to learn along the way and valuable experience gained. To that extent, the BX MVP was much more than the creation of an automated ETL process and REST API.

Background

At Hackney, there has historically been an issue with duplicated business data within the systems as the business name has usually been a free text field with no validation. There’s a famous case where a supplier who was on our trusted supplier/contractor list had had numerous enforcement actions taken out against it but because there was no validation on the business name, upon investigation it was seen that this particular business had been created differently 18 times – therefore avoiding detection and being able to remain on the ‘trusted suppliers’ list. This was just one of the examples of how free text recording of businesses in the council has been allowed to proliferate bad data and therefore making it much harder to join up data and services.

Set up

We appointed two agencies to work with us – Unboxed and MastodonC. Unboxed were to carry out our user research and MastodonC for the technical build. I was appointed Product Owner and so the project started in earnest. We had 6 x 2 week sprints to complete our MVP. After extensive user research and many times defining and re-defining our scope for the MVP, the user that we thought we could benefit the most in this iteration would be the developers working with the Public Realm Digital Transformation team – namely working on a new application for businesses wishing to apply to for a Shop Front License. This would be a new application for a license which would then serve to hold all other license details in the one portal. They had a need for an applicant to enter their postcode, select their address and select their business name associated to that address – thus keeping the data consistent.

https://hackney.gov.uk/markets-shop-front-traders

 

The build

The technical discovery and build came next. We needed to derive the business name and the key datasets we would be using would be LLPG (Local Land and Property Gazetteer), Non Domestic Rates and Civica APP (where currently all license data was sitting).  The LLPG is the councils core address dataset and each address has a unique property reference number (UPRN) – most systems in the council are integrated with the LLPG and hold the UPRN against their addresses. Civica APP has the UPRN attached to it’s licensing data. Non domestic rates doesn’t have the UPRN but the reference number for Non Domestic Rates is held in the LLPG which creates a link. By using these 3 datasets, we would determine which was the correct business name for property. Our logic was determined as – Business Name would come from LLPG – if no business name was present in the LLPG then it would come from Civica – if multiple names existed in Civica then the last seen date would be used to determine the name put forward for Shop Front Licenses in the API. We had decided that only 1 business name would be returned in the API and there would be an option to add a new business name if it wasn’t returned. This will be sent through to the Data & Insight team for investigation/verification and then added to the LLPG. A link to our API is below.

https://api.hackney.mastodonc.net/index.html#/api

 

Looking back…

As mentioned at the start, this was the first time I and other members of the Hackney team had been working on an Agile project and I don’t think we could have achieved our MVP without doing so. The project team stand-ups were an essential part of this – even if you had nothing to update, just keep in the loop and give a smile and a wave to the other members of the team made a difference. Same format each day – What did we do yesterday, what are we working on today and any blockers – jointly being able to update our trello board. This kept us on track for each sprint. However, after our fortnightly Show & Tells where we shared what we had done in the previous sprint – we would hold a Sprint Retrospective and planning session for the next one. It was these that were, I would say, the most important part of the process. Even though we spoke to each other everyday, it was during the retros (mostly) that concerns were raised – honestly and with respect.  

After successfully completing our MVP we had our final Project Retrospective. Whilst working on the MVP there were a number of things that went well – some that didn’t… by having a Project Retrospective it was a great opportunity to capture all the learning – by everyone. There were a few things which were specific to this project alone but most things can be applied to future projects.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.