Q&A On “Introducing E‑Submissions of Theses”
Susanna Broom, an Assistant Registrar at the University of York, was one of the contributors to a recent Graduate School Managers’ Network meeting which focussed on change management. In this Deep Dive Q&A we catch up with Susanna about her contribution to that event, and her views on how to implement change effectively, having just introduced an e‑submission system for PGR theses at York.
Could you describe a bit about the PGR population at the University of York and what had been the status quo for dealing with PGR thesis submissions for examination?
York has a ‘rolling’ population of 2,200–2,300 PGRs. Around a third of that population is in the continuation period (‘writing up’) or post-submission at any given time. Just under half of PGRs are from outside the UK: 13% EU and 35% non-EU. The ratio of full- to part-time students is around 9:1.
Until September 2019, students were required to submit at least two soft-bound copies of their thesis for examination (more copies where there were more examiners). Submissions (500+ per year) were and continue to be handled by a central team: Research Student Administration (RSA).
PGR support at York is split between academic departments (27 in total), which provide ‘first-line’ support, and central professional support teams, including RSA, which provide institution-wide support and/or oversight in various specialist areas. York’s Graduate Research School is a ‘virtual’ school, headed by a Dean. It provides the governance structures for, and strategic oversight of, the PGR student journey at the institutional level.
Could you explain what led to the proposal to make it possible to submit your thesis electronically for examination at the University of York? What were the key drivers?
It was a combination of factors. First and foremost was a desire to improve the student experience. We were already aware that the process was both financially and administratively burdensome for students, and then a report from the Graduate Students Association (we have a separate union for PGs at York), which highlighted and challenged the burden of printing costs on students, brought that to the fore, generating some momentum for change.
The second key driver was a need to streamline processes within RSA in order to ensure effective and grade-appropriate use of staffing resource in that team; we calculated that the submission process was generating in excess of 50,000 administrative ‘touches’ for the team each year. In turn, it was anticipated that making the process more efficient would lead to an improvement in the service provided to all of the team’s stakeholders, with the capacity gained allowing the team to be more proactive rather than reactive. The environmental benefits of e‑submission were also a driver.
Was e‑submission part of a wider change in the handling of PhD assessment at York?
Yes — we reviewed the PGR examination process from submission through to examination outcome and implemented several changes. In addition to e‑submission of theses, we scoped, developed, and implemented:
- Online forms and an e‑workflow for all the documentation associated with the examinations process, from the student’s ‘Notification of Intention to Submit’, to the post-viva reports;
- Revised correspondence for all steps of the examination process, ensuring that recipients were receiving the right information at the right time, and reducing content to the essentials for the relevant stage of the process;
- The transfer of responsibility for the (minor) corrections process to RSA, in order to standardise the submission process for students at all stages of the examination process, and improve QA in this area;
- A change to the method of recording vivas (we record all) so recordings are captured in the cloud, reducing the number of administrative ‘touches’.
In your talk, you described a technique you used called “Rapid Improvement Events”. What is that?
That’s right — it’s a technique based on Lean methodologies which York is utilising for a wide range of process reviews. We have a pool of trained facilitators, and the methodology is advocated by the University’s senior management, which is important when it comes to drawing on resource across directorates to implement changes.
The idea of RIEs is (with the help of trained facilitators) to apply proven Lean principles and tools to review a process in an intense period (usually 1–5 days — the ‘event’ — depending on the scale of the process being reviewed). The focus is on reducing complexity, working beyond internal boundaries (teams, departments, etc), and encouraging key staff and stakeholders to identify and own process improvements. The event itself is sandwiched between a period of planning and build-up (getting the right people in the room, identifying and gathering relevant data and resources, etc) and a post-event period of development and implementation, working to deliver the solutions generated by the event. Although intense and resource-heavy (both time- and personnel-wise), RIEs are a great way to generate momentum for change, while including stakeholders in generating solutions ensures that changes are appropriate and meaningful.
For our RIE, we had two facilitators, representatives from RSA, academic departments, and the GSA, and some ‘lay’ participants (who were very useful in challenging us on why we did things the way we did). Our event was three days. We spent the first day reviewing the examination process in detail, identifying the initial state and the ideal state we were aiming for. On the second day we started to apply Lean tools: identifying wasteful and value-adding steps, mapping flow and touch times, and conducting root cause analyses. Next, we started to generate solutions — with no holds barred — before using a ‘speed-dating’ exercise to sell the benefits of the ideas to one another to whittle down the pool of ideas. The third day started with us conducting a ‘PICK’ analysis, and then starting to pursue the solutions which fell under ‘implement’. By the end of the day, we had tested some of our solutions and developed a high-level plan for what we wanted to implement and how and the timeframe.
We held the event in June, and we wanted to have all the process changes in place for the main thesis hand-in at the end of September. The reasons for this were two-fold: we wanted to improve the process as quickly as possible for the students, and the autumn term is extremely busy for RSA, and so we didn’t want to lose momentum once the new academic year started. So, in the space of four months, we scoped, designed, piloted, and delivered e‑submission, alongside the other process improvements and alterations mentioned above. I wouldn’t have believed that was possible had I been asked before the RIE, and I believe it was made possible by a combination of the RIE methodology creating the necessary momentum, and the commitment of RSA and others to deliver within the challenging timeframe we set ourselves.
Were there any concerns about introducing e‑submission?
Certainly. We were fairly confident that students would be supportive, and that has proven to be the case: direct feedback (via a post-submission survey) has been overwhelmingly positive. In addition, we have observed that students are submitting at all times of day and night in the lead up to their deadline, suggesting that they are fully-utilising the additional flexibility the e‑submission affords them (no more lead times for printing or submission restricted to office hours, etc). Our primary concern was around the reaction of departments and examiners. We were aware that e‑submission would be, at least in some people’s eyes, a controversial move, while there might also be disciplinary- and even project-level differences which made an e‑submission more or less appealing. However, given the focus was on student welfare and experience, we felt these concerns shouldn’t stand in the way of implementing a process which would ultimately benefit students.
What have been the major implementation challenges so far?
Pre-roll-out, the challenges were around finding time to push through the changes and maintain the momentum generated by the RIE. Motivating an already busy team to take on more work is difficult. I tackled this by assigning key workstreams to each manager to run with, giving them ownership over a particular change, and then having weekly ‘huddles’ where we reviewed progress and kept each other honest.
At the point of full roll-out (around two weeks before our major hand-in at the end of September), a certain level of responsiveness and ‘thinking on our feet’ was required as scenarios we couldn’t have foreseen presented themselves. We were prepared that this would happen (in the timeframe we had, we were not going to be able to test every scenario; indeed, I’m not sure that’s possible in any event), but it can cause stress at the time, both for the students and the staff supporting them. The key thing was reassuring students that they would not be disadvantaged, and recognising that we would need to exert a degree of pragmatism.
Now that the process has been in place for three months (with c. 200 successful submissions to date), the primary challenge is around examiners. As expected, there is a degree of kick-back, and we are getting a number of requests for hard copy theses from external examiners (c. 25%; printing for internal examiners is being handled by academic departments), but this was expected. When we decided to print for external examiners on request, we took the view that requests were likely to reduce overtime, as more and more institutions move to e‑submissions for examination (which, from our networks, looked to be the direction of travel), and reading a thesis on an electronic device becomes the norm.
What advice would you give to someone who is having to manage a significant change in the provision of postgraduate education?
As clichéd as it sounds, communication is absolutely vital, both with stakeholders when communicating the change, and within the project team, ensuring that everyone is on the same page. Establish a communications plan at the outset of the development stage (not later — give people time to adjust to the idea) and stick to it. For example, we produced bi-weekly progress newsletters for academic departments and other key stakeholders, and then sent out more formal memos via the Graduate Research School, signed off by senior leads, at key stages.
Expect and prepare for kick-back. There is no change process which is going to be greeted with open arms by all stakeholders. This can be demoralising, particularly where a lot of energy and time has been invested in making a change as smooth as possible. So, it’s important to remember why you’re doing it; reinforce this regularly, both with the project team and with stakeholders. Also, consider that any sort of change can be challenging for some people — you may be able to see the benefits in all their Technicolor glory, but it may not be so obvious to those outside the immediate team — and so an understanding approach is important. In short, be prepared to roll with the punches for a while!
Get your senior stakeholders on board from the start — they will be key when the kick-back starts. We were very fortunate that the two key senior stakeholders were both entirely on-side and prepared to take the expected kick-back alongside RSA. It made us very aware as a group that projects such as these live or die on the support of senior leads, and therefore appreciative of the support we got; you need to be confident that your project sponsor(s) have your back.
Data is key, both for informing the changes you make, and for justifying both the investment of resource, and measuring the success of any implementation. So, do your groundwork in advance, and gather as much data as possible, both quantitative and qualitative. This might need some lead time. For example, a survey may need to be run on an old process in order to provide comparison data for a survey on the new one.
And finally, most large-scale process reviews are going to touch on IT systems at some stage and, if you follow an RIE-type model, you don’t want the momentum generated by that event to fizzle out. So, line-up IT systems development time in advance. Although you may not know the specifics of the changes which might arise from the event, you’ll probably have a good sense of whether any IT systems support might be required. Ideally, get someone in the room during the event, otherwise certainly have meetings, and a commitment to provide development time, confirmed in advance.