MD2007 Housing & Land IT System Replacement

Type of decision: 
Mayoral decision
Code: 
MD2007
Date signed: 
11 July 2016
Decision by: 
Sadiq Khan, Mayor of London

Executive summary

The GLA’s Housing & Land Directorate has a number of business critical IT systems.  These systems support key functions including managing housing grant allocations, monitoring land developments and reporting on outcomes. The systems are over 15 years old and no longer meet business needs.  One of the key systems is also due to be turned off by the Homes & Communities Agency in June 2017, so a replacement has to be found.

In May 2015, approval in principle was given for expenditure of £1.55m to procure a supplier to design and implement a bespoke IT solution. It was agreed Mayoral approval would be sought once the procurement was underway when actual costs would be known. 

Following approval in principle, procurement documentation was prepared and the contracting opportunity was put out to tender, however only one proposal was received. It was decided it was not possible to assess value for money from this one tender.  It was therefore agreed that a new procurement should be undertaken.  

Following internal reassessment and the updating of the specification due to external environment changes, the GLA again went to procurement in April 2016. Tenders have been received and evaluated. The GLA is now able to make a recommendation for contract award in accordance with the tender requirements. The £2.5m expenditure proposed here is in addition to the expenditure approved through MD1665 of £552k for internal staff to project manage, specify, test and sign off on each sprint (a sprint breaks the project down into small parts of functionality and continuously delivers them) once the developer is in place in late spring 2016.
 

Decision

a)    Expenditure of up to £2.5m capital resources to deliver the project; and 

b)    The award of contract to Keytree Limited for the systems replacement project.
 

Part 1: Non-confidential facts and advice

Introduction and background

1.1    The GLA’s Housing & Land Directorate (H&L) has acquired or inherited a number of project, programme and land management IT systems.  These systems provide business critical allocation, management, monitoring and reporting of all the GLA’s investment in housing and all land developments.  They manage over £460m annually. The systems are vital for the GLA to carry out its duties, and to bring investment partners, local authorities and the Mayor together to deliver homes and regeneration.

1.2    There are currently five main systems in place, four of which are owned and maintained by the Homes & Communities Agency (HCA) with secure and segregated access granted to the GLA via remote access. The 5 systems are as follows: 

•    Investment Management System (IMS), including an interface to the GLA’s financial system (SAP) (owned by the HCA)
•    Project Control System (PCS), including an interface to the GLA’s financial system (SAP) (owned by the HCA)
•    Business Objects (owned by the HCA)
•    Compliance Audit (owned by the HCA)
•    QUBE (owned by QUBE Global Software)

1.3    All systems are currently in use by H&L staff with IMS also accessible to around 200 investment partners.   Partners repeatedly complain about the experience of operating IMS, and the inefficiencies and problems with the system.

1.4    Whilst all the systems provide vital functionality in a very specialised area, they have developed independently of each other as the result of outside bodies being brought into the GLA each with their own IT system. 

1.5    Notice has been given by the HCA that the provision of the PCS system to the GLA will cease as of 31 June 2017.   No deadline has been set for shutdown of the IMS system but the GLA envisages that a replacement to the IMS system will be required within the next 2-4 years as HCA and GLA requirements continue to diverge.   The HCA are expecting the GLA to discontinue their use of this system by March 2018.

1.6    In addition, the IMS system is over 15 years old, and has been developed in a piecemeal way.   This means the system is no longer fit for purpose, and a number of time consuming and costly work arounds are needed to maintain day to day delivery of the affordable housing programme, particularly in terms of reporting and monitoring. The current system does not include details of risk management for schemes approved by the Mayor nor does it enable effective forecasting at a programme or team level. Changes required to the system for the GLA’s needs are generally expensive and low in terms of priority for the HCA, so can take months to implement.

1.7    H&L therefore have a pressing need for new systems to replace current systems which are either being switched off, are no longer supported, are inefficient or are poor value for money.   

1.8    There is also an opportunity to deliver additional value across the organisation, as the replacement systems could be used by other teams to support project delivery.  As such, the processes of the regeneration team have also been brought into scope.   

1.9    The specification has also been designed so that bringing in additional parts of the GLA or wider GLA group will be relatively simple, although this may require approval for additional expenditure and funding, depending on the exact specifications.  

1.10    In particular the specification has been designed so that the system will be able to support monitoring reports on housing and land delivery across the GLA Group without large scale changes.

User requirements and scope - background

1.11    An original business requirements specification on system replacement options for H&L was carried out by specialist consultants who recommended that a single, bespoke web-based system is procured and delivered to replace the existing systems.  

1.12    The original spend for this was estimated at £1,555,200. Only part of the system however was scoped in detail.  This was the replacement for the PCS land project management system.   As such there was no certainty on the proposed expenditure required for the full solution, which needed to be tested via procurement.    IPB agreed expenditure in principle, but agreed final sign off would be sought once the procurement had taken place.

1.13    Following the unsuccessful procurement, there was considerable change in the housing and land external environment.  This included the introduction of housing association right to buy, the 1% rent decrease, starter homes, housing zones and the London Land Commission.   It was agreed by the programme board (see section 1.19 below) that the user requirements which had been specified in 2015 were no longer up to date.  The project would therefore be at risk of either expensive change requests or delivering a product which was not fit for purpose. 

1.14    In order to minimise this risk, it was agreed that a process mapping exercise would be carried out to assess the recent changes.   This exercise highlighted that there was enough certainty to map user requirements, as long as there could be a flexible approach to the solution development.  It also highlighted opportunities to bring in additional functionality, such as including the Regeneration Directorate functions.

1.15    As such, the project board agreed to re-tender following a different approach – the “Agile” approach.   Agile is the GLA’s mandated delivery method for software development. The Agile development standard adopted by the GLA is in direct response to cost and time to deliver issues associated with other traditional software development methods. 

1.16    Agile is an iterative approach to software delivery that builds software incrementally from the start of the project, instead of trying to deliver it all at once near the end. This means that there will be working software to test and use within 4 weeks of the project starting.

1.17    Agile works by breaking projects down into small parts of functionality called user stories, prioritising them, and then continuously delivering them in short cycles called iterations or sprints.    It priorities the user stories which provide the most business value, and through a process of continuous planning and feedback, ensures value is maximised throughout the development process.

1.18    H&L and the Regeneration Unit carried out a process of defining the user stories which was the basis of the procurement specification.  This involved significant input from internal and external users.

1.19    A monthly Programme Board has been set up for the project and chaired by the Head of Area – South Team. This board includes H&L Senior Managers and representatives from Regeneration, Governance, Finance, TG Services and Digital Services. 

1.20    The systems replacement project will be run by a core team of GLA officers, the Delivery Team, who have been trained in Agile, and provide subject matter and technical expertise as required. MD1665 approved the backfilling of specific posts (subject to Mayoral approval to enter into contract with the preferred development supplier) to allow the Delivery Team to work with the supplier to project manage, specify, test and sign off on each sprint.

2    Procurement Process and Preferred Suppliers

Please see paragraphs 2.1 – 2.14 in the part 2 confidential annex for details of the procurement evaluation and assessment of the tenders received.
 

Objectives and expected outcomes

3.1    The objective for the IT project is to: design, build & implement a single, user friendly, web based system to manage the core processes for Housing & Land and Regeneration.

Suppliers will need to deliver key must haves:
•    A secure system, with clear audit trail for approval of spend
•    Integration (in some way) with SAP for GLA finance systems
•    An improved, more efficient process
•    An intuitive, easy to use interface
•    Flexible and customisable reporting supporting the Housing and Land Single programme  Office as well as corporate reports on performance as well as requests from the Mayor’s Office
•    Ability to upload data from other sources not manually input
•    Use open source development to minimise future costs

3.2    The project will bring a number of business benefits, both strategic and operational.  Some of the strategic benefits are:
•    A system which will be flexible and customisable, and therefore able to integrate monitoring and reporting across the GLA Group relatively easily.     This means housing and land delivery and outputs can be better managed across the group, with issues identified and managed early.
•    “One version of the truth”, which will enable better and more robust reporting on key outputs such as homes delivered, broken down by programme, land owner, boroughs etc.
•    More streamlined processes and integration across H&L and regeneration.
•    Ability to add in other grant payment processes across the GLA, if deemed of business value.

3.3    In terms of operational benefits, the project team is currently baselining these in order to track time and money saved during and after implementation.   The key benefits are envisaged to be:

Benefit Profile

Type of benefit

  1.  Accurate data, one version of the truth

Non – cashable – better and more accurate decision making

Cashable – time saved on reporting and using offline workarounds

  1. Easy to use & improved efficiency through business-led design

Cashable – time saved on non-value added tasks, including unnecessary process steps

  1. Improved, auditable decision making, supported by evidence

 

Non-cashable – better decision making and clearer rationale for investment decisions

  1. Reduced maintenance overhead, greater control & performance

Cashable – reduction in time spent raising change requests and testing HCA changes (currently estimated at 3 FTEs)

Non-cashable – improved control and speed of driving improvements or added functionality

 

Equality comments

4.1    The public sector equality duty requires the identification and evaluation of the likely potential impacts, both positive and negative, of the decision on those with protected characteristics (age, disability, gender reassignment, pregnancy and maternity, race, gender, religion or belief, sexual orientation).

4.2    The Authority’s equality duty has been taken into account when procuring the supplier. 

4.3    The new system will allow us to monitor compliance with design standards, which take into account the need of accessibility for all, including persons with a disability and those with any other protected characteristic. 
 

Other considerations

Key risks and issues

The Delivery team has been monitoring risks and issues throughout the project, and these are highlighted in daily meetings for quick resolution.

The key risks for the project are detailed below.

Risk Description

Mitigation Actions

The scope of what is required to deliver value to the GLA – the Minimum Viable Product – has been significantly under estimated in the tender response.  As a result, the development cost and/or the time taken to release an MVP could increase

  1. Agile methodology will be properly applied to ensure that the MVP elements are prioritised and complexity is kept to a minimum.
  2. The minimum viable product has been carefully scoped in advance with key users, and an expert business analyst has assessed the tenders and believes them to be appropriate.

Changes in scope lead to the minimum viable product not being delivered in time or in budget

  1. Scope decisions will be flagged and addressed early on in the process to avoid any delivery surprises further down the line, using the dedicated GLA delivery team. The team will monitor progress, scope and complexity to keep the project on track.  A working prototype will be produced at the end of the Alpha Phase (Sept 16) allowing a full complexity assessment. Regular information on spend and spending forecast will be provided to Finance.

To respond to changes in the environment the system must be fully configurable and responsive; suitable for use across the GLA Group and able to support changing policies.

  1. To mitigate this risk, the GLA have clearly defined this as a core requirement.
  2. To ensure that this element isn’t overlooked key configurability features have been prioritised by the Product Owner and will be one of the first features developed.

 

Financial comments

6.1    The estimated cost of £2.5m is a capital expenditure, which will be met from the Mayor’s Housing Covenant 2015-18 programme budget. This cost is in addition to the £552k for internal staff approved by MD1665. (revenue funded from Recycled Capital Grant Fund interests)

6.2    A separate approval will be sought for the ongoing revenue maintenance costs for the system once these have been clarified with the supplier.  These costs will be met from the existing Housing and Land Budget.

6.3    Keytree are part of TfL’s Solution Framework. As part of being appointed to this framework TfL carried out financial due diligence to assess financial standing of this company, which they have passed and were assessed as sound.
 

Investment and Performance Board

This MD was not considered at IPB given the need to quickly get into contract to meet delivery dates. The next IPB meeting would have entailed a wait of 7 weeks.  IPB have previously considered and approved the project in principle in May 2015 and were updated in January 2016, as noted above.

 

Planned delivery approach and next steps

The next steps are summarised below:

Activity

Timeline

MD Approval

June 16

Contracting with preferred supplier and project start

July 16

Discovery phase and Alpha phase

mid-Sep-16  

Beta 1 phase

01-Apr-17

Minimum viable product

01-Apr-17

Data Migration

30-Apr-17

Beta 2 phase (full system delivery – long stop date, although delivery expected to be earlier)

31-Mar-18