February 11, 2016

The theory behind theories of change

This essay will look at the theory behind theories of change. First of all it is a quick introduction to my forthcoming book provisionally entitled A Vocabulary for Evaluation. Secondly it explains the motivation behind the kind of graphics produced by an accompanying web app called QuickToC - a web app for making Theory of Change diagrams.

While this essay can serve as a resource for someone using QuickToC, it should make sense even to readers who are not interested in the web app. All the diagrams in this essay were produced with QuickToC.

QuickToC is a simple, free web app for making diagrams of theories of change, logframes, etc. It is open source so you can even install it on your own computer for free if you want. Its special feature is that users can also create boxes to group the variables, for example to mark off different phases, regions or stakeholders. There is more info about the app itself and how to use it on my blog and there are some examples included in the app itself. Comments, suggestions, bug reports are welcome here.

The basic building block of theories of change

Theory of Change diagrams are a kind of directed graph. The basic unit looks like this:

The state of the child variable is influenced, if not completely determined, by the states of one or more parent variables. Mathematicians would say that the state of the child variable is some function of the states of the parent variable(s). But here we mean function” in a very general and possibly vague way. There is no reason to expect that the variables are numerical (though they might be) or that the function is exact. All we mean is that there is some kind of rule which tells us how the child variable is influenced by the parent variables. The rule can take any imaginable form - for example:

  • all the variables are true/false variables and the child variable is only true if all the parent variables are true …
  • or value of the child variable stays very low until the value of the parent variable reaches a certain tipping point, beyond which the value of the child variable soars …
  • and so on.

In particular, there is no reason at all to expect that the child variable is influenced by the parent variable(s) in any kind of linear way. While linear relationships are convenient for mathematicians, they are the exception rather than the rule in the natural and social world.

So if you look at this basic model and think:

Gosh, that looks very mechanistic!

… I can assure that it is only mechanistic in the loosest of all possible senses, loose enough to cover just about any kind of idea about how things in the world influence other things.

For example, anyone can see that the following model is probably true, even before we worry about exactly what kind of variables these are, if they can be expressed in terms of numbers, or what shape the function might have. It might well be that the link between parent and child variables is complex, or chaotic, or emergent, or even worse … but if the states of the parent variables give us sometimes, potentially, some information about the state of the child variables, our thinking can still be expressed in terms of this basic model.

Many have argued that this kind of simple model drives the way we understand, predict, explain and try to control the world around us.

In particular, and this is absolutely central to project and programme evaluators, within this basic model we can get a good understanding of the contribution which one parent variable makes - in the context of any other parent variables - to a child variable. Contribution is the defining question of evaluation: how much does our project intervention contribute to changes we desire?

If we can understand contribution in the context of one simple building block, and then we can show how to build up more complex theories using these blocks, we should be able to understand contribution within these more complex theories too.

There are many other interesting templates for building up explanations of how the world changes and how we can intervene, from system dynamics to chaos theory. But I believe any theory expressed with any of these alternative models can also be expressed using the kind of basic building block we deal with here: a single-step functional model linking parent and child variables. I discuss this claim in more detail in my book.

Building a theory of change

From the point of view of someone designing, managing or evaluating a project, this basic building block is quite familiar, and we see it everywhere in project plans such as logical frameworks. Its benefits are obvious: we can show what needs to happen in order to achieve a certain outcome. By linking these units up, we can continue back up the chain: in order to achieve that, this needs to happen … and so on, back to something we can actually control. We end up with a composite theory of how some desired change can come about.

Showing the joins

QuickToC (like many other tools) helps us to draw these kinds of theories. In particular, QuickToC gives you a place called a join where arrows join up to variables where you can indicate the function: how exactly the parent variables influence the child variable. You probably won’t want to describe the function in detail in that little box, but at least you can indicate that it needs discussing.

Restricted rules

But with typical planning toolkits like the Logical Framework Approach, it is not the case that anything goes. Instead, they usually have various ways of restricting the kind of model you can build.

Traditional hierarchical models may look something like this.

These kinds of models have a long list of restrictions. We will list these restrictions here and later we will see what happens when we break them…

There is a strict set of levels” defined by the number of steps away from the beginning and end of the tree.

  • Each level has a special name like Results” or Outcomes”.
  • Each variable:
    • belongs to exactly one layer,
    • has two or more parents (occasionally, just one parent) which are all in the preceding layer (apart from the first layer, e.g. inputs”).
    • and has exactly one child in the following layer (apart from the last layer, e.g. goal”).
  • There is only one variable in the final layer, e.g. goal”.

None of these restrictions are necessary to validly explain how change might come about. No-one really knows why they are so pervasive. Perhaps they are administratively convenient. But every time you have to twist your actual understanding of how change comes about to fit one of these patterns, you are turning a (hopefully) correct theory into an incorrect one.

Paul Duggan discusses similar issues on his blog.

Nevertheless, QuickToC makes it easy to construct these kinds of patterns - look at the first few examples on QuickToC.info, perhaps using the kind of decimal point notation (A, A.1, A.1.1 etc) common in these restricted designs.

Boxes - why we need them

To be continued!

February 8, 2016

QuickToC - sketch out your Theory of Change in a few seconds

QuickToC is a free and simple web app for making diagrams of theories of change, logframes, etc. Its special feature is that you can also create boxes to group the pieces of your network, for example to mark off different phases, regions or stakeholders.

First, do us a favour by clicking here: tell your followers about quicktoc!

You make the diagrams just by typing the names of the elements in a structured way into a (resizeable) window, and you get a live diagram as output which reflects what you type. You can save the diagram as a graphics file or just copy and paste it into any document, but don’t forget to copy and paste the text somewhere too because it won’t be there next time you visit the site.

Get this …

Just by typing this …

-Phase 1



What QuickToC provides

Quick and easy …

This site tries to make it easy to make a diagram using only text typed according to really simple rules.

… theories of change

There are plenty of toolkits for making various kinds of network graphs and UML diagrams. Some are offline, some are online, for example plantuml. But QuickToC is optimised for, as the name says, theories of change, logframes, etc.

… including boxes

Its special feature is that you can also create boxes to group the pieces of your network, for example to mark off different phases, regions or stakeholders. So in addition to the graph itself, you can show hierarchical grouping of nodes using nested boxes. This is particularly useful in the field of project monitoring and evaluation, in which it is often necessary, alongside the causal flow between project variables which can be captured with a normal directed graph, to show other non-causal but possibly hierarchical grouping of variables e.g. project phase, geographical distribution etc.

What it doesn’t do

No control over layout

It doesn’t give you much control over the actual layout (like whether something appears at the top or bottom). This tool tries to keep the layout simple, but that doesn’t necessarily mean things are where you want them. Don’t bother trying to get the nodes and boxes to move about: If you want to tweak a diagram further, you can download the .svg version of it and manipulate it further in Inkscape, Libreoffice Draw or Illustrator.

Remember to save your text

There is no registration or log-in. You just type text. Don’t forget to copy and paste the text you typed somewhere too because it won’t be there next time you visit the site.

Anyone want to help me make this into a plugin for MS Word? Enter the text, press a button, get the graphic inserted below?

r software quicktoc evaluation mande
February 8, 2016

The grammar of QuickToC

Every line is either blank or defines a variable or a box.

Define a variable

Just type characters:

my variable

Defining edges between variables


You can use dots at the beginning of a line to define a link from a to b:




You can use spaces at the beginning of a line to define a link from b to a:




You can use a decimal notation common in logframes etc:






Or, most generally, you can use this to= notation to construct an edge to another node:

a; to=b

You can give more than one target by listing more than one variable, separated by spaces. Note that case is important, so to=A is not the same as to=a

a; to=b c

So the names of the targets have to be without spaces:

my variable another variable; to=myvariable

Using aliases

If you are using to= and you have have long variable labels it can be tedious to have to retype them. So you can give the target variable a simpler alias by adding characters before a colon. The second part is shown as the label, but the first (simpler) part can be used to refer to the variable elsewhere

a::my variable
b; to=a

Allowed characters

You can use ( ) ! ? . , in the names of your variables. Don’t use " = + ; or '. If you are using to=, remove anything except letters and numbers from the name of the target.

Implied variables

If you imply a variable using the to= or decimal methods without actually defining it, like c in the example below, the variable will be shown in grey.

b; to=c


Boxes are used to group variables. A box is introduced by a box definition: a line starting with one or more dashes: -. What comes after will be printed as the label of the box. Boxes with more dashes will be printed a bit smaller.

--My big box

Boxes with more dashes are shown inside boxes with fewer dashes.

You can finish off” one box without starting another by typing a line with the same number of dashes but no text.

Variables following a box definition are shown inside the box.

The edges between variables are not affected by boxes, though the layout may change a little.

That is it. The rest is decoration.


Variables, edges, boxes and indeed the diagram itself can be decorated by adding little phrases of the form attribute=value, separated by semicolons, like this:

my variable; fillcolor=orange

(to be completed)


The diagrams are intended to represent causal networks, i.e. a set of causal connections between variables. So if one or more variables point to another, they are to be understood as influencing the variable at the receiving end of the arrows. It is possible to make cyclic diagrams, in which you can trace a path from a variable down the arrows back to the same variable. We usually think of these as feedback loops”. The interpretation of cyclic diagrams is not quite so easy, which is one reason why they are traditionally discouraged in project modelling; usually we have to think of the variables as representing the same thing at different times.

The basic premise is that it causal networks are a good way to model projects and programmes. This is great because there is a big and growing literature about causal networks, so if and when we need to think more formally about projects and issues like adaptability, chaos, complexity, contribution and attribution, we can base it on this powerful new science. This is what I am attempting to do in my forthcoming book.

Interpretation of boxes

The whole point about boxes is that we don’t really interpret them. They are for when you want to group variables in some way - phase 1, phase 2, variables concerning children, variables concerning parents, inputs, outputs, etc, without any causal interpretation.

One of the big problems with logical frameworks etc is that they don’t have boxes: they don’t have a way of grouping or organising variables which do not imply a causal connection. So we end up having to create, for example, pseudo goal” variables as a way of grouping or listing or organising outcomes even when the goal” is not really a causally separate variable and the outcomes do not really causally influence it.

Unlike with other, purer ways to draw graphs like plantUML and Graphviz itself, the edges between variables do not get their own lines. Instead, you define them when you define your variables. For convenience, there are four different ways to do this, which are all basically the same.


A QuickToC diagram consists firstly of variables, which may be linked to one another with directed edges, i.e. lines which usually have arrowheads. So formally, a diagram is a directed graph. Secondly, there are boxes, which may contain variables and which may be nested inside one another. A diagram may contain variables (and maybe edges) and/or boxes.

Variables, edges and boxes may also be decorated in various ways, for example edges may have labels and variables may have special colours. Also the whole diagram may have a title and possibly a legend.


This blog by Steve Powell is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License and powered by Blot.
Privacy Policy