Our team has just wrapped up the thirteenth sprint of our Back-office Planning System (BoPS) beta phase with Southwark Council, DLUHC and partners.
Our aim is to create a user-centred back-office planning system that uses accurate, up-to-date records and data to increase efficiency across the planning application process and meet the needs of local authority planning teams.
Find out more about the project here: BoPS digital.
Progress across the last sprint
The theme for the past sprint focused on validation improvements such as the assessment process including testing the new ‘assessing applications against policy’ which was demoed in the last show and tell. Iterating on validation has also been looked at as well as smaller tasks such as; the ability to edit dates on manually uploaded documents and ensuring applicants can reject all validation requests. Some research was conducted with officers on immunity applications and the continued work of improving bugs was also looked at. We also looked at the introduction of Cucumber specifications and Ben Baumann has joined the team from Unboxed and will be part of the development team.
Live applications
Currently we are in the private beta phase meaning the partners are accepting LDC applications through RIPA and they are being processed onto BoPs. 14 applications have been received so far through BoPs across all the councils. Throughout the project, an agile approach has been taken and during the private beta phase it has been helpful as partners can easily share and feedback from applicants, any questions they have for each other and any possible bugs that may come up, which can be addressed as soon as possible. All live applications are being dual processed at the moment as there is no public interface for BoPs.
Edit document date received
The importance of editing the date the document is received when manually uploaded is so that documents can be recorded when they were received into the council to determine the valid from date. This date however may be different from the date the document was uploaded to the system, so to support this, two types of documents have been identified, documents arrived from an API, i.e those that come through RIPA or when an officer has made a validation request. These give officers the ability to make digital requests which send a message to the applicant requesting them to upload a document or make changes. These are then automatically uploaded to the system, dates are captured and the officer then has the opportunity to go and edit the date received. It is also important for officers to understand that the two types of documents work in slightly different ways.
Applicants can reject all validation requests
When an officer comes across an issue with the application - for example, if a document has been submitted and it is missing a scale bar on it, this becomes an invalid document meaning the application is invalid. So an officer may send a request to the applicant asking them to replace the document with one that has a scale bar. There were variations of validation requests, some looking at red line changes, incorrect fees and new or replacement documents. Some of the applicants could accept or reject these proposed changes however for document requests, they were only given the opportunity to upload a document. To ensure consistency and that applicants and officers have a strong line of communication, applicants are now given the choice to accept or reject requests for new or replacement documents as well as other requests which may relate to fees. This is important as it keeps the consistency across the way these different requests work and supports the transparent, open conversation between the councils and applicants.
Research on officers assessing immunity applications
How officers can assess immunity applications has been looked at. Different officers have been spoken to, exploring the pain points and the goals of what they are trying to do. This has highlighted lots of topics such as document management, lots of administration tasks which abstract from the actual process of determining and assessing the evidence. So ways of supporting that have been looked at via some sketching which has been going along with the research activities.
Testing ‘assessing against the GPDO’
In the previous show and tell, a demo was shown of the new application process and that consists of the assessment against policy action. This is where officers can select which classes of the GPDO they want to assess the development against. This allows officers to view the GPDO legislation for each class in turn so they can select whether the development applies with that requirement. This has since been tested with six officers from three different councils so that their experience could be recorded using the new process. The feedback was really positive. There was an overall feeling that it was clear and an intuitive method for assessment and also easy to follow, officers were also pleased they were the first people to see that. They also felt that it saved them time to refer across to the legislation but they did note there was no column to record comments which is something we already plan on adding. This will allow them to record if a development complies or not and also why it does not comply if applicable. There were some suggestions about other small changes such as a different title for the tasks, so instead of referring to assessment against policy, changing that to assessment against legislation. Lastly there were a couple of thoughts as to whether it would be best to have the original tags from the GPDO put in there or if there should be a use of more simple english as it can be difficult to understand but as officers, part of their role is to be able to read the legislation,
Introduce Cucumber specifications
Tests were written in a way that encapsulates the business logic which allows us to outline how BoPs behaves which is useful to consolidate the way BoPs works. Information has been gathered from various sources. As this is just the beginning, as the application is developed, better tests will be written and the ability to be more precise increases in some cases. It has already been helpful for the GPDO references for example, so the team are really excited to protect themselves with this specification moving forward.
Updating calendar days to working days
Up until recently, normal days were used for when an application is received, which meant an application would expire between 35 to 40 days after being received but now, it is just being accounted for normal days excluding UK bank holidays and weekends from all of the accounts through the application.
The user experience has also been looked at throughout the application when going through the validation process steps. After testing with partners, it was decided there was space for improvement within the process such as the language has been made clearer and the process could be iterated upon. So work is being done to improve the overall experience so that steps taken through the process feel more natural and logical. We want to ensure that even though the screens being shown are in a staging environment, we want to make sure that before we go to production, before it is pushed into a real world environment, that it is a clear process.
Towards public beta for the MVP
Currently we are in the private beta phase and there may be questions on when the public beta phase will start. We have begun to scope out what would be needed to progress onto public beta, currently there is an accessibility order just about to start for RIPA. This will ensure that everyone can use that service and once that order is complete, the ‘find out if you need planning permission’ part of the service soon. However the full move to the public beta for RIPA and BoPs will be complex as it involves partners sweating the details of photosystems, drawing out any bugs and making sure all the planning legislation is cracked within the systems before it goes live. Staff also need to be trained in order to know how to process our applications on BoPs and make sure there is enough support in place for the public who will be making applications. Once the links on the partner councils websites go live, a lot more cases will be being received and we want to make sure we are ready before taking that step. Creating an API is also being looked at which will link all the data to a digital planning register so dual processing can stop and everything processed on RIPA and BoPs is visible to the public.
What’s next?
In the next sprint, further validation improvements will be looked at including improving the process. We will look to continue testing ‘assessing applications against policy’.
Changes to the applications description will be looked at outside of the validation process it currently sits in, multiple file uploads and bug fixing and bring more GIS data and this time ward data because we were recognising that some local planning authorities allocate cases by ward so that data will be helpful to have in the tool.
Lastly further look into how dates are calculated within the tool particularly expiry and target dates.
The BoPS team are keen to speak to more planning teams in other local authorities across the country to set up user testing sessions. If you’d be interested and can spare some time to help with the project, please get in touch via bops@southwark.gov.uk.
See the full recorded Show and Tell as well as a live demo here:
https://www.youtube.com/watch?v=M-HpeKF5Sgc&t=1076s
Follow BoPS on Twitter for the latest updates: @BoPs_Digital.