Contents

Governance

ILR governance aims to preserve data integrity and to simplify compiling and submitting learner data.

Overview

The ESFA own the data specification, schema and associated tools designed to ensure only quality data is accepted into the systems.

The specification schema identifies precisely what data is to be submitted for each year running from 1 August to 31 July (plus 2 months for corrections).

The schema is applied to systems in educational institutions in the FE and Skills Sector which receive funding provision by contract, and it governs the submission of the data to the ESFA.

Data set integrity and rules

Data that is collected must conform to a defined set of rules to maintain the quality of the dataset.

For instance the data collected:

• cannot be for rolling monthly data or for short duration

• should not be onerous or costly for data providers

• should be easy to source and therefore cost effective

• must align to the defined purpose of the ILR dataset

• must be supported by an approved business case

• must be measurable

• must be operationally acceptable

The parties involved

The ILR dataset is managed by the Data Specification team within the ESFA

The FE Data Collections Board

As the highest level group within this user community structure, the board is responsible for guiding its collective understanding and actions.

The FE Data Collections Board is made up of internal stakeholders with a vested interest in ensuring the high quality of the dataset and with a sound understanding of what it can and cannot do.

The DfE Data Governance Board

The DfE Data Governance Board delegates responsibility for the governance of change management of the ILR to the FE Data Collections Board.

Technical User Group (TUG)

The data provider community is represented on the FE Data Collections
Board through the membership of TUG.

The Board considers the operational and technical activities and guides the actions of the ILR Analysis Team, taking responsibility for ensuring that there is a clear calendar of data submissions and a clear annual schedule of activities, driven by milestones related to change management and communications.

Change management

The FE Data Collections Board guide the Data Specification team within the ESFA to manage change to the ILR dataset.

Change proposals, analysis and decision-making

When a change to the schema is proposed the ILR Governance processes ensure that the benefits, reasons and impacts are investigated and made clear so that an informed decision can be made on whether or not to proceed with proposed changes.

Where there is a change to policy, existing fields may no longer be relevant. The ILR Governance provides the structure to investigate and confirm that no dependencies exist, and to ensure redundant fields are removed in a controlled manner so that their removal does not cause submission issues or technical difficulties.

Proposals for change, pass through a process of analysis leading to a clear recommendation which is presented to the Data Collections Board .

Appealing a decision

The FE Data Collections Board decide if a proposed change should be addressed or not.

If the Board reject the proposal and the a change sponsor disagrees, they can appeal the decision to by addressing the points of concern. If the appeal is rejected again, the change sponsor has the option to put forward the proposal and analysis to the DfE Data Governance Board who make the final decision.

Approved proposals and risk rating

Where risk analysis shows:

• Amber RAG rating, the proposal must be tracked on the appropriate Risks, Assumptions, Issues and Dependencies (RAID) log and reviewed after 6 months’ data

• RED RAG rating, explicit agreement of the Chair of the deciding Board is required.

Impartiality and decision making

Members of the FE Data Collections Board are key stakeholders in the ILR collection. When they or their teams propose changes to it they must withdraw from the decision making process on that specific proposal.

Timeline

The ILR year runs from 1 August to 31 July.
Change proposals must be received by 31 July to be applied for 1 August the following year.

1. Consultations are held in August and September with ESFA teams (to understand business activity, calculations, and all details), software suppliers (to ensure best solution) and with data providers (to understand, reduce and plan around impact).
   

2. Analysis is conducted through the 3 gates:

   1. Compliance: to ensure the proposal is acceptable to the business and can meet the business objectives

   2. Solution: to ensure all parties are agreed on the best solution and what this will mean for software and processes

   3. Impact: considering the solution to establish the impact across all parties (data providers are involved in this exercise)
      

3. The analysis results in a quantified acceptability rating for each gate which contributes to the recommendation from the ILR specification team to the FE Data collections Board

4. A decision is made in October with appeals where relevant following on swiftly. The final decision is confirmed in December with communications released to the data provider network

5. The revised specification for the coming year is released in January

6. Development starts in January and software suppliers are involved in this work

7. The software is released at the end of July

Mitigating costs

Change to the dataset puts a considerable load on the data provider. Any change made to the ILR schema which requires the data provider to change their data collection routines or software will impact their overheads, and as a result, impact the services they can provide to the learners.

This is the reason why all changes which are approved pass through a rigorous change management process, and involve input from the data provider community in the analysis and decision-making phase. All decisions and reasons for the changes are published.

Administering complex and basic changes

Changes which don’t require a structural change can be addressed outside the formal change window as an in-year change (eg. Additional codes).

Change proposals that do require structural change must be tabled by the start of the formal change window (30 June) for analysis and consideration through the change management process. If approved, the changes would be implemented for the start of the next full submission year.