1. Delivering Data Futures at Edinburgh – Project Structure
Project Board
Manages risks and resources
Prioritises tasks for delivery
Makes decisions re. policy changes / escalation as appropriate
Working Group
Oversees work of task and finish groups
Recommends actions to the Project Board
Task & Finish Group
Systems Analysis
Systems Development
Ensuring that Edinburgh is able to meet Data Futures requirements presents challenges in terms of systems development and in terms of policy and adapting existing ways of working. The project has different streams that reflect this:
Systems analysis and systems development will identify and implement the necessary changes to the Student Records System (SITS) and assess the impact on other systems
Business process / policy changes will be addressed by Task and Finish Groups that are co-ordinated by the Working Group. In the first phase these are addressing known issues that do not require systems development
As the project progresses these work streams will inform each other
Investigate specific issues e.g. managing PhD Supervision records

2. Additional analysis / development
Process reviews
Additional analysis / development
Initial analysis
System development
HESA 18/19 (old)
HESA 19/20 (Data Futures)
Ref. 1
Ref. 2
Ref. 3
Mandatory test
In Year Data Futures
Data Futures Delivery

3. In-year Returns: Continuous data supply and correction
Current process
Data returned for full Academic Year (Aug – Jul)
Data quality checking period and sign off (Aug – Oct)
In-year Returns: Continuous data supply and correction A S O N D J F M A M J J A S
Reference period 1
Reference period 2
End of Reference period
Sign off period
Data sent to statutory customers
Reference period 3
Data Futures creates a continuous database for the student record. Data are updated within each reference period to show where there have been changes e.g. adding new students, changes to programme of study or course choices. Records are timestamped so the date from which a change took place are included in the database. There is not a long data quality checking period and data will be shared with statutory customers at the end of each reference period.
Once data has been signed off it is fixed. Changes to historic data will be treated in a similar way to ‘Fixed Database Return’ in the current system i.e. changes will need to be approved by the funding council and institutions will need to pay a fee (currently £7,000). This means that the Student Records System will need to be kept up to date in as close to real time as possible e.g. should a PhD student move to writing up at the end of November this will need to be captured and returned before the end of the reference period.