In brief
- Work-as-imagined is how people think work happens or should happen.
- Work-as-prescribed is how work is written into procedures, policies, checklists and standards.
- Work-as-done is how work is actually carried out under real conditions.
- Differences between them are normal in complex systems. They can reveal both resilience and risk.
- The aim is not to catch people out, but to understand how the system really works and how it can be better supported.
Why this topic matters
Most organisations rely on procedures, policies, protocols, checklists, training materials and digital systems to describe how work should be done. These are important. They create shared expectations, support coordination, and help organisations show that risks have been considered.
But written descriptions never capture the full reality of work. Everyday work happens with interruptions, time pressure, competing priorities, missing information, changing demand, equipment limitations, staffing constraints and local judgement. People and teams continually adjust what they do so that care is delivered, flights continue, trains run, operations recover and systems keep functioning.
This is why the distinction between work-as-imagined and work-as-done is so useful. It gives us a more respectful and realistic way to talk about work. Instead of assuming that every difference from a procedure is a failure of compliance, it asks what conditions shaped the difference and what the organisation can learn from it.
A simple way to think about it
Work-as-imagined is the picture of work held by designers, managers, regulators, investigators, procedure writers, trainers, auditors and sometimes practitioners themselves. It is the work people expect to happen, or believe happens, when they are not directly observing the messy details of the situation.
Work-as-prescribed is the written or formal version of work: the procedure, protocol, checklist, pathway, policy, standard, training instruction, software workflow or regulatory requirement. It is one form of work-as-imagined, but it is useful to name it separately because prescribed work has a particular authority in organisations.
Work-as-done is the work that actually takes place in context. It includes the small adjustments, sequencing decisions, informal checks, prioritisation, communication, judgement and practical problem-solving that may not appear in the written process.
These are not competing realities where one is simply “right” and the other is “wrong”. Procedures may be necessary and well designed. Everyday adaptations may be skilled and safety-enhancing. The important question is whether the relationship between them is understood.
Beyond WAI and WAD: Work-As-X
The familiar contrast between work-as-imagined and work-as-done is a helpful starting point, but it can be too simple if we use it alone. In practice, there are several versions of work circulating in a system.
Useful distinctions
- Work-as-imagined: how work is thought to happen, or expected to happen.
- Work-as-prescribed: how work is formally written in procedures, protocols, standards or software rules.
- Work-as-normative: how external rules, professional standards, regulation or law say work should be organised.
- Work-as-done: how work actually unfolds in the real operating environment.
- Work-as-disclosed: how people describe their work in interviews, meetings, reports or incident accounts.
- Work-as-observed: how work appears to an observer during audits, shadowing, ethnography or safety studies.
This wider Work-As-X view is especially useful in socio-technical systems where knowledge is distributed across people, teams, organisations, technologies and documentation. What a regulator imagines, what a procedure prescribes, what a digital system permits, what a practitioner reports, what an observer sees and what actually happens may all differ in meaningful ways.
These differences are not just “communication problems”. They are clues about how knowledge, control, responsibility, authority and adaptation are distributed across the system.
What this helps you see
Looking carefully at everyday work helps make hidden system conditions visible. It can show where a procedure assumes more time, staffing, certainty or information than the situation provides. It can reveal where technology requires extra work, where handovers depend on informal knowledge, or where a team has developed a workaround because the official process does not fit the task.
It can also reveal what is going well. A Safety-II and resilience engineering perspective asks how successful performance is created, not only why things fail. Many safe outcomes depend on people noticing weak signals, anticipating demand, coordinating across boundaries, recovering from missing information and making sensible trade-offs under pressure.
The gap between prescribed work and everyday work therefore has two sides. It may show vulnerability, such as under-resourcing, unclear responsibility or excessive reliance on informal memory. It may also show adaptive capacity: the ability of people and systems to adjust before, during or after changing conditions.
Examples in practice
In healthcare, a clinical guideline may look straightforward on paper but be difficult to use in a busy ward, operating theatre, intensive care unit or discharge process. Medication reconciliation at discharge, for example, depends on timing, electronic records, pharmacy input, medical decisions, patient counselling and coordination with primary care. A protocol may describe the intended sequence, but everyday practice may vary because discharge timing, staffing and information availability vary.
In neonatal medication administration, written procedures may not fully capture the complexity of dosing, preparation, interruptions, patient condition, off-label medication use and multidisciplinary coordination. The point is not simply that staff “deviate” from rules. The point is that safe care often depends on adjustments that the formal process does not fully describe.
In aviation and air traffic management, work-as-done matters because operational safety depends on timing, monitoring, communication, anticipation, weather, traffic conditions, automation, procedures and changing goals. New technology or a new concept of operation may look safe in design documents but still change the practical conditions under which controllers, crews and systems coordinate.
The same issue applies to digital and AI-enabled systems. A software workflow or automated recommendation may prescribe a particular path, but real work may involve exceptions, overrides, missing data, uncertainty and human judgement. If the design does not understand work-as-done, the technology may create new burdens while appearing efficient on paper.
How to explore work-as-done
Understanding work-as-done usually requires more than reading a procedure. Useful evidence may come from observations, interviews, workshops, walkthroughs, incident narratives, audits, handover documents, system logs and comparison with guidelines or standards.
FRAM is one practical method for this kind of analysis. It models work as a set of functions and examines how those functions depend on one another through inputs, outputs, preconditions, resources, controls and time. This is helpful because real work rarely follows a simple linear sequence. One function may create the conditions for another, delay another, depend on a resource elsewhere, or be affected by timing and workload.
A useful analysis does not ask only, “Was the procedure followed?” It asks: What made the procedure easy or difficult to follow? What did people have to adjust? Which adjustments helped? Which adjustments created fragility? What did the written process assume? What was actually available at the time? What would make good work easier?
Using the insight responsibly
This topic has to be handled carefully. People will not describe everyday work honestly if they think the information will be used to blame them. A human-centred analysis should create the conditions for openness, curiosity and learning.
It is also important not to romanticise workarounds. Some adaptations are intelligent and necessary. Some are signs that the system is forcing people to carry too much risk. Some may work most of the time but fail when demand increases or when an experienced person is absent. The task is to understand which adaptations should be supported, which should be redesigned, and which indicate a deeper system problem.
The best use of WAI/WAD analysis is practical improvement: clearer procedures, better technology, more realistic staffing assumptions, improved training, better handovers, stronger feedback, and safer ways to manage variability.
Limitations and cautions
Work-as-done is not fully visible. What people disclose in an interview is not the same as what happens in practice. What an observer sees may change because people know they are being observed. What a log records may miss judgement, communication, uncertainty or context.
For that reason, it is better to treat every account as a partial view. Work-as-prescribed, work-as-disclosed and work-as-observed can all help us understand work-as-done, but none of them is a perfect copy of it.
The practical value comes from triangulation: comparing documents, observations, interviews, operational data and stakeholder perspectives. Used well, the distinction between work-as-imagined and work-as-done helps organisations learn from everyday work before a serious event forces the lesson.
Related publication(s)
- Kaya, G.K. and Hocaoglu, M.F. (2020). Semi-quantitative application to the Functional Resonance Analysis Method for supporting safety management in a complex health-care process. Reliability Engineering & System Safety, 202, 106970. DOI: 10.1016/j.ress.2020.106970.
- Kaya, G.K., Ovali, H.F. and Ozturk, F. (2019). Using the Functional Resonance Analysis Method on the drug administration process to assess performance variability. Safety Science, 118, 835–840. DOI: 10.1016/j.ssci.2019.06.020.
- Kaya, G.K., Stallard, R., St-Laurent, M., Li, W.-C. and Sujan, M. (2026). Exploring unstable approaches in aviation: utilising functional resonance analysis method. The Aeronautical Journal. 130(1345), 917–943. DOI: 10.1017/aer.2025.10108
- Sujan, M., Lounsbury, O., Pickup, L., Kaya, G.K., Earl, L. and McCulloch, P. (2024). What kinds of insights do Safety-I and Safety-II approaches provide? A critical reflection on the use of SHERPA and FRAM in healthcare. Safety Science, 173, 106450. DOI: 10.1016/j.ssci.2024.106450.
Selected references
- Clay-Williams, R., Hounsgaard, J. and Hollnagel, E. (2015). Where the rubber meets the road: using FRAM to align work-as-imagined with work-as-done when implementing clinical guidelines. Implementation Science, 10, 125. DOI: 10.1186/s13012-015-0317-y.
- Hollnagel, E. (2012). FRAM: The Functional Resonance Analysis Method: Modelling Complex Socio-technical Systems. Ashgate.
- Hollnagel, E. (2015). What is work-as-imagined different from work-as-done? In R. Wears, E. Hollnagel and J. Braithwaite (eds), The Resilience of Everyday Clinical Work. Ashgate.
- Patriarca, R., Falegnami, A., Costantino, F., Di Gravio, G., De Nicola, A. and Villani, M.L. (2021). WAx: An integrated conceptual framework for the analysis of cyber-socio-technical systems. Safety Science, 136, 105142. DOI: 10.1016/j.ssci.2020.105142.
- van Dijk, L.M., van Eikenhorst, L. and Wagner, C. (2022). Daily practice performance (Work-as-Done) compared to guidelines (Work-as-Imagined) of medication reconciliation at discharge: Outcomes of a FRAM study. Safety Science, 155, 105871. DOI: 10.1016/j.ssci.2022.105871.
- Woltjer, R., Pinska-Chauvin, E., Laursen, T. and Josefsson, B. (2015). Towards understanding work-as-done in air traffic management safety assessment and design. Reliability Engineering & System Safety, 141, 115–130. DOI: 10.1016/j.ress.2015.03.010.