Monitor processes

Keep all departments aligned to the overall vision of the organization.

Develop and maintain policy

Update GitBook documentation and infrastructure where necessary. See this Miro board for reference on goals, hazards, constraints and requirements:

Identify Stakeholder Needs

  • Establish, approve, or update requirements

  • Gather and understand who you are building for and understand their main needs and expectations.

  • Discuss with representatives and relevant parties if updates are required. It's important to consider that each function owner or team are autonomous units that can be excluded from the organization at any time.

Explore alternative concepts

  • Identify tradeoffs, and explore various concepts, their feasibility, and their impact on the stakeholder needs.

  • Keep exploring resources about organizational design and familiarise yourself with new tools.

System architecture and component breakdown

Decompose larger concepts into smaller components.

Components have inputs, execute a function and outputs.

System architecture captures the relationship between elements:

Assign the functions identified in the functional architecture to the corresponding logical components. This includes both functions related to human operations and those that are purely software or hardware-based.

Remember to maintain the safety of the system by evaluating the safety of its components.

Reliable but unsafe

Components do their job but together an error might occur → the problem is in the system design.

Unreliable but safe

A task or function might be well documented, but an individual might no execute it → specify requirements. Deviating from instructions can also be unreliable but safe, if it secures the overall system

Component categories

  • Goal condition - have a goal for controllers/operators

  • Action condition - be able to act on the system (actuators)

  • Model condition - design a model of the system

  • Observability condition - be able to obtain the state of the system

Gather and Verify Requirements & Constraints

Define the objectives/goals of the system, which should be guided by the stakeholder's needs.

Define constraints: safe and acceptable ways to achieve system goals.

Define functional requirements and performance requirements. Create a hierarchy of requirements to understand how they are related.

Don't specify the exact implementation. It depends on the technical constraints, considering the overall system design.

Link widgets/components to requirements and visualize them. Continuously ensure validity - do the requirements make sense? Review, iterate, and refine.

Identify Risks and Hazards

Assume that the system is unsafe. Safety is a system property and errors are an integral part of maintenance.

Hazard = a state the system should never be in.

Understand the larger sociotechnical system it belongs to. It can impose constraints on the system you are designing and reduce risks. Safety is equally a top-down system property, not a component property.

Risks and hazards can be technical, financial, social, and managerial. A top-down review can identify risks, safety concerns, and combinatorial structure of possible accidents.

Pure bottom-up decentralized decision-making can cause a lack of safety in the system.

The accident causality model is not ideal:

  • condition(s) → event → condition(s) → event → condition(s) → event

Causality is often complex and non-linear. Subjectivity in describing causality creates additional vulnerabilities: Subjectivity in granularity can be influenced by politics, and subjectivity in changing conditions limits the overall understanding of interconnected events.

Root-causes are multi-factorial.

Blame is the enemy of safety.

STPA - System Theoretic Process Analysis

  1. Identify potential for inadequate control

    • Control not provided

    • Unsafe control action provided

    • Safe control action too early or too late

    • Control action stopped too soon or applied for too long

  2. Define how could inadequate control occur

    • Build in protection against degradation

    • Design constraints, ensure review cycles

When identifying risks and faults, bring the system back to a safe state and no further - “proper paranoia”.

Communicate and Document the system design

Create a visual map that clearly represents the current state of the system, focusing and zooming in on the relevant parts. Some parts need to be generalized for simplicity, others not shown at all, and others altered slightly to make sure the system design helps others make well-informed decisions.

Closed-loop Diagram

Viable System Model

Entity-Relationship Diagram

Create an entity-relationship diagram to visualize how components are connected. You can find more details on how to create an ERD here:


Make sure you specify the goals of the ERD and regularly review whether it represents different fractal dimensions of the same ontology.

Data Model

Based on the ERD, create a database model for a relational database.

Provide written documentation based on the visual map.

Create models and adapt models over the course of the project.

Validate or simulate the design

Find a way to simulate the design. Either through interviews or low-stakes real life scenarios with a similar system design. Ensure integrity and analyze the impact on cost, performance, and risk.

When creating a model, write down how it currently is, not hypothetical ideas. Write out all outputs, i.e. proposal, product, etc. What are the artifacts/types of data we're creating?

There is no perfect design.

Aim to reduce cost, while increasing value output.

Process control and evaluation of change/adaptation over time can help model and predict accidents.

Keep track of stakeholder requirements - they might shift and extend over actual capabilities of the system.

Control the system and ensure the implementation

Remember that external information sources impact the control algorithm. New information can improve it but needs to be considered carefully.

Model/simulate process based on control algorithm. Consider time delays, a change in the system may produce effects only much later.

If you are changing two processes simultaneously, one might change faster than another.

Make sure that different controllers don’t have an overlap in process, set clear boundaries to what is being controlled by which controller.

Remember: Organizations need to be closed-loop systems to adapt to the environment.

Last updated