This work took place between August and October 2021.
Introduction to the work
Getting our heads into the post-advisory board (formally headteacher board) process has been quite different to the pre-advisory board.
With pre-advisory board we had the findings from the former private beta which really helped with our understanding of the process and what our uses needed.
With post-advisory board, and as a new team, we were starting from the beginning trying to understand the service, our users, and the business objectives.
The following posts highlights some of the main activity that has happened to try and understand this process.
Is this one service or two?
Firstly, we wanted to understand current process for post-advisory board.
We knew this would help with our understanding, however, we also wanted to assess any similarities between manage an academy transfer and the academy conversions.
We wanted to have a clear understanding of whether this needed to be two systems and therefore potentially two development teams, or one service with two journeys that a joint team may be able to deliver.
Process maps
Firstly, we mapped out the two post-advisory board processes, educating ourselves using existing artefacts and research.
Although each team took responsibility for their own diagram, and they did differ, it was still a great visual way to get a high-level understanding of the similarities of the processes.
The diagrams were then verified by our subject matter experts and consequently amended, in fact we are still adding details and making changes as we learn more.
Workshop
To get everyone thinking about how best we might move on with this work we participated in a joint workshop, the focus of the workshop was to:
- Review the combined journeys
- Identify high level user needs
- Review in detail the transfers and conversions processes
- Identify what is the same, similar and, different about the process
- We also discussed collaboration strategies and next steps
The workshop confirmed our hypothesis that the processes were similar enough to warrant a joint piece of work between the transfers and conversions teams.
Creating a swarm
At this point the two teams were still working on pre-AB and this needed to stay a priority, however, there was some resource available so, tasks were identified on post-AB which could be started in the form of a swarm, that is, resource that constantly report back to the main team or ’hive’ on the process of the work.
Gathering insights for delivery officers
The first work item identified for the swarm was sorting all the insights we had for delivery officers.
We had existing delivery officer needs for both transfers and conversions, however they were devised some time ago.
In addition, we had findings from a recent series of UR sessions with delivery officers, these findings had also further iterated our process diagrams.
Other factors that have caused us to iterate are, knowledge gained from attending RDD training sessions and findings from the cross-cutting diary study work.
In addition, we wanted to ensure any previous research carried out in this space wasn’t lost, so following an activity to read through all historical documents, we surfaced any needs or pain point to add to our collective evidence.
Themes and groups
Once we had collected all the needs, insights and pain points into Lucidspark, we grouped them into high-level themes and then further sorted related items.
Lucid spark screen shot of the themes created from the insights we collected.
How might we statements
From each of these groupings we were able to create a ‘how might we statement’.
The idea was to communicate the core problems to the team and to ensure as a team we focus on the problems rather than jumping straight into solutions.
We intend to hold sessions with different disciplines and users to help us brainstorm solutions for these statements, this should ensure we include a wide range of perspectives.
From these groupings, and having all the insights in one place, we were also able to create a more up-to-date set of user needs.
Example how might we statement
Stakeholder and business insights
Once our delivery officer user insights were in good shape, we moved on to start thinking about stakeholder and business needs.
It soon became evident we had a lot less knowledge and research for these groups.
We identified gaps in our knowledge and some areas where we thought there were huge opportunities to improve the service.
Our current hypothesis
Our findings current indicated several areas for further research:
RDD and ESFA teams have data requirements, however, there are currently inefficiencies in the process due to systems not talking to each other.
The process does not discourage files from being stored on local computers, compromising data.
Some data is currently not captured at the most suitable points for use by RDD and ESFA teams.
In addition we need to understand more about the expansion of the operational development team (ODT) and how it will effect what we already know.
We reported our findings to the main team, and a BA (Business Analyst) resource has been allocated to start this next piece of work, this will make up the next section of work (part-2).