Reflective journal My account of the SDF work, written in February 2026 about events in 2025.

Technical materials The code, processing logic and diagrams of what I built, showing how it worked.

Dated messages Messages from the time, used only to confirm dates and the order of events.

Participant account What an interviewee described. Not observed or checked independently.

Interpretation dashed outline Conclusions drawn from the evidence.

Stage of use Whether a change was in use, being tested, explored or proposed. These labels describe a stage, not whether the change succeeded.

Research question 2 · Responses

How did people respond, and when did an alternative become part of regular work?

Short answer

People responded in many ways, and their changes had reached different points: some were in use, some were being tested, some were only proposed. In my own work, I could trace an alternative arrangement becoming part of recurring SDF reporting, which I call An alternative way of doing part of a task, developed in response to a problem, that became part of the regular work of completing it. Local adaptation is broader and includes responses whose workaround formation was not established, whether they were in use, tested, explored or proposed.Thesis Sections 1.8 and 2.9.2. The interviews described real changes too, but gave less detail about what prompted them and how they changed the earlier work.

Thesis Section 7.4 · full question wording in Section 1.4

Two kinds of response

Every workaround is a local adaptation, but not the other way round

When a tool or process does not fit the work, people adjust. A team manages its own development environment; someone tests a prototype with made-up data; someone proposes a booking agent. These are local adaptations.

Workaround formation is the narrower case: an alternative that became part of how a task was regularly done, as my SDF reporting arrangement did.

How I identified workaround formation

I considered these four features together.

  1. A problem was affecting the work.
  2. Someone deliberately developed an alternative to deal with it.
  3. The alternative became part of the work needed to complete the task.
  4. It stayed in use, or changed how the task was carried out.

Thesis Section 2.9.2

What each setting showed

One workflow examined in depth, alongside accounts of other university work

I took part in the SDF work. A reflective journal written in February 2026 about events in 2025, alongside the technical materials I built, let me describe its development in detail. The interviews gave participants' accounts of their own work, with less detail about how each change developed.

My SDF reporting workflow

In regular use

Every reporting cycle I had to match staff records, funding allocations and expense transactions by hand. I built an arrangement in which each part had its own job.

Source records

Staff reference and transaction data

Python processor

A shared code, TR_Code, kept each transaction linked to the right staff record; totals were calculated and outputs prepared for different purposes

For reporting

A spreadsheet and matching email file for each staff member, prepared as a pair and sent to staff

For questions

Selected data files, with direct identifiers replaced, that I asked questions about in plain language through Microsoft 365 Copilot

For checking

Processing logs and saved outputs that kept a route back to the records

My checking and explanation

When a figure or a Copilot answer needed attention, I went back to the prepared records and the funding context, reconciled them, and explained the result

The workaround was this whole arrangement, including my checking, not Python or Copilot on its own. Open each part on the SDF page.

1 · A problemLinking records by hand, every cycle Section 4.2.1
2 · A deliberate alternativeAn arrangement that kept records linked and figures traceable Section 4.2.4
3 · Part of the workMy journal describes its routine use; the technical materials show what I built Section 4.7
4 · Changed the taskIt changed how SDF reporting was carried out Section 4.7

My conclusion: the SDF account supports workaround formation for this connected arrangement. It changed part of the reporting work; it did not replace the wider university process or remove the need for checking.

Reflective journalTechnical materialsThesis Sections 4.3–4.7 and 2.9.2 · Figures 4.5.1.1 and 4.7.1

Institutional support staff

IP01Partly rolled out

A managed service for subject-related assistants that had begun rolling out. IP01 linked its slower wider rollout to governance and concern that answers could sound authoritative while being wrong.

IP02In development

A team-managed environment for building prototypes. IP02 described engineering checks and sign-off needed before colleagues could rely on an application.

IP03Being tested

A prototype tested with made-up data that placed draft messages in IP03's own mailbox for review. Testing with live data and production approval were still outstanding. IP03 called it a “workaround”.

“having that control of our own environment, yeah, definitely helps with some of the friction” IP02

Three separate projects, as each participant described them. Thesis Sections 5.2–5.5

Everyday staff

Reported in use

SP05 · two internal agents: one to classify research outputs, constrained to selected sources, and one that colleagues used to check grant statements against funder requirements

SP06 · an Excel attendance workbook, with Copilot's help on the formulas

SP06 built the workbook from an official class list and used it across subjects to see which students needed follow-up. Copilot helped develop formulas, which SP06 tested in Excel. It is a spreadsheet SP06 managed, not an automated GenAI system.

SP08 · used Copilot to understand error messages in research software

Explored

SP05 · an external tool for preparing impact cases, used on a limited basis

Proposed

SP03 · an agent to help arrange student bookings

SP07 · ideas for advanced reporting and agents

These accounts did not give enough detail to show workaround formation. Thesis Sections 6.5 and 7.4

Research it builds on

A narrower use of “workaround” than Alter's

Alter, S. (2014). Theory of workarounds. Communications of the Association for Information Systems, 34(1), 1041–1066. https://doi.org/10.17705/1CAIS.03455 describes a workaround broadly: any goal-directed change that lets work continue despite an obstacle, whether temporary or lasting. This study uses a narrower scope, focusing on alternatives that became part of regular work. That does not exclude temporary workarounds from Alter's account.

Azad, B., & King, N. (2008). Enacting computer workaround practices within a medication dispensing system. European Journal of Information Systems, 17(3), 264–278. https://doi.org/10.1057/ejis.2008.14

A workaround becomes usable when it fits the roles, timing and cooperation around it, so building something is not the same as it becoming part of the work.

Behrens, S., & Sedera, W. (2004). Why do shadow systems exist after an ERP implementation? Lessons from a case study. In PACIS 2004 Proceedings (Paper 136). https://aisel.aisnet.org/pacis2004/136

Shadow systems run alongside official ones. Used here to judge a locally built arrangement by what it does, not where it came from.

Wibisono, A., Alhassan, I., Sammon, D., Heavin, C., Kiely, G., & Suryani, E. (2019). Understanding theory of workarounds in practice. Procedia Computer Science, 161, 187–194. https://doi.org/10.1016/j.procs.2019.11.114

Workarounds as a process, from a problem to a changed way of working.

Why it matters

Trying something is not the same as changing how work is done

A change can be useful without becoming part of a recurring workflow. The SDF account showed how an alternative became part of regular reporting. The interviews described changes at several stages, but provided less detail about how they developed. Thesis Sections 7.4 and 7.7.1