A finished LGR baseline is already out of date

The LGR baseline should not be a one-off discovery activity. It is the current as-is across staff, systems, contracts, buildings and budgets, and it needs to stay live from decision day through vesting and beyond.

Every LGR programme has to establish the same thing: what each predecessor council currently has, how it operates and what needs to transfer into the new authority. That means consolidating staffing lists, systems, contracts, buildings, budgets and service information into one robust day one picture.

The work is essential. It underpins the blueprint, financial viability, disaggregation, TUPE, contract decisions and the plan for a safe and legal vesting day. The difficulty is that the baseline is usually assembled as a one-off exercise while the councils themselves continue to change.

The baseline is built in a moving organisation

Traditionally, programmes issue RFIs, spreadsheets and templates across every predecessor council. Service teams find data in local systems and documents, then return it using different formats, field names, terminology and structures. The data must be standardised, matched and reconciled before the programme can use it as one baseline.

On previous reorganisations, up to 200 people have been drawn into finding and validating the data. F3's lived experience is that roughly 85 per cent of early-stage capacity can be consumed by administrative process before a single transformative decision is made. This is not a failure of the programme team. It is the structural reality of creating one picture from organisations that were never designed to report as one.

While that work is under way, people join and leave. Contracts renew. Monthly revenue forecasts move. Structures change. A return that was correct when it left a service may be wrong by the time the full baseline is signed off. The result is a snapshot in time, not a current picture of the as-is.

The consequence is felt in the decisions

A stale baseline is not simply an information problem. It changes what the programme can decide, and when.

SROs and service directors need current evidence to agree the blueprint. The Section 151 officer needs a credible day one budget and the ability to test viability. Disaggregation decisions need a method, a driver, a data source and an audit trail. The programme also needs to see where policies, performance or contracts differ, which are tension points to resolve and which create opportunities to harmonise or consolidate.

When the evidence is not current, decisions are delayed, caveated or reopened. On a fixed route to vesting day, that lost time has to come from somewhere. Historically it comes from transformation. Existing structures, systems and contracts are carried across to reach safe and legal, and the new council begins the baseline and transformation exercise again after vesting. That is how a two to three year delay becomes built into the programme.

The Workbench does the wrangling, so the baseline can stay current

The SMART: LGR Command Workbench does not wait for the baseline to be assembled before it becomes useful. It ingests the material councils already hold, including system exports, completed RFIs, spreadsheets and documents such as contracts, then automatically identifies the required data and maps it into a single defined LGR schema.

That schema does the equivalisation work across predecessor councils. Different field names, terminology, table layouts and document structures become comparable records across staff, systems, contracts, buildings, budgets and services. The original source remains attached to each record, so the evidence and audit trail are not lost in the consolidation.

The Workbench also deals with the repeat work that follows. It identifies potential duplicates and, when refreshed information is supplied, compares it with what is already held. Unchanged records are left alone, new records are added, leavers or closed items can be removed, and records that may need updating are highlighted, for example where a member of staff's role or salary has changed.

Instead of analysts and service teams spending their time standardising formats, matching records and rebuilding trackers, they can focus on validating exceptions, resolving tension points, testing options and making decisions. The same structured evidence can feed the day one blueprint, financial viability, disaggregation, scenario modelling, the opportunity pipeline and decision papers without being re-keyed.

That efficiency changes what is practical. Instead of running a limited number of baseline updates, the programme can refresh the same structured baseline throughout delivery. New returns and documents are compared with what is already held, so the current as-is across staff, systems, contracts, buildings and budgets is maintained from decision day through vesting, rather than reconstructed as another point-in-time snapshot.

The central benefit is that decisions about the day one blueprint, financial viability, disaggregation, TUPE, harmonisation and transformation can be made against current evidence, not data that went stale while it was being reconciled. The same current baseline, blueprint, assumptions, decisions and opportunities can then carry into each new unitary, avoiding a vesting day restart and giving the new leadership a stronger platform for transformation.

Book a SMART:LGR Command Workbench overview. The session walks through how automated ingestion, schema mapping, deduplication and change detection make it practical to keep the baseline current throughout the programme, strengthening decisions and bringing transformation forward.

---