2. Theory of Change, Positionality, and Your Role

🎯 Learning Outcomes	📍 Guiding Questions
Create a simple theory of change linking activities to outcomes and impact Analyse how context, power, and positionality influence training design and outcomes Identify key assumptions and risks that may affect the success of your training	What change are you trying to contribute to, and how will training support that? What assumptions are you making about how change will happen? How do your role and positionality influence the design and delivery of this training?

In the previous lesson, you mapped the system your training sits within — the actors, resources, constraints, and relationships that will influence it. Now the question is: how does your training lead to change within that system?

This lesson helps you make your intended change explicit, examine the assumptions built into it, and reflect on how your own perspective influences the design.

Why this matters¶

A system map helps you understand the environment your training sits within. A Theory of Change helps you clarify what you want to happen within that environment. The two are closely connected, but they do different kinds of work — and it is important not to blur them.

Seeing how a system is structured does not, on its own, tell you what change is realistic or how training might help bring it about. You still need to set out that logic clearly.

This matters because training designs often fail at the level of assumption. If you cannot explain, in a clear sequence, how your training is expected to lead to the change you want, then key parts of your design are still implicit. Making those links visible gives you something you can examine, question, and improve, rather than simply hoping the training will have the effect you intend.

From system to Theory of Change¶

Theory of Change

A Theory of Change is a clear explanation of how and why your activities are expected to lead to the outcomes and impact you care about. It lays out the steps in that pathway and makes the assumptions behind them visible.

The basic structure looks like this:

flowchart LR
    A["<strong>Inputs</strong><br/>what you bring"] --> B["<strong>Activities</strong><br/>what happens<br/>during training"] --> C["<strong>Outputs</strong><br/>what participants<br/>produce or complete"] --> D["<strong>Outcomes</strong><br/>what changes in their<br/>behaviour or practice"] --> E["<strong>Impact</strong><br/>the broader change<br/>this contributes to"]

Building yours step by step¶

Start from the right side of the chain, not the left. Begin with the impact you hope to contribute to, then work backwards. This keeps your logic clear — it’s easy to list activities you enjoy delivering, but harder to explain exactly how they lead to real-world change.

For each link in the chain, ask: What needs to be in place for this step to lead to the next? These are your assumptions. Write them down. For example, if your chain says "participants learn data analysis skills → they apply those skills at work," you're assuming they have access to relevant data, that their managers support new approaches, that they are motivated to apply the skills, and that they have time to practice. Each assumption is a potential point of failure — and an opportunity to strengthen your design or adjust your expectations.

A Theory of Change in action

An NGO runs a three-day training on data collection methods for community health workers in rural clinics. Their chain:

Inputs experienced trainers, mobile devices, sample datasets
Activities hands-on practice entering and cleaning patient data
Outputs each participant submits a complete, accurate dataset from their clinic
Outcomes health workers routinely collect reliable data as part of their workflow
Impact better data drives better resource allocation across the district

Their key assumption? That participants will have reliable phone signal and electricity to charge devices back at their clinics. When they surface this assumption, they realise they need to build in an offline-first workflow — and talk to district managers about charging stations before the training, not after.

Here is another example: Can you figure out what it's referring to?

You'll return to your Theory of Change throughout this workbook — refining it as you define learning outcomes in Lesson 5, design activities in Lesson 7, and think about assessment in Lesson 9. Treat it as a living document, not a one-off exercise.

Your role in the system¶

Training is not neutral. The choices you make as a designer — what to include, whose examples to use, what counts as "good" performance — reflect your position, your background, and your assumptions about what matters.

This isn't a problem to solve; it's a reality to be aware of. Consider the difference between these roles:

Role	What it looks like	When it fits
Instructor	You set the agenda, deliver content, assess outcomes	When learners need specific technical skills and you have clear expertise
Facilitator	You guide discussion and create conditions for learning, but participants drive the content	When learners have significant existing knowledge or the topic requires local adaptation
Co-designer	You build the training with participants, not just for them	When power dynamics matter, when local context is essential, or when you're an outsider to the community

Most real training involves a mix of these roles. The key is to choose deliberately rather than defaulting to "instructor" because it's familiar.

Pause and reflect

Think about a training you've delivered or are planning. What role did you (or would you) naturally take? Who decided the content, the format, the success criteria — and who was left out of those decisions?

In practice¶

👉 Activity 2: Theory of Change — Build the logical chain from what you do to the impact you hope for, and surface the assumptions hiding in that chain.

Before you move on¶

You should now have:

a draft Theory of Change with assumptions made visible
a deliberate choice about your role (instructor, facilitator, co-designer, or a mix)

These are living documents

Nothing here needs to be final. Training design is iterative — your Theory of Change and role choice will evolve as you work through the rest of this workbook and as you learn more about your learners. Revisit and rework these outputs whenever your thinking shifts.