DD2067 London Development Database

Type of decision: 
Director's decision
Code: 
DD2067
Date signed: 
14 March 2017
Decision by: 
Fiona Fletcher-Smith, Executive Director of Development, Enterprise and Environment

Executive summary

Approval is sought from the Director to spend up to £80,000 for a redevelopment of the London Development Database (LDD) to achieve a number of significant improvements to the system, with priorities to be determined in consultation with users in the GLA and the London Boroughs. The primary objectives are:
•    To change the code and database structure of the LDD to accommodate additional data
•    To improve the user interface so it is easier for users to add and check the data
•    To improve the data upload functionality to allow new or missing data to be uploaded directly to existing records
•    To align the LDD with other planning systems to enable reporting across multiple systems (e.g. the SHLAA and PAWS systems)
 

Decision

The Executive Director of Development, Enterprise & Environment approves expenditure of up to £80,000 from the planning budget on software development services, from Proband, which are required to carry out a number of improvements to the London Development Database. 

 

Part 1: Non-confidential facts and advice

Introduction and background

1.1.    The London Development Database (LDD) stores information on land use change shown by planning consents. The data is supplied by the 33 London boroughs and stored and managed on systems maintained by the GLA Technology Group. The database was established to allow the Mayor to fulfil the duty outlined in section 346(a) of the Greater London Authority Act 1999 “to monitor the implementation of the spatial development strategy”. It provides essential data for the London Plan Annual Monitoring Report, the document produced to address this duty. It also provides valuable information on development activity in London that is used throughout the GLA group, within the London Boroughs and for research and analysis by a wide range of organisations and individuals with an interest in planning in London. It is considered to be a major and unique contributor to the credibility and effectiveness of the evidence base which has underpinned successive iterations of the London Plan and development of SPG. 

1.2.    The importance of the LDD is such that it is the subject of an Information Scheme agreement between the Mayor and the 33 London Boroughs, as permitted under section 397 of the GLA act. This agreement requires the London Boroughs to provide data on the relevant planning consents in their area and to monitor their progress (paragraphs 2.8-2.10), while the GLA is responsible for the design and development of the data transfer tool (paragraph 2.17).

1.3.    The LDD is a web-based application that was first built in 2004. Since then it has been subject to incremental development to ensure that it remains relevant and capable of meeting the expectations of the many users of the data. The last set of enhancements was carried out following the signing of ADD282 in 2015. A DAR was also approved in December 2014 to migrate the database from Oracle to Postgres. The carrying out of the work approved in ADD282 was subject to the completion of the work in the DAR. Maintenance and support is now provided by Insight as approved in ADD2048.

1.4.    The Oracle to Postgres migration was part of a long-term database strategy within the GLA’s Technology Group to reduce annual maintenance costs and future licensing costs by moving all of the Mayor’s databases away from Oracle to this open-source alternative.

1.5.    During the discussions on development priorities with the representatives of the London Boroughs at both the LDD Management Team meetings and the LDD Annual Seminar, they have made it clear that they would benefit from an improved user interface, with features such as tabbed (rather than linear) access to data entry screens, key statistics being published on their home page and improvements to the data upload procedure being heavily requested. It has been noted that the current interface slows down data entry, and the presentation of the system may contribute to the lack of prominence this statutory task receives within the boroughs.

1.6.    Throughout the course of implementing these recent changes, GLA officers have held detailed discussions with the developer over the future of the system and it has become clear that the system is based on technology and programming techniques which are now out of date. This outdated structure is a considerable barrier to the continued maintenance and development of the system. Simple changes such as the addition of new data fields require a lot of development time, and major presentational changes are either too time consuming (and therefore expensive) or technically challenging to implement. The presentation changes requested by boroughs currently fall within this category.
 

Objectives and expected outcomes

2.1.    The objectives of the project are to 
2.1.1.    Improve the LDD database to accommodate additional data and connect to external systems e.g. Business Objects reporting tool and the SHLAA system
2.1.2.    Redesign the user interface of the LDD so the system is easier to navigate and provides a better ‘user experience’ for the staff in the London Boroughs who we rely on to provide the data
2.1.3.    Improve the data upload facility to allow the targeted upload of data to existing records is also a priority outcome which will aid the boroughs to speed up the inputting process, it will allow the GLA to add data held in other planning and housing systems directly to LDD, improving integration between systems, specifically the GLA’s SHLAA and PAWS systems.
 

Equality comments

3.1.    Active consultation with LDD users from within the boroughs will be carried out throughout the development process to ensure that the system is fully accessible to all of our users.

3.2.    No other significant equalities issues have been identified in relation to this project.
 

Other considerations

Risks

4.1.    The following risks associated with not carrying out this project have been identified:
•    It is not currently possible to link the fields recently added to the database to the Business Objects reporting system. Unless the database is restructured it will not be possible to monitor the provision of housing for older people or the additional data fields for office to residential prior approvals.
•    Unless the structure of the database is changed, it will not be possible to report on any new monitoring targets identified either during the course of the review of the London Plan or in response to changes in the planning system. The database will effectively be stuck in time, with no possibility of responding to changing requirements.
•    Without the required investment, it is possible that the system will eventually become totally incompatible with the reporting system which would make it impossible to produce the data for the statutory London Plan Annual Monitoring Report and which is required for the evidence base for the full review of the London Plan, which is currently underway.
•    Although the project is underpinned by a statutory requirement to monitor the London Plan and by the Information Scheme agreement between the Mayor and the 33 London Boroughs, it is essential for the smooth running of the project that Boroughs remain engaged. Borough users have clearly stated that they would benefit from an improved user interface. A perceived lack of investment in the project makes it more difficult to promote the project within the boroughs and ensure that they make sufficient resources available to carry out the work effectively in the face of competing demands.

4.2.    The following risks have been associated with carrying out the project
•    The Business Objects reporting system is mapped against the current structure of the database. Although an initial assessment has suggested that the re-mapping exercise can be carried out as part of the redevelopment project, it remains a risk that unexpected problems may occur and that additional cost may result from aligning the reporting system to a new database structure
•    Initial testing of a potential migration strategy has suggested that the current structure can be readily migrated to the new structure, allowing additional goals such as the improved user interface to be delivered as essential elements of the project. If the migration proves more challenging than anticipated, identified objectives may need to be put on hold to ensure the success of the project.
•    The LDD is a complex system with functionality that has been developed incrementally. Extensive testing will be required to ensure that the new system works correctly and in the same way as users expect
•    It is likely that further changes will be either facilitated or necessitated by these changes.
•    There may be an additional training requirement to familiarise borough users with the new system.

4.3.    As it is the GLA’s default reporting tool, the focus at this stage is on ensuring compatibility with Business Objects. However consideration will be given during the design process to whether any alternative options are available to extract data from the new system in a more cost effective manner.

Procurement and delivery management

4.4.    The procurement was carried out by TfL Procurement using the Solutions Framework.  Of the companies that responded, Proband was selected as the preferred supplier.

4.5.    The enhancements to the LDD will be managed by the Planning Team working closely with the Technology Group.
 

Financial comments

5.1    Approval is being sought for expenditure of up to £80,000 for Proband to redevelop the London Development Database (LDD).  The cost will span two financial years 2016-17 and 2017-18 respectively and will be funded from the London Plan Programme Budget.

 

Planned delivery approach and next steps

Activity

Timeline

Procurement of contract [for externally delivered projects]

N/A

Announcement [if applicable]

N/A

Delivery Start Date [for project proposals]

March 2017

Final evaluation start and finish (self):

Autumn 2017

Delivery End Date [for project proposals]

Winter 2017

Project Closure: [for project proposals]

December 2017