DESIGN ANALYSIS

Using a FRAM model for design analysis

USING A FRAM MODEL FOR DESIGN ANALYSIS
 
A model developed using FRAM can support the design or redesign of complex socio-technical systems, work processes, technologies, and organisational arrangements.
 
Design analysis differs from retrospective and prospective analysis. A retrospective analysis examines how a particular event or outcome developed. A prospective analysis explores how performance variability may combine under possible future conditions. Design analysis, by contrast, focuses on whether a proposed system can function successfully under the conditions in which it is expected to operate.
 
The analysis begins by describing the functions that are necessary for the intended activity or system to succeed. Each function is characterised through the six FRAM aspects: Input, Output, Precondition, Resource, Control, and Time. The resulting model makes the functional dependencies within the proposed design visible.
 
This supports questions such as:
 
• Which functions are essential for the intended system performance?
 
• Are the necessary inputs, resources, preconditions, controls, and time available?
 
• Are responsibilities and functional dependencies clearly understood?
 
• Where does the proposed design depend on assumptions about human, organisational, or technological performance?
 
• Which functions may need to adapt when actual conditions differ from those anticipated during design?
 
• Where might variability propagate or combine across functional couplings?
 
• Are there functions that are highly dependent on a single resource, control, or source of information?
 
• Could the proposed design create unintended interactions, bottlenecks, conflicts, or new dependencies?
 
• How might technological or organisational changes affect other parts of the system?
 
• What should be monitored once the design is implemented?
 
FRAM design analysis does not assume that a system will operate exactly as specified. Procedures, interfaces, automation, roles, and organisational structures represent Work-as-Imagined. Actual performance will also be shaped by changing demands, available resources, local constraints, competing goals, and the adjustments made by people, organisations, and technologies.
 
For this reason, the proposed design should not only describe how the system is expected to work under ideal conditions. It should also consider how functions may vary and how the system may adapt when conditions change.
 
Different design alternatives can be represented as different models or model versions. Their functional structures, dependencies, resource requirements, and possible variability can then be compared. This can help identify where a proposed change strengthens the system, transfers demands elsewhere, introduces new couplings, or removes adaptive capacity that may be necessary for successful everyday performance.
 
A FRAM-based design analysis can therefore support:
 
• The design of new work systems and services
 
• The redesign of existing processes and organisational arrangements
 
• The introduction of new technologies or automation
 
• The allocation of functions between people and technology
 
• The evaluation of procedures, interfaces, and information flows
 
• The comparison of alternative design concepts
 
• The examination of Work-as-Imagined before implementation
 
• The identification of monitoring and feedback requirements
 
• The exploration of resilience and adaptive capacity
 
The purpose is not to predict every possible future situation or to eliminate all variability. In complex socio-technical systems, this would not be possible. Instead, FRAM provides a structured way to examine whether the design supports successful performance across a range of conditions and whether the system can respond appropriately when circumstances differ from those originally anticipated.
 
Design analysis should therefore be iterative. As the design develops, the FRAM-based model can be reviewed and updated using information from designers, operators, subject-matter experts, intended users, simulations, prototypes, and operational experience. Comparing Work-as-Imagined with emerging evidence about Work-as-Done can reveal assumptions and dependencies that might otherwise remain hidden.
 
The outcome is not a final prediction of system behaviour. It is a more transparent understanding of how the proposed system is expected to function, where successful performance depends on interactions and adjustments, and where design interventions, monitoring, or additional support may be beneficial.