The problem
Providers often find it difficult to understand how their funding stream statements have been calculated. Currently, those who receive adult funding wait around 2 weeks after receiving their allocation statement to receive calculator tools provided by the DfE. These tools break down the calculation methodology so that providers can understand how we arrived at the funding line values in their statement. Providers receive them separately to the statement via GOV.UK or Doc Exchange, and in different formats (spreadsheet and PDF), as opposed to the digital statement on manage your education and skills funding (MYESF).
Funding Operations colleagues are under pressure to produce these tools - some of which are bespoke to each provider - which involves significant time and manual effort.
This calculation functionality will also ‘unlock’ our data driven pattern to streams outside of our adult funding pilot group - as some existing statements already include calculation information.
Hypothesis and a proof of concept approach
We needed to understand whether it was possible to provide calculation information in our data-driven pattern. We decided to investigate a technical proof of concept based on a hypothesis:
“We believe that calculations can be data-driven, saving internal efforts and resources. In turn, this will allow additional, more complex funding statements to use our data-driven pattern.”
Reviewing existing material
We gathered and reviewed past user research, funding service user personas and calculation user needs validated during discovery and alpha phases. We also reviewed the calculator tools provided for adult funding, as well as common helpdesk enquiries around allocation statements.
Developing early design concepts
To help shape our thinking, we worked on some early, high-level design concepts. These initial designs were shaped by the following challenges:
- How might we show calculations with their associated funding lines?
- How might we support the user need hierarchy to see totals first, then funding line details and calculations when needed?
- How might we give users access to the calculation data?
We then explored options using a variety of GDS components to ensure consistency and accessibility.
Analysing the data available and identifying technical options
Working alongside the technical team and our business analyst, we mapped existing calculation data held within internal databases to better understand its relationships and structure, followed by a data gap analysis. This allowed us to identify the key data requirements for our proof of concept and for the tech team to begin investigating how we might pull key calculation information through to the pattern.
The conclusion, and dividing up the challenge
To help us align internally, and break down the challenge, we made the distinction between calculation factors and calculation operations.
A calculation factor is a key component of a calculation such as student numbers, funding totals or rates applied. We discovered that some factors appear to be universal across funding streams, and some are unique.
A calculation operation is a mathematical process applied to a factor such as addition, subtraction, multiplication and division.
We were able to prove that the data for calculation factors is more readily available, and possible to pull into the data-driven pattern. However, more technical investigation is needed into how to deliver calculation operations. This is because the current data structures mean that the operations data is not readily available in a format that our tech solution can access and therefore is more difficult to pull into the pattern in a data-driven, user-friendly way.
Next steps
Due to the technical, data and timeline constraints, we decided to concentrate our efforts on delivering calculation factors as a statement feature in the next phase of work, using this as a foundation to deliver calculation operations in the following phase.
The first task would be to validate a set of assumptions from our early-stage design work with providers:
- Users are not interested in all calculation factors
- Most user roles might be interested in calculation factors, but they do not need to dig into them unless their allocation does not match their forecast
- Users will want to download or export calculation factor data for their own processes
- Users typically investigate calculations when conducting long term forecasting and budgeting, or when their allocation does not match their forecast
- Users find calculation factors most useful when presented in an order that they are familiar with
- Showing calculation factors under the funding line they relate to will help users understand their allocation
- Certain funding stream statements can be understood with only the calculation factors, others will need calculation factors and operations to be understood
Once we validated these assumptions, we would have a better understanding of how we can add value to provider experiences by showing them calculation information within their statement.