Problem Solving – Building State Capability

Can PDIA become a regular part of how a government works?

Guest blog written by Peter Harrington

Recently I have been engaging with a government in a middle-income country which is using PDIA methods to tackle some of their thorniest public problems. As one would expect there have been successes and failures, and lots of learning. But in addition to this, leaders in the government want to ‘embed’ PDIA permanently into the way their government works. This raises some interesting questions for PDIA – can the methodology be institutionalised as part of the way a government works? If so, what does this look like? And what is required to make that successful and sustainable?

The government has decided that it wants to embrace more innovative methods of getting things done, and governments through the ages have had similar ambitions. There has been a recognition that existing ways of working leave some problems unsolved, and a good place to start is to understand why this might be.

Governments by their nature function in routines. These are established pathways which, to a greater or lesser degree depending on the government’s capability, serve a range of functions in maintaining the operations of the state. These functions are well established but can also change, adapting to new conditions and new social or economic needs through shifts in policy, legislation, new services and new ways of working. As such governments can be understood as complex adaptive eco-systems which are themselves embedded in and interacting with a larger complex adaptive system: wider society.

As functioning (or dysfunctioning) systems, governments get an awful lot of things done. To borrow an analogy used by Matt Andrews, the amount of coordination it takes to make a streetlight switch on at a specific time each day is actually quite extraordinary. But as systems whose configuration is a response to and reflection of their societal context, governments are by their nature unable to solve every problem through their regular operation. Some problems are complex, and/or emergent, and require different types of know-how to solve. Some of these problems may arise directly because the machine of the state is configured in such a way as to neglect, exacerbate or even cause that particular issue. Think of a robot vacuum cleaner: they are pretty smart these days, programmed to trundle around your house hoovering the floor space and capturing a lot of dirt. When it’s done the floor looks pretty clean, but anyone with a Roomba knows that it can’t catch dirt gathering in the hard to reach corners, and it may have even pushed extra dirt into some of those corners. Getting into those nooks and crannies requires something different – probably a human, using a different tool.

The DDD Manifesto finds a new home

written by Salimah Samji

Since we published The DDD Manifesto on November 21, it has been viewed over 5,000 times all around the world (in 100+ countries). It currently has over 400 signatories from 60 countries. It is an eclectic community with people from bilateral organizations, multilaterals, governments, academia, NGOs, private sector, as well as independent development practitioners. These are the founding members of The DDD Manifesto Community.

Today, we are delighted to launch the online platform of the DDD Manifesto Community which is the new home of the manifesto. We hope that this will be a place where you can come to share ideas, have conversations, question your assumptions, learn from others, offer support and be inspired. It includes a forum for discussion, blog posts written by community members and features video presentations from the recent DDD workshop (#differentdev).

To sign the manifesto and to participate in the forum, you can register here. Please contribute actively – this is a community website and you are the community.

If you want to Do Development Differently but it sounds too hard…

written by Matt Andrews

Arnaldo Pellini recently wrote an interesting personal blog post about the Doing Development Differently workshop and manifesto. He concludes with, “I agree with these ideas and I can share and discuss these ideas with the team with whom I work but what difference can it make if the systems around us due to organizational culture, history, circumstances, and traditions struggle to embrace flexibility, uncertainty, untested experimentation, and slow incremental changes?”

This is an honest reflection from a practitioner in the field; and one that I hear often–from folks working in multilateral and bilateral agencies, as contractors, and beyond. It captures a concern that the development machinery (organizations, monitoring and reporting devices, profession-alliances, government counterparts, etc.) is structurally opposed to doing the kind of work one might call DDD or PDIA.

It’s like this cartoon…where our organizations say “let’s innovate but stay the same.”

I have been thinking about this a lot in the last few years, ever since I wrote chapter ten of my book…which asked whether the development community was capable of changing. In that chapter I was not especially confident but (I hope) I was still hopeful.

Since then, I think I’m more hopeful. Partly because,

we have found many folks in the multilaterals, bilaterals, contractors etc. who are doing development in this more flexible way. We invited a range of them to the DDD Workshop and over 330 signed on to the DDD Manifesto. One of the goals of our work in the next while is to learn from these folks about HOW they do development differently even with the constraints they face. How do they get funders to embrace uncertainty? How do they get ministers in-country to buy-into flexibility and give up on straight isomorphism?
I am also working on research projects that tackle this question; doing PDIA in real time, in places where development is predominantly done through the incumbent mechanisms. It is hard work, but I am finding various strategies to get buy-in to a new approach (including showing how problematic the old approach is, by working in the hardest areas where one has a counterfactual of failed past attempts, and more). I am also finding strategies to keep the process alive and buy more and more space for flexibility (by iterating tightly at first, for instance, and showing quick wins…and telling the story of learning and of increased engagement and empowerment). So far, I have not experienced complete success with what I have done, but I have certainly not struggled in getting support from the practitioners and authorisers we work with. (In my world it is harder to get support from academics, who think action research on implementation is a hobby and consultancy work… indeed, anything that does not say ‘RCT’ is considered less than academic. Sigh.)

All this is to say that I think Arnaldo is emphasizing a really important constraint on those working in development agencies. But a constraint that we should work through if we really do agree that these more problem driven, flexible approaches are what is needed. To Arnaldo and others I would suggest the following:

Separate the conversation about which way we should do development from the conversation about how much our organizational realities ALLOW us to do it. The first conversation is: “Should we do DDD/PDIA?” The second conversation is: “How do we DDD/PDIA?” If we conflate the conversations we never move ahead. If we separate them then we can develop strategies to gradually introduce PDIA/DDD into what we do (in essence, I’m suggesting doing PDIA ourselves, to help change the way we do development…see an earlier blog).
I also constantly remind myself that we (external folks in development organizations) are not the only ones facing a challenge of doing new stuff in existing contexts–with all the constraints of such. This is what we are asking of our counterparts and colleagues in the developing countries where we work. Dramatic and uncomfortable and impossible change is in the air every time we are introducing and facilitating and supporting and sponsoring work in developing countries. I always tell myself: “If we can’t work it out in our own organizations–when we think that our own organizational missions depend on such change–then we have no place asking folks in developing countries to work it out.”
So, it’s a challenge. But a worthy one. And if we care about doing development with impact, I think it behooves us to face up to this challenge.

Good luck, Arnaldo, thanks for your honesty and for the obvious commitment that causes you to share your reality. It is really appreciated!

The PDIA Anthem

Need help decoding the acronym PDIA? Check out the PDIA anthem.

This Anthem uses the Instrumental from Mos Def – Mathematics. It was made by a very talented student as part of an assignment for Matt Andrews course entitled Getting Things Done in Development. We had never imagined that we could write a song about PDIA, let alone a rap. Thank you.

Let me hear you say P. D. I. A. …

Introducing The DDD Manifesto

We are delighted to release The DDD Manifesto as an outcome of the 2014 Doing Development Differently (DDD) workshop.

In late October, a group of about 40 development professionals, implementers and funders from around the world attended the DDD workshop, to share examples where real change has been achieved. These examples employ different tools but generally hold to some of the same core principles: being problem driven, iterative with lots of learning, and engaging teams and coalitions, often producing hybrid solutions that are ‘fit to context’ and politically smart.

The two-day workshop was an opportunity to share practical lessons and insights, country experience, and to experiment first hand with selected methodologies and design thinking. In order to maximize the opportunity to hear from as many people as possible, all presenters were asked to prepare a 7:30 minute talk — with no powerpoints or visual accompaniments. The workshop alone generated a rich set of cases and examples of what doing development differently looks like, available on both Harvard and ODI websites (where you can watch individual talks, see the posters or link to related reports).

The aim of the event was to build a shared community of practice, and to crystallize what we are learning about doing development differently from practical experience. The workshop ended with a strong call for developing a manifesto reflecting the common principles that cut across the cases that were presented. Watch the closing remarks here.

These common principles have been synthesized into The DDD Manifesto. We recognize that many of these principles are not new, but we do feel the need to clearly identify principles and to state that we believe that development initiatives will have more impact if these are followed.

As an emerging community of practice, we welcome you to join us by adding your name in the comment box of the manifesto.

Contexts and Policy Implementation: 4 factors to think about

written by Matt Andrews

I recently blogged about what matters about the context. Here’s a video of a class I taught on the topic at the University of Cape Town over the summer (their winter). It is a short clip where I try to flesh out the 4 factors that I look at when thinking about new policy: 1. Disruption; 2. Strength of incumbents; 3. Legitimacy of alternatives; and 4. Agent alignment (who is behind change and who is not).

How can we learn when we don’t understand the problem?

written by Salimah Samji

Most development practitioners think that they are working on problems. However, what they often mean by the word ‘problem’ is the ‘lack of a solution’. This leads to designing typical, business as usual interventions, without addressing the actual problem. Essentially, they sell solutions to specific problems they have identified and prioritized instead of solving real and distinct problems.

If the problem identification is flawed, then it does not matter whether you do a gold standard RCT or not, you will neither solve the problem nor learn about what works. Here’s a great example. A recent paper entitled, The permanent input hypothesis: the case of textbooks and (no) student learning in Sierra Leone found that a public program providing textbooks to primary schools had no impact on student performance because the majority of books were stored rather than distributed.

Could they not have learned that the textbooks were being locked up, cheaper and faster, through some routine monitoring or audit process (which could have led to understanding why they were locked up and then perhaps trying to find other ways to improve access to the textbooks – assuming that was their goal)? Was an RCT really necessary? More importantly, what was the problem they were trying to solve? What was their causal model or theory of change? If you provide textbooks to children then learning outcomes will improve?

Interestingly, the context section of the paper mentions that “the civil war severely impacted the country’s education system leading to large-scale devastation of school infrastructure, severe shortages of teachers and teaching materials, overcrowding in many classrooms in safer areas, displacement of teachers, frequent disruptions of schooling, psychological trauma among children, poor learning outcomes, weakened institutional capacity to manage the system, and a serious lack of information and data to plan service provision.” In addition, they also found variance between regions and in one remote council, “less than 50 percent of all schools were considered to be in good condition, with almost 20 percent falling under the category “no roof, walls are heavily damaged, needs complete rehabilitation.”

Honestly, in a complex context like this, it isn’t clear or obvious that providing textbooks would make much difference even if they were handed out to the children, especially since they are written in English. Apparently, the teachers teach in Krio in the early years and then switch to English in Grade 4 and 5. Based on the context above, that sounds more like fiction than fact.

In environments like these, real problems are complex and scary, and it is easier to ignore them than to address them. A possible way forward could be to break the problem down into smaller more manageable pieces using tools like problem trees, the ishikawa diagram and the ‘5 whys.’ Then design an intervention, try, learn, iterate and adapt.

For more watch BSC video deconstructing sticky problems and problem driven sequencing.

Hirschman’s Hiding Hand and Problem Driven Change

written by Matt Andrews

I referred to Albert Hirschman’s work on the “Principle of the Hiding Hand” in my class today. It is a great principle, and has real application when thinking about PDIA and problem driven change.

In his essay, “The Principle of the Hiding Hand” Hirschman argues that creative solutions most frequently come from adapting to tasks that turn out to be more challenging than we expect.

In Hirschman’s words, “men engage successfully in problem-solving [when] they take up problems which they think they can solve, find them more difficult than expected, but then, being stuck with them, attack willy-nilly the unsuspected difficulties – and sometimes even succeed.”

It’s really beautiful, because it takes as a given some facts that we often think stand in the way of doing flexible, PDIA-type development. Hirschman expects that decision makers will tackle problems, often adopt solutions that look attractive but are hard to pull off (perhaps like big best practice type initiatives), and will overestimate the potential results.

He argues that they wouldn’t try to do the challenging things that development demands if they didn’t think this way. So, he advises to ‘go with it’ …. but then wait for the unexpected… in the form of complexities, constraints, hidden difficulties, etc.

When these unforseen difficulties emerge, Hirschman argues, we have the opportunity to become creative–and to iterate and experiment and find and fit ways to solve the problems that initiated the work in the first place … building on the sunk costs already incurred in pursuing the big, best practice, perfect solution. (saying something like “we’ve come so far…let’s now iterate to ensure we actually solve the problem we set out to solve.”)

Beautiful: Start where you are, focus on solving problems, try the big best practice (but hard to actually do) solution, and become creative when you hit the challenges…

What he assumes is that you have space for flexible change and PDIA-type innovation because of the sunk costs associated with past (or current) reform. An interesting assumption, that I think we can look at academically and reflect on practically.

Required and fundamentally vital reading for anyone in development.