Most projects are not isolated but are embedded in wider systems: organisational structures, user ecosystems, stakeholder agendas, and legacy technologies. Ignoring this context leads to unintended consequences, misalignment with organisational goals, and reinforcing existing dysfunctions A systems-informed approach at initiation helps frame the project correctly, design for sustainability, and avoid solving the wrong problem well. ## Define the System Boundary Thoughtfully - What is included in this project’s scope? - What lies outside—but still interacts with it? - Who or what might be unintentionally affected? **Example**: A project to implement a new workflow tool may sit within the digital team, but its success depends on training, user habits, legacy systems, and leadership support. Use a rich picture or context diagram to map relationships before jumping into task lists. ## Identify the System’s Purpose and Behaviour - What is the system currently _doing_, not just what it is _supposed_ to do? - Is the system's actual behaviour aligned with its stated purpose? **Example**: A knowledge-sharing system might exist to "support learning", but in practice it may incentivise hoarding expertise to gain status. You need to understand both stated and observed purpose. Observe current behaviour, speak to users, and look for dissonance between goals and outcomes. ### 3. Map Key Stocks and Flows Identify: - **What is being accumulated or depleted**? (e.g. knowledge, technical debt, trust, user engagement) - **What are the key flows** that drive this? (e.g. onboarding, error resolution, feedback loops) **Application**: If you're building an onboarding process, your key stock is _competency_. Your inflows are _training_ and _experience_. Your outflows are _confusion_ and _attrition_. Structure the project to optimise these. ## Surface Feedback Loops Early Look for: - **Balancing loops** (e.g. "increased usage → longer response times → user frustration") - **Reinforcing loops** (e.g. "positive reviews → more usage → more feedback → further improvements") **Action**: Ask the team, “If this change works as planned, what will it set in motion? What might bounce back or escalate unexpectedly?” This avoids ‘linear planning’ and helps you design mitigating actions from the start. ## Consider System Delays Projects often misfire by expecting instant change. Systems often respond with a delay, especially in areas like: - Behaviour change - Organisational learning - Trust or morale - Technical resilience Build realistic timelines for outcomes, not just outputs. Don’t measure success too early. ## Engage Across System Boundaries Systems thinking means recognising interdependence. At project kick-off: - Identify stakeholders _outside_ your immediate team or remit. - Understand how they interact with the system you are affecting. - Build feedback mechanisms to stay aware of upstream and downstream effects. Use stakeholder influence maps and impact pathways. ## Use Systems-Based Project Questioning | Identify | Why It Helps | | ----------------------------------------------------------------------------- | -------------------------------------------------- | | What system is this project embedded in? | Grounds the work in context | | What are the desired long-term behaviours? | Keeps focus beyond deliverables | | What are the key stocks and how do they change? | Identifies points of control and delay | | What feedback loops already exist? | Reveals stabilisers and amplifiers | | What unintended consequences could emerge? | Anticipates side effects | | Who benefits, who bears cost, and over what time frame? | Surfaces equity and distributional concerns | | What is our time horizon? Are we measuring the right thing at the right time? | Prevents premature judgement of success or failure |