A user-centred Back-office Planning System (BoPS) for local authorities.

Description

Summary of the work We require a multi-disciplinary team with good knowledge of creating open source software in Ruby, using recent language and framework features, i.e., Ruby on Rails. This team will deliver ongoing development of existing codebase, design and testing of the Back-office Planning System (BoPS) Service. Expected Contract Length 1 year Latest start date Monday 28 March 2022 Budget Range up to £1,000,000 Why the Work is Being Done Councils lack a user-centered solution providing back-end case management, transactional functions and the database necessary to manage a planning service. The project aim is to create a back-office town planning system that uses accurate, up-to-date records and data to increase efficiency across the planning application process and satisfy the needs of end users (planning officers). In the next phase we aim to develop the MVP service into a more feature rich public beta service that continues to iterate the functionality required to process full householder applications, and integrates with legacy systems as required. Workarounds will be reduced and issues such as considerations, consultations and reporting will have a place on the product roadmap. Developing an application processing tool to handle the 'data not documents' approach and improving the validation process. Problem to Be Solved Councils lack an efficient, user-centered system that provides back-office case management, transactional functions, and an easily navigational database. Planning information is regularly received and processed as documents instead of data, creating a reliance on a paper-based process and limiting the availability, transparency and re-usability of data. The national market is currently dominated by just two providers, meaning that commercial incentives to support innovation are low. The existing systems can be slow, resistant to interoperability, and usually require planning officers to learn a number of system ‘work arounds’ just to be able to effectively manage their application case loads. The practical problems associated with poor quality software create challenges not just for individual case officers and local planning departments, but for the effective administration of the national planning system as a whole. Who Are the Users As an applicant I want to be kept up to date about the progress of my application so I know when to expect a decision. As a planning officer I need to be able to assess a range of data, from a variety of sources, to make the right decision. Local and national government needs to accurately collect and collate a range of standardised data from all authorities. As an agent I want to process any requests for further information as part of the same original application so I can keep track of applications more easily. As a planning support officer I want to spend less time doing data entry so I can spend more time on planning tasks. As a planning officer I want to easily be able to find information relating to applications which are allocated to me so I can complete my assessment more efficiently. As a planning officer I want to see known constraints automatically flagged up on an application along with suggestions for relevant conditions so I don’t need to manually type them in every time. Work Already Done The BoPS project has been underway since 2019, and now involves 11 councils in total, who have (for example) at least 3 FTEs working as part of the blended project team. BoPS is currently undergoing private beta testing using Lawful Development Certificate applications received via an integration with the Reducing Invalid Planning Applications (RIPA) (https://www.ripa.digital) tool. The project has so far developed an MVP for assessing Lawful Development Certificate applications received by the Reducing Invalid Planning Applications (RIPA) tool application service, including a user-facing interface for applicants to respond to requests. Additional information can be found at (https://bops.digital). Existing Team Between two and four representatives from each partner council are typically involved in the project team, and they perform the following functions: Leadership and stakeholder management Project Delivery Integrations, Data and Infrastructure BoPS Product Owners Content Subject Matter Experts Reducing Invalid Planning Applications (RIPA) Product Owners Content designer DLUHC Delivery Manager and Product Manager Current Phase Beta Skills & Experience • Provide a multi-disciplinary team, including 2 designers, 3 developers (min.) and one p/t delivery manager. (5%) • Demonstrate successful experience and responsibility of moving and managing a product through different lifecycle phases from Discovery through to Public Beta to Live services. (5%) • Experience of successfully working in agile teams, working to Test Driven Development, CI/CD and DevOps practices. (5%) • Evidence of successfully developing products and services that adhere to robust standards when buying and building, such as the Technology Code of Practise and GDS Service Standards. (5%) • Demonstrable ability to successfully develop software in Ruby, using recent language and framework features, i.e. Ruby on Rails. (5%) • Ability to support development of REST APIs. (5%) Nice to Haves • Demonstrate knowledge of the planning system and other relevant services. (5%) • Evidence work on similar projects involving multiple partners. (5%) • Experience of developing or working within management processes for open source technologies. (5%) • How you plan for required software Integrations with existing tools to be achieved. (5%) Work Location Remotely with some onsite workshops. Working Arrangments The work should be conducted in a collaborative and open way, working closely in a joint team with council officers, partners and interested stakeholders. Suppliers are expected to attend all necessary project meetings as required, and be available during working hours (core hours 9.30 - 5.30pm). Suppliers should have experience in using the following platforms: G Meet, MS Teams, Miro, Trello, Notion, Github, Slack. No. of Suppliers to Evaluate 5 Proposal Criteria • The team you will provide and the skills and expertise they bring. (2%) • How the approach can meet user needs, the Government Service Standard, and the Technology Code of Practice. (2%) • Proven service development experience of accessibility, iterative delivery, "working in the open" aka. Open-source. (2%) • Your approach to dealing with multiple stakeholders (skill and seniority) and managing expectations. (2%) • Demonstrate and evidence successful experience in advocating for the importance of agile, iterative and user-focused delivery, as set out in the Government Service Manual. (2%) Cultural Fit Criteria • Work as a team with our organisation, project team, partners and other suppliers. (5%) • Share knowledge and experience with other team members and partners. (5%) • Ability to flex resources up and down depending on the needs of the project. (5%) • Be able to adapt agile working practices to support the collaborative, multiple partner model. (5%) Payment Approach Capped time and materials Assessment Method Presentation Evaluation Weighting Technical competence 60% Cultural fit 20% Price 20% Questions from Suppliers 1. Hi, Can we ask which suppliers have been working with you during the Discovery and Alpha stages please? Thanks. Unboxed 2. When do you expect the system to be finally deployed? We are on track for a public Beta of the existing code-base/products starting on 1st April. 3. How does this tie in with the consolidation of your current systems? This work is being conducted as a separate project alongside the consolidation of our current systems. 4. What will you do with Building Control and Land Charges? The project has not scoped any work related to Building Control or Land Charges. 5. What integrations are you considering? The project will need to integrate with any systems required to deliver the functionality prioritised by the project team - we envisage this to at least include some legacy systems (council partner dependant) and the NLPG/LLPG. 6. Who are the officers responsible for the project? The project team will be made up of representatives from each of the partner councils and DLUHC.