Putting logic back into program logic
Are the programs logics that you see actually logical?
On Wednesday 11 April 2018, ARTD Partner Andrew Hawkins, delivered a free seminar in Sydney organised by the Australasian Evaluation Society (AES), which was attended by approximately 50 people.
Hawkins first briefly introduced his subject. His generalist definition of a program logic is “A one-page diagram or model of the important components of an intervention and how they work together to deliver outcomes.”
He then gave attendees three example program logics to use as references in their discussions of two key questions.
Question 1: What makes program logics logical?
- They represent a narrative or ‘plausible story’.
- There is an expectation that activities in a program logic will lead to particular outcomes.
- They are not business plans and, due to limited space, do not map out every potential input, activity, outcome, etc.
- They should be meaningful to various stakeholders.
- They represent a thoughtful process or ‘journey’ describing how an organisation can go from Point A to Point Z, and any anywhere in between.
- Different program logic formats, styles and colours may appeal to some but not to others (however, whichever styles are selected should be used thoughtfully).
- Being aware of when to use a particular agency or organisation’s accepted template format so that the organisation itself can more easily understand the program logic.
- Trying to be too logical in a program logic can actually hamper innovation.
Question 2: What do the arrows mean in a program logic?
- They lead to or influence a particular activity or outcome.
- Sometimes they seem to mean here’s “Where the magic happens” rather than a logical link.
- They are assumptions about what needs to occur to allow an organisation to go from Point A to Point B.
- They provide direction around expectations and what has to happen in an organisation.
- They can indicate where an evidence base justifies a connection.
- They represent sign-posts for the reader showing where the story starts and where one must look to next.
Later, Hawkins gave an overview of his own approach to program logic. He argued that a ‘configurationalist’ understanding of causality would be more useful than the ‘successonist’ understanding deployed in many program logics. His point was that effective programs are better thought of as a ‘causal package’ with certain assumptions, like a recipe, rather than a linear ‘causal chain’ where one element in the program logic causes the next one.
Hawkins believes a program is better thought of as a proposition or argument that a course of action will be sufficient to bring about a desired result, rather than a theory about change or a theory about action. He said that while theory was very important for providing reasons, justifications or ‘warrants’ for elements of the program design (and for the program as a whole), he thinks it is too much for a program logic diagram to display this theory.
Instead, he proposed focusing on the conditions that program activities needed to achieve that, together, would be enough to enable an intended outcome to be achieved. He argued that this approach enables critical thinking (that can support realistic design) and evaluations focused on measuring outcomes a program is sufficient for achieving its objectives. It can also support the program’s argument or business case.
