Welcome to Submit My Planning Application weeknotes.
For more general updates, continue to check our project site; showing all the great stuff we’re doing and key information about the project. Alongside the project site, also be sure to check out our blog post.
KEY DATE: We will be having our final Show and Tell next week on Thursday the 22nd August, from 1 – 1:30 PM. We hope to see you there, please try your best effort to attend as it’s our final one!
A big thank you to Peter N (the Applications team manager M3) for helping us understand the payment process more.
What we did this week:
- Testing the ‘Reset Password’ feature to ensure it works
- Testing the verification process when a user comes to use the service via the account creation email
- We’re identifying and fixing minor bugs as we go through the different processes within the service
- We’ve completed the integration to Gov.UK Notify
- We have completed the copy and the testing for the ‘Confirm your Submit my Planning Application account’ email
- We are finalising the copy and setting up templates for 3 more emails
- Our notification emails now have a reply-to address
- We’ve now understood validation for disabled applicants is done by the Planning Team. No validation or process is required in the SMPA product, if payment process incomplete, it should be flagged as a disabled applicant
- We’ve fixed all payload generation issues, the information entered was sent back for users to review but we spent time on improving the formatting
- We did a hard reset in our database due to rogue data being submitted to the database, We had to recreate our accounts and submit applications again. We’ve added extra validation and better error handling to ensure this doesn’t happen going forwards
- We’re working with the development team at Hackney to deploy the service onto Hackney infrastructure
- Hackney will manage data in accordance with their privacy policies – this is data from SMPA
- Working with Sarah to approve Woopra
- There will be further testing to ensure no major bugs are present within our service
- Continuing with the General To Dos; Error 404s and any session timeouts – to ensure all functionalities of the service are working
- Ensure front end bugs are addressed
- Test the ‘Payment receipt’ email
- Ensure that we’re complying with GDPR
- Carrying out Quality Assurance testing
What are we keeping an eye on?
- Integrating with Tascomi
- Address API which is due to go live on Monday the 19th of August
Thanks for reading!
Planning Applications Team
(AKA Emma H, Andy B, Andy E, Ana, Mathew T, Nic and Hidayat).
Another week skipped – I was away in lovely Norway taking trains through the mountains and cruising through the fjords (taking photos like this) which was super relaxing.
Manage a Tenancy continues apace along multiple strands. We’re continuing to close a significant number of bugs in both existing and new code and our latest feature release should be ready to go very early next week.
At the same time I’ll be reviewing the detailed submissions for our piece of “replatforming” work (moving away from our experiment with a “low code” platform) on Monday. We should be meeting the shortlisted vendors very shortly after that then hopefully be starting the development work in early September.
As if that wasn’t enough we’re also also delighted to be working with the HackIT Service Design team to plan out our next round of new development. The scope for that should be defined by the end of next week and we can look forward to getting underway.
Have a great weekend all.
This week has been a positive and productive week, for Manage Arrears. We have;
*Shortlisted Digitalmarket place bidders, and reviewed their proposals for Phase three. The outcome will be published shortly.
*+Trish Hadden shared some positive feedback relating to service charge arrears. Last month the team saw a huge reduction, approximately by 10%, in their arrears which is a result of their arrears letters being sent. Contributing factors from our project include;
- The improved content redesign of the letters
- The improved accuracy which comes from the bulk sending feature providing the ability to provide and send accurate and timely information.
*Many thanks to +Cate McLaurin for assisting with discussions around the Letter before action (LBA) and Ministry of Justice (MOJ) conversations. The Letter before action is a 14 paged letter sent to Lessee has part of the Service Charge escalation policy. We are investigating the possibility of an alternative solution to enclosing paper forms. Which will determine how these letters will be handled e.g. via Gov Notify.
*Also many thanks to +Carolina Gaspari for providing +Elaine Geeves and I with advice and guidance on UI and UX design. We learnt a lot. Particularly relating to simple tips about making use of lines and space and grouping text. We have since adjusted the layout of our wireframes to reflect the advice. Our Product owner was shown the example of these and he is in full support of us user testing these with his team next week.
Next week we will be:
- User testing case details layout designs with the Income Collection team
- Working to resolve the Hackney API/ Hackney action diary bug.
- Continuing to finalise LBA stories.
This week we focused on two main areas: continuing to better understand the scale of the issues with property and asset management data and also starting to think about how we might use the LLPG to address some of these issues (awful pun not-intended).
In order to make sure that we were aligned with other work that had been done in this area we spoke to Ian Marriot and team (including +Clayton Daniel as our demo-master) who explained the thinking that has guided their efforts on the Property Index. This tool compares data on Universal Housing (UH) and Codeman (the asset management system PAM uses currently).
This gave us a helpful overview of the scale of some of the data quality issues and also a view of some of the things they’ve considered to improve them. There were some headline numbers (more dwellings on UH than Codeman), which had reasonable explanations (UH includes additional dwelling types like temporary accommodation), but others that revealed more of a problem (blocks or sub-blocks marked as disabled on Codeman but not marked on UH).
In addition to this we have started to put together a list of all the teams / services in Hackney that make direct use of PAM data and which data items they are interested in. This will help us to start to build a picture of which data items are the mainstream ones that we need to be accommodating in our solution.
It has also helped us hone our thinking on where we draw the line in terms of which data elements to add into the LLPG to ensure we can maintain data quality (of both our address data itself which is super important to protect, as well of PAM data itself). We’ll need to come up with some clear criteria to test with PAM colleagues in the next sprint.
This week we have started to look in more detail at the LLPG itself. This has prompted a discussion about how we will test the hierarchies in the LLPG. We have discussed the merits of cross referencing vs parent child relationships as a method of creating our hierarchies in the LLPG.
We chose to test cross referencing rather than parent child as parent child itself would not allow us to have enough layers in the hierarchy due to limitations of the LLPG structure and software we use to maintain it. We considered a hybrid of parent child and cross-refs, but in our discussions parent child did not seem to have any significant benefit.
Before the end of this sprint we’ll be talking through the pros and cons of this approach with the Dev team, Apps Management and other Data & Insight reps to get some healthy challenge and ensure that our proposed approach won’t cause unnecessary work for them down the line in surfacing PAM data for applications or reporting.
Welcome to the penultimate weeknotes of the API Factory. Written weeknotes are a change to our regular scheduling but, it’s never too late to try a new thing, right?
We’ve been very busy bees over the last week attacking the task of getting the Addresses API into production on 12th August. This has involved Sandrine doing a lot of testing and raising some bugs. Liudvikas, Bukky and Matthew fixing the bugs with gusto and handing them back to Sandrine to test. We are 80% there and feeling optimistic about what’s left as it’s tasks like renaming things which, typically, aren’t too back breaking.
On the flip side of the coin we have been looking at how we control access to our APIs in a secure way that doesn’t cause massive admin overheads. I know it feels like we’ve been saying this for weeks and weeks but that’s because we have. Cloud infrastructure is a *really* complicated thing to get your head around and make choices about when you are learning everything as you go.
We have to give huge thanks to our colleagues from the infrastructure department of ICT who have given us as much time and expertise as they possibly can on the subject and also to our friends at AWS who have now run 3 workshops for us to help us get our heads around everything. We think we have a plan for the now and some great knowledge to share with our friends in infrastructure about what the tools AWS have can do and how Hackney might benefit from those in the long run.
Selwyn has been working hard to implement our plan for ‘now’ but, as with all new things, it’s been taking more time and faffing (he had to create a whole new AWS account because we didn’t want to risk breaking production services) than we would have liked but he’s made stunning progress. We’re still hopeful that a production Addresses API than can be controlled on a per API, per environment level is totally within our grasp.
And on that bombshell, I leave you in suspense and eagerly awaiting the final episode of ‘The API Factory’. A drama that has given us, highs, lows, twists turns and many good times. Here’s to the last week of the project and our most collaborative delivery yet.