You can spend months fine tuning your LLPG to the extent that it becomes extremely accurate. However, if the LLPG is not integrated into systems and simply resides in a “silo” on your PC, then there is pretty much no return on your hard work.
Don’t get me wrong, this is not a caveat to say you can have a sloppy LLPG; you simply can’t build a data infrastructure upon a sparse, inaccurate data foundation. Conversely, if you do not strike a balance and link to other systems then it is safe to conclude that your LLPG is not working for you. Needless to say, you need to put the work in to get the results out and that’s where data quality comes into play. The LLPG must firstly be brought up to an acceptable baseline quality before utilising it fully. The monthly improvement schedule indicators really do help with this along with a few steps we took below.
Where to begin..
I’m in no position to advise how to improve your LLPG step by step, but I do believe if you should take a single step, then it should be a step back to look at the overarching interactions with the LLPG plus all departments and systems that utilise addresses.
When I first took up the role as LLPG Custodian for Harrow, I wanted to fully understand the present “LLPG picture”. To do this I drew a system flow diagram. This detailed absolutely everything surrounding the LLPG: who updates it; the sources of address change intelligence (inputs); who I query issues with; what other systems I consult; who / what the information gets fed to and what format and frequency. This also included systems the LLPG did not (yet) integrate with.
London Borough of Harrow Initial LLPG Flow Diagram
From this diagram I was able to create a strategy outlining where I wanted the LLPG to go. For example, a lot of systems were still consuming the LLPG in DTF 6.3 format which I felt was not taking full advantage of the additional DTF 7.3 fields such as “BLPU Class” or “Parent UPRN”. A new spec for these systems were written and were consequently updated in-house.
Additionally I felt this exercise was great to identify what I call the “Address Change Intelligence Loop”. Address Change Intelligence can be loosely defined as information pertaining to a property and its lifecycle. I like to refer to it as the address information that is used to modify and update the LLPG i.e. the inputs into the LLPG. By adding “Loop” at the end of it, I’m implying that I see this as a cycle. For example, UPRNs and addresses are supplied to council tax, but to really get a return on this flow of information I aim to look at the intelligence I can obtain back from council tax and see how this can be re-inserted into the LLPG. Information is essentially a two-way flow and the aim is to capture it to enrich the LLPG.
For example; IA provide monthly unmatched council tax records containing unmatched Ctax / NDR records and properties that are newly added. But what about monitoring change? Account closures can act as flags for imminent address changes and are able to pick up the high volume of change in NDR properties. I since requested a monthly account closure report from our Revs and Bens department and we can now attempt to keep track of NDR that little bit better.
Similarly, the flow diagram Identified our Communications department as a large consumer of addresses, conducting leaflet drops and bulk post outs. Once again, drilling down to see what happens to the address information unearthed a great opportunity. Mail that can not be delivered by Royal Mail gets sent back to the council and is marked why it was returned. The reasons either pertain to the occupier or to the physical property itself. The latter is invaluable as it allows me to query the LLPG to verify what the issue could be. This consequently lead to the development of the “LLPG Barcode project” which essentially converted UPRNs to barcodes and placed these onto posted media and allowed for rapid query list creation from the returned mail. This project managed to get some great recognition by winning the NLPG Technology Exemplar Award 2010.
Final thoughts..
I see the LLPG as a hub of address information which is passed on to other departments who then further utilise it. Rather than just leaving the flow of information at that, further address change intelligence can be gained if you delve deeper into how other departments utilise the address data and what actionable information is returned. This can then be used to improve both data quality and integration of the LLPG.
