Data consumers
We have 2 groups of users. The first group is made up of the people who manage a conversion or transfer project - the caseworkers and delivery officers.
We also have a group we refer to in the team as data consumers.
These are the people who work in funding and administration teams.
They use the data that caseworkers and delivery officers enter into Prepare and Complete for many things, including to:
- update school, academy and trust records
- check and audit information
- prepare and send funding
It is vital they get the right information at the right time. Inaccuracies can result in delays to funding.
Exporting data
At the moment, these users are able to access data through reports in KIM (Knowledge and Information Management).
We have done research with these users to try to understand what they actually need, and what data they get in these reports but do not use.
We have tried to provide this data in CSV files that the user can download from Complete conversions, transfers and changes.
In some cases, these exports are expanded and more detailed versions of the tables that caseworkers and delivery officers can see, such as the By Month tables.
Elsewhere, we have designed a part of the product that only these users can access. Here they can download data about conversion and transfers.
These exports are not available to caseworkers or delivery officers as they do not need to use them in their jobs.
Bespoke reports for each team
As we began talking to data consumers, we found that often they did not need all the information they got in the KIM reports. We also learnt that the teams often needed different datapoints to other teams.
So we decided to create bespoke reports for each team. This would help to reduce the time and effort it took for them to filter down the reports and find the data they really needed.
We wanted to give the user just the information they need and removed all the extra data that was not relevant to them.
Learning from a data trial
We ran a data trial with the data consumers to test that the reports would provide the information they needed before delivery officers and caseworkers transitioned away from KIM.
We provided dummy data and got feedback about the reports from the data consumers.
Language changes
The trial showed us where users we unclear on what some column headings and data in the CSV files meant, so we changed those to something more meaningful to users.
This was particularly helpful where we used terminology to describe if the academy was going to form a new MAT (multi-academy trust) or join one that already exists.
Instead of saying that a conversion was a "single converter" or "forming a MAT" we will soon say that the project is either "joiing a MAT" or "forming a MAT".
Missing data
Through the trial we also learnt that in some instances our bespoke reports were missing some information that a particular user group needed. This was most often the case with contact details for various people at schools, academies and trusts.
While we might have some of the contacts a team needed in one export, other contact details they needed were missing. That information was often available in other exports instead.
While that information existed and it was possible to access it, its location made the task of finding and using it harder for the teams that needed it.
Reducing the number of reports
The more we spoke to data consumers and got their feedback, the more we learnt the datasets were not as distinct for each team as we originally thought.
In fact, it soon became clear that most of the teams needed very similar and overlapping information.
Taking the approach to have separate and distinct exports meant that some funding teams would need to download and filter more than one export to get what they needed. Trying to reduce the mental load for these users in one way, actually increased in it another.
As we have progressed through the trial, we're learnt that in many cases it's actually easier for data consumers to download all the information available in one CSV file and then filter it down to what they need.
This has a couple of benefits for them:
Firstly, they have less files to download and look through. Secondly, they're already familiar with datasets and confident in interrogating and manipulating them to find what they need.
Because of this, we've merged some of the exports to reduce the burden on data consumers who use them.
Future iterations of the exports
We'll continue to get feedback from users about how they use the exports.
We suspect we may end up at a point where all the information in Complete is simply exported in one file and data consumers filter through that.
But we will see where the feedback and research takes it.
Providing data to secondary users in Prepare
We've also done work to give data consumers the information they need in Prepare conversions and transfers.
There used to be 2 different teams, each working on Prepare and Complete. We are now one team of people working on both those products.
Those 2 teams tried to work together and share thoughts and findings, but ultimately they did end up working in a bit of a siloed way. Because of this there are some significant differences in the way they 2 things look and function.
Because of this, how we get data from Prepare to the data consumers who need it is slightly different to how we do it in Complete.
Merging data from Prepare and Complete
Long term, we want to enable Prepare to pass information about a project to Complete automatically.
This would remove the need for delivery officers and caseworkers to add projects to Complete themselves.
That would save them time and reduce the amount and chance of errors introduced to Complete through human data entry.
If we can pass information about projects from one application to the other, we should be able to provide a single place for data consumers to access and download data. This would stop them having to export data from Prepare and Complete separately.
This is a large piece of work, but there are many benefits to doing it for all our user groups and the department. The team hope to prioritise this and begin work on it in the near future.