The importance of reflecting on what you are doing, as part of the learning process, has been emphasized by many reviewers. Building the capacity to reflect on action so as to engage in a process of continuous learning is increasingly seen as an important aspect of behavior change, and it is beginning to be used in many models of changing professional practice. However, it is not a conscious behavior for many teams, and effort needs to be put in to provide teams with tools that can support reflection. These tools are usually known under names such as After Action Review (AAR) or Learning Debriefs, and are used by to capture the lessons learned from past successes and failures, with the goal of improving future performance.
In terms of evaluation they are starting to be paired with design processes such as program theory-based approaches. Developing results-based framework diagrams can help with structuring and deepening participants thinking and planning (both in developing action plans and monitoring plans) for a project. Then after these plans have been implemented (action), an AAR can provide people with a platform and space to reflect on what happened and what they are learning about their project.
AAR is a form of group reflection; participants review what was intended (activity aims), what actually happened (intended and unintended outcomes), why it happened and what was learned. AARs should contribute to information that not only helps assess an immediate activity, but also helps assess progress towards longer-term term progress set out in the underlying Theory of Change (TOC) and accompanying logic models. AARs can be used in short, frequent group process checks, or more extended, in-depth explorations to assess progress at the wider level. It can be undertaken by a group or an individual as they ask themselves four questions:
What was supposed to happen? By asking each participate about their expectations it can sometimes highlight problems in communication as individuals have different expectations.
What actually happened? By identifying what went on an accurate picture can be built up.
Why was there a difference? This is where participants need to concentrate on the what – and not the who – between expectations and what actually happened.
What can we learn from this? What learning points have been identified so that the organisation or individual continues to improve?
AARs can be conducted almost anywhere, and will vary in length. For example, an AAR can be conducted after a one-off event (in 15 minutes or so), or a much more focused meeting could be held to reflect on how planned intermediate and longer-term outcomes are being achieved at an organizational or program level. It is important that the underlying culture of those undertaking an AAR is one of openness and learning. It is not about allocating blame, but ensuring that those involved can move forward (and adapt where necessary). Lessons are not only shared by the individuals involved but can be documented and shared with a wider audience.
Every organization, every partnership or team, and every intervention will likely require different levels of preparation, execution, and review. However, a number of best practices do emerge across the literature:
Lessons must first and foremost benefit the team that develops them. The AAR process must start at the beginning of the activity (with clear aims set out in advance through a TOC or outcomes modeling process). AAR Lessons must link explicitly to future actions, that support desired outcomes. And leaders must hold everyone, especially themselves, accountable for learning.
Managers and facilitators should phase in an AAR culture. This can begin with facilitating simple AARs around team projects – keeping things simple at first and developing the process slowly—adding knowledge-sharing activities and systems, richer metrics, and other features dictated by the particular initiatives in question.
If there are issues with either openness or time, it may be worthwhile to gather individual ideas first – and then facilitate a group discussion.
By creating tight feedback cycles between planning and action, AARs build team and organizational capacity to succeed in a variety of conditions. AARs are not just a source of lessons, but provide a low-technology tool which teams and communities can use on how to draw new lessons from novel and evolving situations for which they did not train—situations they may not even have imagined. In a fast-changing environment, the capacity to learn lessons and adapt can be more valuable than any individual lesson learned. That capacity -which can be used for adaptive management or for innovation – is what can be gained by more closely linking outcome planning and learning-based reflective activities such as AARs.
This post explores how evaluations benefits from being focused on a small set of key questions. These are often referred to as key evaluation questions (KEQs). They should be seen as high level questions that assess progress towards the main specified outcomes, and will be answered by combining data from several sources and methods.
Evaluations provide an opportunity for your (or your clients’s) intervention’s overall progress to be considered, including focused consideration of specific aspects of the initiative. A well-developed theory of change (TOC) and accompanying logic models provide an outline that helps to develop measures of success that traces the intervention’s development and impact over time. These measures, in turn, need to be focused with appropriate KEQs that are driven by funders, project participants and other key stakeholders.
The five criteria to evaluate interventions (relevance, effectiveness, efficiency, impact, and sustainability outlined in the OEDC/DAC evaluation guidelines provide a good starting framework for a range of initiatives in development areas (health, natural resource management, community resilience, etc.) . Evaluation questions also to be considered in a complex intervention such as this should address context, reasons for adaption and emergence of activities and outcomes, different perspectives and inter-relationships that impact project success, sustainability and transferability.
A useful starting set of key evaluation questions to guide initial analysis are:
Is the research delivering on outputs and outcomes as planned? (efficiency and effectiveness)
Have applied activities and their delivery methods been effective? Are there aspects that could have been done differently? (process effectiveness)
Is the wider project story being told? What range of outcomes (intended and unintended) has the research project contributed to – taking account of each of social, economic, environmental and cultural considerations (impact)
How has the project influenced the stakeholder community, and what capacities has it built? (impact)
Is the project being delivered on budget? What aspects of the participatory elements of the project could be done differently next time to cut costs while still delivering achievements? (efficiency)
Is the project impacting positively on key groups and issues that have been identified as important in project design? (impact)
Is there evidence that the initiative is likely to grow – scaling up and out – beyond the project life? (sustainability)
To what extent did the initiative deliver against the needs of key stakeholders? Were the size, scale and approach taken for each need appropriate? (impact & efficiency)
These questions need to be clarified by key project stakeholders. Some may be amended, others dropped, and new questions can be included. Developing these questions also provides an opportunity to revise the underlying theory of change and any accompanying logic or outcome models. In this way KEQs can be seen to help intervention planning and evaluation.
This post looks more specifically at outcomes, and how they can be developed and written. It highlights the benefits of focusing on outcomes for project planning, implementation and evaluation. It also provides some tips and ideas for involving program staff and stakeholders in developing and working with outcome statements.
Until recently, the performance of many public sector programs has been judged largely on inputs, activities and outputs. Over recent years this approach has been increasingly questioned as being too concerned with efficiency considerations, without a corresponding focus on what benefits are actually arising from program funding and activities. Increasingly the trend is moving towards a focus on the specification and achievement of outcomes, revealing more about how effective programs are in achieving real development changes on-the-ground.
Outputs are the goods and services that result from activities. Outcomes are the constructive impacts on people or environments. In the past planning and evaluation has tended to focus on program outputs, or how we keep ourselves busy – the ‘what we do’ and ‘who we do it with’. This enables us to tell our partners, funders and stakeholders about what the program does, the services it provides, how it is unique, and who it serves. We can describe and count our activities and the different goods and services we produce. Now, however, we are being asked what difference it makes! This is a question about outcomes (see figure). Outcomes are the changes, benefits, learning or other effects that happen as a result of what the program offers or provides. Outcomes are usually specified in terms of either: i) social and organizational capacities (social outcomes – e.g. learning, understanding, perceptions, attitudes and behaviors), or ii) state conditions (the bio-physical, ecological, social or economic changes in a system).
While most people intuitively appreciate this distinction between outputs and outcomes, experience in results-oriented training sessions suggests that for many program staff, turning that appreciation into practice takes time. As the Keystone (2009) guide points out it takes most people quite a lot of conscious practice before they start thinking in terms of outcomes, rather than outputs or needs or activities. An outcome statement describes a result – a change that has taken place. It is not a needs statement, or an activity that is still in progress. Outputs comprise the products and activities that you do, while outcomes are what we see as a result of our outputs.) One simple test is to ask two questions of each statement: i) is it written as an outcome? and ii) does it describe changes that we can plausibly enable or facilitate in people, groups, institutions or environments?
Outcomes may be specified in different ways. Often a distinction is made between short-term, intermediate and long-term, or just intermediate and long-term. Short-term outcomes can be seen as the immediate difference that your program makes in the wider environment. A long-term outcome often has a number of short-term and intermediate outcomes that together contribute to the ultimate achievement of the long-term outcome. Collectively these outcomes should contribute explicitly to the wider vision underpinning program development. An intermediate outcome is a specified intermediate state that contributes to the desired long-term outcome – a step along the way. Intermediate outcomes are especially useful when time lags in measurable state outcomes are significant or limit timely response.
The program outcomes and intermediate outcomes should be structured in a logical hierarchy reflecting how each leads to another and/or contributes to the long-term community outcome(s). A useful way of doing this is to take each outcome and ask the question, ‘If we achieve this, what will it lead to and how will it contribute to the long-term outcome?’ Look for gaps – starting from the highest level outcome and working down the outcomes model. A test is being able to read an outcome and say, ‘Yes, this will likely be achieved if all of these initial (contributing intermediate) outcomes (and corresponding outputs) are achieved.’ The answers to these questions will enable you to draft a succinct statement of each outcome.
Each outcome statement should therefore define what will change as a result of an intervention and by how much (or, at the very least, in what direction the change will occur). This then allows the means of performance measurement to be defined. The more clearly an outcome statement specifies a desired change, the easier it is to define an appropriate indicator or indicator set.
It is not always easy to identify outcomes, and harder still to clarify them, but there are a number of key questions that can help. For example, begin by asking what is/will be different as a result of the initiative? For whom? What will be changed/improved? What do/will beneficiaries and other stakeholders say is the value of the program? For an existing program, look at the major activities. For each activity, ask yourself, ‘Why are we doing that?’ Usually, the answer to the ‘Why?’ question is an outcome. Most importantly, seek ideas and input from others. Their perspectives will help provide a broader understanding of the program and its benefits. This activity will also help build consensus among key program stakeholders.
When writing outcomes be sure to describe the desired change. Keep your outcomes SMART: Specific, Measurable, Achievable, Relevant, Time-limited. Say ‘what’, not ‘how’ – Establishing the means and plausibility of the ‘how’ is a later step. Consider whether outcomes are likely to be achieved in the program time frame.
Table 1 Examples of outcome statement structure from a range of sectors
Over x years
Over x years
Public awareness of an issue
Over x years
This post provides a short introduction to the language and concepts of outcomes. Links to a wealth of information, tips and guides from around the world can be found from the LfS Managing for outcomes: using logic modeling webpage.
Often rallying participants around the development of a visual logic model is a good place to begin the development of a theory of change. The use of key headings and post-it notes makes it easy to provide a structure to help people develop some early models that contribute directly to their program planning, and build confidence and capacity in the use of TOC outcomes-based approaches.
Logic models are narrative or graphical depictions of processes in real life that communicate the underlying assumptions upon which an activity is expected to lead to a specific result. There are four components commonly included in logic models (Fig. 2). These are the four primary components of the project or program itself – inputs, activities, outputs and outcomes. There are also four supporting activities which encourage participants to think more carefully about the underlying theory of change that they are planning to use. These supporting activities are: i) an outline of the current situation and desired vision; ii) stakeholder analysis, to identify which stakeholders should be involved in model development; iii) the scoping and planning exercise that underpins any model development; ensuring that underpinning assumptions are documented; and iv) noting internal and external factors – including related activities – that may influence outcomes.
There is no single or correct way to draw a logic model. It can be drawn horizontally (as in Fig. 1) vertically, or even in a more free-form fashion. Ideally, a logic model should be able to be displayed on a single page with sufficient detail that it can be explained fairly easily and understood by other people. Much of the value of a logic model is that it provides a visual expression of our underlying beliefs about why the program is likely to succeed through one step leading to another. Thus, each step between an activity and an output or between an output and an outcome can be thought of as an ‘if this happens … then that is likely to happen’ statement. For large or complex programs, the logic model may be divided into more detailed sections or sub-models. These may be summarized by a less detailed ‘overview’ model, often given on the first page, that shows how the component sub-models fit together into a whole.
As an example, Fig. 2 illustrates the main program logic elements set out in a horizontal fashion. The inputs are the resources used to resource the activities, produce the program outputs, and ultimately contribute towards desired outcomes. Inputs typically include such things as money, staff, and equipment/infrastructure. Inputs are usually measured as counts, such as hours of staff time, dollars spent, etc. Activities are the actual interventions and actions undertaken by program stakeholders, staff and agencies to achieve specified outputs. Activities can range from writing a memo, to holding workshops, to creating infrastructure. Activities are usually measured in terms of number of things done – e.g. x meetings held with communities. Outputs are the tangible results of the major activities in the program (the goods and services produced). They are usually measured by their number – e.g. reports produced, newsletters published, numbers of field days held. Collectively the inputs, activities and outputs define what the program does, and how efficient it is in managing those elements. Outcomes represent the effectiveness of the program – are the desired states of the community, biological system or production sector achieved by the program. Outcomes may be specified in terms of short-term, intermediate and long-term, or just intermediate and long-term. A long-term outcome will usually have a number of intermediate outcomes that together contribute to its ultimate achievement.
The diagram above also shows the supporting information and activities that help the model (and the intended program) to be understood in its wider context. Starting out with outlining a planning and scoping phase helps participants to clearly define the problem or need, and the desired outcome. An ‘issue’ statement should explain briefly the current situation: what needs to change; why is there is a need for intervention; and, what problem/issue does my program aim to solve? This requires that ‘who, what, why, where, when, and how’ are all considered in relation to the problem/issue. Then, the overall purpose of the program needs to be defined. What are you trying to accomplish over the life of the program and beyond? The answer to this question is the solution to the issue statement, and will serve as the program’s vision. The program vision serves as a reference frame for all elements of the logic model that follow. Involving your key stakeholders (see the accompanying resources on stakeholder mapping and analysis) in the process of developing an outcomes model provides an opportunity to engage them in a discussion about the program and to get their input to the process.
The link between a program’s activities and outputs and its desired outcome is based on the assumptions that explicitly, or implicitly, are built into your program theory. Your program theory (or theory of change) sets out why you believe that the successful delivery of the program’s activities and outputs is expected to lead to the desired change (the predicted outcomes). It is important to document the program rationale – the beliefs about how change occurs in your field, based on research, experience, or best practice. This needs to be followed by identifying the corresponding assumptions that are built into the program rationale and to acknowledge and document where uncertainties exist.
A final discussion can help participants to take account of the risks and opportunities facing the program. These can derive from both internal and external factors. Programs that are operating in complex environments cannot control all the factors that will influence how, when or even if they reach their goals. Therefore it is also important to be aware of similar or related external initiatives that will impact on the final outcomes. This is important in terms of attribution – how to ascertain how much impact can be attributed to your program. It also provides the opportunity to look for other initiatives to link and integrate with, to develop useful synergy and maximize the overall influence of the program. Internal factors might relate, for example, to staff and stakeholder capacities.
Three key reasons for using logic models in program design are that they: i) helps you understand why and how something works; ii) provide a guide for implementing useful monitoring and evaluation systems; and iii) help you tell the story of your program quickly and visually. Logic models are most useful when they are developed at the beginning of a program. In this way they can be used to plan how resources can be coordinated and even inspire particular project strategies. They can also at this stage help set realistic expectations for outcomes, bearing in mind that the ultimate desired end-state outcomes of an initiative can often take many years to emerge. Their initial development helps subsequent evaluation as once a program has been described in terms of a logic model, it is then possible to identify meaningful and easily measurable performance indicators. Finally, the simple, clear graphical representation that a logic model provides helps with program communication, and can serve as the basis for expanding the underlying TOC.
Finally ––Some tips for working with logic models
Start with ensuring a common understanding of the current situation and a shared vision: It’s important to know where you are, and where you are trying to get to. These positions will have often been expressed in already published documents, mission statements, etc. The important thing is to ensure that there is some common understanding around the problem and the desired outcomes among all those that you are trying to work with on your journey.
Involve stakeholders: A strong focus on the process of developing a logic or outcomes model (rather than seeing it as just a task to complete) can increase engagement in the program. Building a logic model provides an opportunity, often rare in the everyday provision of services, to involve stakeholders in a discussion on what it is about the planned initiative that is most meaningful to constituents.
Keep the model simple: Concentrate on the most important activities and outcomes, and cut back on detail. Describe your activities and outcomes in language that is understood by a wide range of stakeholders. This lets your logic model provide a common picture of your project that is easily understood. It’s important to get an overview of the model on one page that can be used as a communication aid, and more detail can be added behind it if necessary.
Minimise the use of arrows: In complex situations there are always many links and potential feedback loops between the boxes on the page. It is often enough to indicate the general movement of time and direction of the model.
Avoid siloed thinking: Don’t just include steps and outcomes that are measurable or which you can absolutely prove you changed (attributable to you) – these may not end up being the most important part of the programme. Similarly don’t force lower steps to only contribute or influence a single higher-level step or outcome. Most elements influence a number of things in the real world.
Work constructively with disagreement: Although it might be difficult, keep key stakeholders involved, including staff, program participants, collaborators, or funders. Take time to explore the reasons for disagreement about what should be captured in the logic model. Look for the assumptions, identify and resolve disagreements, and build consensus.
More information: Often people talk about logic models and theory of change processes interchangeably. Logic models typically connect programmatic activities to client or stakeholder outcomes. But a theory of change goes further, specifying how to create a range of conditions that help programmes deliver on the desired outcomes. These can include setting out the right kinds of partnerships, types of forums, particular kinds of technical assistance, and tools and processes that help people operate more collaboratively and be more results focused.
This post provides a short introduction to the language and concepts of Theory of Change or program theory. It looks at how the use of these outcomes-based approaches helps those involved with program learning, planning and evaluation. Subsequent outcomes-based posts look more specifically at developing logic models and working with outcomes.
Community-based change initiatives often have ambitious goals, and so planning specific on-the-ground strategies to those goals is difficult. Likewise, the task of planning and carrying out evaluation research that can inform practice and surface broader lessons for the field in general is a challenge. A Theory of Change approach provides a framework which encourages program staff and stakeholders to develop comprehensive descriptions and illustrations of how and why a desired change is expected to happen in a particular context. It is outcomes-based, and helps those involved to clearly define long-term goals and then map backwards to identify the necessary preconditions that will be required for success.
Theories of change are vital to program success for a number of reasons. Programs need to be grounded in good theory. By developing a theory of change based on good theory, managers can be better assured that their programs are delivering the right activities for the desired outcomes. And by creating a theory of change programs are easier to sustain, bring to scale, and evaluate, since each step – from the ideas behind it, to the outcomes it hopes to provide, to the resources needed – are clearly defined within the theory. Often people talk about logic models and theory of change processes interchangeably, Logic models connect programmatic activities and outputs to client or stakeholder outcomes. But a theory of change goes further, specifying how to create a range of conditions that help programs deliver on the desired outcomes. These can include setting out the right kinds of partnerships, types of forums, particular kinds of technical assistance, and tools and processes that help people operate more collaboratively and be more results focused.
The importance of the concept was well illustrated in a 1995 paper – Nothing as Practical as Good Theory: Exploring Theory-Based Evaluation. In that paper, Carol Weiss, hypothesized that a key reason complex programs are so difficult to evaluate is that the assumptions that inspire them are poorly articulated. She argued that stakeholders of complex community initiatives typically are unclear about how the change process will unfold and therefore place little attention to the early and mid-term changes that need to happen in order for a longer term goal to be reached. The lack of clarity about the ‘mini-steps’ that must be taken to reach a long term outcome not only makes the task of evaluating a complex initiative challenging, but reduces the likelihood that all of the important factors related to the long term goal will be addressed.
Weiss popularized the term ‘Theory of Change’ as a way to describe the set of assumptions that explain both the mini-steps that lead to the long term goal of interest and the connections between program activities and outcomes that occur at each step of the way. She challenged designers of complex community-based initiatives to be specific about the theories of change guiding their work and suggested that doing so would improve their overall evaluation plans and would strengthen their ability to claim credit for outcomes that were predicted in their theory. Over subsequent years a number of evaluations have been developed around this approach, fueling more interest in the field about its value.
A theory of change is usually presented in a visual diagram (or logic model) that allows the reader to see the big picture quickly. It does not usually provide a specific implementation plan. The purpose of the process is to allow people to think about what must be changed before doing it.
Theory of change is both a process and a product (Vogel 2012).
At its simplest, theory of change is a dialogue-based process intended to generate a ‘description of a sequence of events that is expected to lead to a particular desired outcome.’ This description is usually captured in a diagram (or logic model) and narrative to provide a guiding framework of the change model showing how and why the desired goals can be reached by the project team and stakeholders. Acknowledging ToC as a process reminds us that a ToC inquiry is an ongoing process of analysis and reflection. It is not a one-off exercise to design (or evaluate) an initiative, but implies an ongoing learning and adaptive management cycle.
In brief, a theory of change starts by identifying a clear ultimate goal and working backwards to establish preconditions for reaching that goal. At each step any assumptions are examined. The next step is to identify indicators. Only when these steps have been completed are the activities or interventions identified. Finally a narrative is drafted to explain the theory of change in everyday language. As Vogel points out, developing a theory of change requires discussion between the different stakeholders groups of the following elements (in order):
the context for the initiative, including social, political and environmental conditions, the current state of the problem the project is seeking to influence and other actors able to influence change;
the long-term outcomes that the initiative seeks to support and for whose ultimate benefit;
the broad sequence of events anticipated (or required) to lead to the desired long-term outcome;
the assumptions about how these changes might happen, and about contextual drivers that may affect whether the activities and outputs are appropriate for influencing the desired changes in this context;
a diagram (logic model) and narrative summary that represents the sequence and captures the discussion.
The main benefit of theory of change comes from making different views and assumptions about the change process explicit, especially seemingly obvious ones. A good theory of change can specify how to create a range of conditions that help programs deliver on the desired outcomes. These can include setting out the right kinds of partnerships, types of forums, particular kinds of technical assistance, and tools and processes that help people operate more collaboratively and be more results focused. The purpose of doing so is to help program staff and stakeholders to check that programs are appropriate, debate them and enrich them to strengthen project design and implementation. For this reason, theory of change as a process emphasizes the importance of dialogue with stakeholders, acknowledging multiple viewpoints and recognition of power relations, as well as political, social and environmental realities in the context.