PDIA and Authorizers with an itch

written by Matt Andrews

“How do you decide where to work on a PDIA project?”  This is probably the most common question I have been asked with respect to PDIA.

After over 5 years of doing this work in a variety of countries and sectors, I have a simple answer: “When we find authorizers with an itch.”

“That sounds bizarre,” I hear you say. Or maybe you think I’m just being cute to fit in with a playful blogging technique.

No, authorizers with an itch are key to starting any PDIA initiative.

When I say we need counterparts with an itch, I mean that they are very aware of a problem they can’t solve. Like an itch you can’t scratch, or that you scratch again and again but to no avail. This is usually a policy problem that has come to the surface one too many times, usually where various prior reforms or policies or interventions have not provided effective solutions.

Stubborn itches create frustration and even desperation, which can create the space for doing things differently—and taking risks. PDIA needs this kind of space, and this motivating influence. Without it, we have found very little room to focus on the problem, and learn-by-doing towards a new solution.

There are downsides of working to scratch a stubborn itch. The fact that others have tried scratching it, to no avail, means that it is usually going to be ‘wicked hard’ to solve (so don’t expect an easy path to a solution). The fact that it seems to move around (sometimes itching here and sometimes there) reflects the many unseen and even dynamic factors that cause the itch itself (like nasty politics or bureaucratic dysfunction). Don’t expect these factors to go away just because you are tackling the problem with PDIA. You will hit the nastiness soon. Be ready.

When I say we need ‘authorizers’ to start, it is because the PDIA work we do is always in the public domain, where no real work (with action attached) is done without someone’s explicit authorization. The required authorizer is always, in my experience, someone inside the context undergoing change. This means the work cannot be ordered or organized or identified by an external agent (donor, consultant, or even academic).

My team at Harvard found this out the hard way. As you will read in a forthcoming working paper by Stuart Russell, Peter Harrington and I, we have experimented with PDIA initiatives where problems are identified in different ways.  We have had limited success whenever anyone from Harvard or an external entity (like a donor) has been a main identifier of the problem. In contrast, we have almost always had some success when the problem was identified by a domestic authorizer in the place undergoing change.

This is simply because the internal authorizer needs to have internal authority: at the least, to convene a group of internal people to start engaging with the problem, and beyond this to protect the PDIA process from threats and distractions. No external party can do this.

Beyond convening authority, we find that the authorizers need to provide three types of authorization: shareable authorization (where they allow the engagement of other authorizers in the process of scratching the itch), flexible authorization (which allows for an experimental process), and patient (or grit) authorization (where one can expect some continued support in the search for an effective ‘scratch’ solution).

These are big authorization needs, and one does not know if they will be met at the start of the PDIA process. But they tend to come when authorizers face an itch (making them willing to share, adaptive in demands, and patient for a real solution).

We find, therefore, that there is enough space to initiate a PDIA initiative if we find an authorizer with an itch she cannot scratch.  That’s where we start our work, buckling our seat belts and getting ready for a journey of, and to the unexpected.

Are you in a situation where an authorizer is facing a stubborn itch? Maybe you have space to ask, “What’s the problem…and can we mobilize a team to try something different to solve it?”

Learn more about engaging authorizers around problems that matter in chapters 6 and 9 of our free book, Building State Capability: Evidence, Analysis, Action.

 

PDIA Notes 2: Learning to Learn

written by Peter Harrington

After over two years of working with the government of Albania, and as we embark on a new project to work with the government of Sri Lanka, we at the Building State Capability program (BSC) have been learning a lot about doing PDIA in practice.

Lessons have been big and small, practical and theoretical – an emerging body of observations and experience that is constantly informing our work. Amongst other things, we are finding that teams are proving an effective vehicle for tackling problems. We have found that a lot of structure and regular, tight loops of iteration are helping teams reflect and learn. We have found that it is vital to engage with several levels of the bureaucracy at the same time to ensure a stable authorising space for new things to happen. This all amounts to a sort of ‘thick engagement’, where little-and-often type interaction, woven in at many levels, bears more fruit than big set-piece interventions.

Each of these lessons are deserving of deeper exploration in their own right, and we will do so in subsequent posts. For now, I want to draw out some reflections about the real goal of our work, and our theory of change.

In the capacity-building arena, the latest wisdom holds that the best learning comes from doing. We think this is right. Capacity building models that rely purely on workshop or classroom settings and interactions are less effective in creating new know-how than interventions that work alongside officials on real projects, allowing them to learn by working on the job. Many organisations working in the development space now explicitly incorporate this into their methodology, and in so doing promise to ensure delivery of something important alongside the capacity building (think of external organizations that offer assistance in delivery, often by placing advisers into government departments, and promise to ensure a certain goal is achieved and the government capacity to deliver is also enhanced).

It sounds like a win-win (building capabilities while achieving delivery). The problem is that, in practice, when the implementers in the governments inevitably wobble, or get distracted, or pulled off the project by an unsupportive boss (or whatever happens to undermine the process, as has probably happened many times before), the external advisors end up intervening to get the thing done, because that’s what was promised, what the funder often cares more about, and what is measurable.

When that happens, the learning stops. And the idea of learning by doing stops, because the rescue work by external actors signalled that learning by doing—and failing, at least partially, in the process—was at best a secondary objective (and maybe not even a serious one). Think about anything you have ever learned in your life – whether at school or as an adult. If you knew someone was standing by to catch a dropped ball, or in practice was doing most of the legwork, would you have really learned anything? For the institutions where we work, although the deliverable may have been delivered, when the engagement expires, nothing will have changed in the way the institution works in the long run. This applies equally, by the way, to any institution or learning process, anywhere in the world.

The riddle here is this: what really makes things change and improve in an institution, such that delivery is enhanced and capability to deliver is strengthened? The answer is complex, but it boils down to people in the context doing things differently – being empowered to find out what different is and actually pursue it themselves.

In pursuing this answer, we regularly deploy the concept of ‘positive deviance’ in our work: successful behaviors or strategies enabling people to find better solutions to a problem than their peers, despite facing similar challenges and having no extra resources or knowledge than their peers. Such people are everywhere, sometimes succeeding, and depending on the conditions sometimes failing, to change the way things work – either through their own force of will, or by modelling something different. Methods to find and empower positive deviants within a community have existed for many years. But what if, by cultivating a habit of self-directed work and problem solving, it was possible to not just discover positive deviants but create new ones?

Doing things differently stems from thinking differently, and you only think differently when you learn – it’s more or less the definition of learning. Looked at this way, learning becomes the sine qua non of institutional change. It may not be sufficient on its own – structures, systems and processes still matter – but without a change in paradigm among a critical mass of deviants, those other things (which are the stuff of more traditional interventions) will always teeter on the brink of isomorphism.

We believe that positive deviance comes from learning, especially learning in a self-directed way, and learning about things that matter to the people doing them. If you can catalyse this kind of learning in individuals, you create a different kind of agency for change. If you can go beyond this and catalyse this kind of learnings in groups of individuals within an institution or set of institutions, and create a sufficiently strong holding space for their positive deviance to fertilise and affect others, then gradually whole systems can change. In fact, I’d be surprised if there’s any other way that it happens. As Margaret Mead put it, “Never doubt that a small group of thoughtful, committed, citizens can change the world. Indeed, it is the only thing that ever has.”

This is our theory of change. The methods we use – particularly the structured 6-month intensive learning and action workshop we call Launchpad – are trying above all to accelerate this learning by creating a safe space in which to experiment, teach ideas and methods that disrupt the status quo, and create new team dynamics and work habits among bureaucrats. By working with senior and political leaders at the same time, we are trying to foster different management habits, to help prevent positive deviance being stamped out. In doing all this, the goal is to cultivate individuals, teams, departments and ultimately institutions that have a habit of learning – which is what equips them to adapt and solve their own problems.

This does not mean that the model is necessarily better at achieving project delivery than other methods out there, although so far it has been effective at that too. The difference is that we are willing to let individuals or even teams fail to deliver, because it is critical for the learning, and without learning there is no change in the long term. Doing this is sometimes frustrating and costly, and certainly requires us gritting our teeth and not intervening, but what we see so often is agents and groups of agents working their way out of tricky situations with better ideas and performance than when they went in. They are more empowered and capable to provide the agency needed for their countries’ development. This is the goal, and it can be achieved.

 

 

PDIA: It doesn’t matter what you call it, it matters that you do it

written by Matt Andrews

It is nearly two years since we at the Building State Capability (BSC) program combined with various other groups across the developing world to create an umbrella movement called Doing Development Differently (DDD). The new acronym was meant to provide a convening body for all those entities and people trying to use new methods to achieve development’s goals. We were part of this group with our own approach, which many know as Problem Driven Iterative Adaptation (PDIA). 

Interestingly, a few of the DDD folks thought we should change this acronym and call PDIA something fresher, cooler, and more interesting; it was too clunky, they said, to ever really catch on, and needed to be called something like ‘agile’ or ‘lean’ (to borrow from approaches we see as influential cousins in the private domain).

The DDD movement has grown quite a bit in the last few years, with many donor organizations embracing the acronym in its work, and some even advocating for doing PDIA in their projects and interventions. A number of aid organizations and development consultancies have developed other, fresher terms to represent their approaches to DDD as well; the most common word we see now is ‘adaptive’, with various organizations creating ‘adaptive’ units or drawing up processes for doing ‘adaptive’ work.

‘Adaptive programming’ certainly rolls off the tongue easier than ‘Problem Driven Iterative Adaptation’!

Some have asked me why we don’t change our approach to call it Adaptive as well, others have asked where we have been while all the discussions about names and titles and acronyms have been going on, and while organizations in the aid world have been developing proposals for adaptive projects and the like (some of which are now turned into large tenders for consulting opportunities).  My answer is simple: I’ve made peace with the fact that we are much more interested in trying to work out how to do this work in the places it is needed the most (in implementing entities within governments that struggle to get stuff done). 

So, we have been working out how to do our PDIA work (where the acronym really reflects what we believe—that complex issues in development can only be addressed through problem driven, iterative, and adaptive processes). Our observation, from taking an action research approach to over twenty policy and reform engagements, a light-touch teaching intervention with over 40 government officials, an online teaching program, and more, is clear: the people we work with (and who actually do the work) in governments don’t really care for the catchy name or acronym, or if PDIA is clunky or novel or old and mainstream. The people we are working with are simply interested in finding help: to empower their organizations by building real capability through the successful achievement of results.

We thus seldom even talk about PDIA, or adaptive programming, or DDD, or agile or lean, or whatever else we talk about in our classrooms and seminar venues back at Harvard (and in many of our blog posts and tweets). Indeed, we find that a key dimension of this work—that makes it work—is not being flashy and cool and cutting edge. It’s about being real and applied, and organic, and relational. And actually quite nodescript and mundane; even boringly focused on helping people do the everyday things that have eluded them.

So, PDIA’s lack of ‘flash’ and ‘coolness’ may be its greatest asset (and one we never knew about), because it does not matter what PDIA is called…what matters is whether it is being done.

PDIA Notes 1: How we have PDIA’d PDIA in the last five years

written by Matt Andrews, co-Founding Faculty of the Building State Capability Program

We at the Building State Capability (BSC) program have been working on PDIA experiments for five years now. These experiments have been designed to help us learn how to facilitate problem driven, iterative and adaptive work. We have learned a lot from them, and will be sharing our lessons—some happy, some frustrating, some still so nuanced and ambiguous that we need more learning, and some clear— through a series of blog posts.

Before we share, however, I wanted to clarify some basic information about who we are and what we do, and especially what our work involves. Let me do this by describing what our experiments look like, starting with listing the characteristics that each experiment shares:

  • We have used the PDIA principles in all cases (engaging local authorizers to nominate their own problems for attention, and their own teams, and then working on solving the problems through tight iterations and with lots of feedback).
  • We work with and through teams of individuals who reside in the context and who are responsible for addressing the problems being targeted. These people are the ones who do the hard work, and who do the learning, and who get the credit for whatever comes out of the process.
  • We work with government teams only, given our focus on building capable states. (We do not believe that one can always replace failed or failing administrative and political bodies with private or non profit contractors or operators. Rather, one should address the cause of failure and build capability where it does not exist).
  • We believe in building capability through experiential learning and the failure and success such brings (choosing to institutionalize solutions only after lessons have been learned about what works and why, instead of institutionalizing solutions that imply ex ante knowledge of what works in places where such knowledge does not exist).
  • We work with real problems and focus on real results (defined as ‘problem solved’, not ‘solution introduced’) in order focus the work and motivate the process (to authorizers and to teams involved in doing the work).
  • We—the BSC team affiliated with Harvard—see ourselves as external facilitators of a process, and do not do the substantive work of delivery—even if the results look like they won’t come. Our primary focus is on fostering learning and coaching teams to do things differently and more effectively; we have seen too many external consultants rescuing a delivery failure once and undermining local ownership of the process and the emphasis on building local capability to succeed.

This set of principles has underpinned our experimental work in a variety of countries and sectors, where governments have been struggling to get things done. We have worked in places like Mozambique, South Africa, Liberia, Albania, Jamaica, Oman, and now Sri Lanka. We have worked with teams focused on justice reform, health reform, agriculture policy, industrial policy, export promotion, investor engagement, low-income housing, tourism promotion, municipal management, oil and electricity sector issues, and much more.

These engagements have taken different shapes—as we vary approaches to learn internally about how to do this kind of work most effectively, and how to adapt mechanisms to different contexts and opportunities:

  • In some instances, we have been the direct conveners of teams of individuals, whereas we have relied on authorizers in countries to act as conveners in other contexts, and in some interactions we have worked with individuals only—and relied on these individuals to act as conveners in their own contexts.
  • Some of our work has involved extremely regular and tangible interaction from our side—with our facilitators engaging at least every two or three weeks with teams—and other work has seen a much less regular, or a more light touch interaction (not meeting every two weeks, or engaging only be phone every two weeks, or structuring interactions between peers involved in the work rather than having ourselves as the touch point).
  • We have used classroom structures in some engagements, where teams are convened in a neutral space and work as if in a classroom setting for key points of the process (the initial framing of the work and meetings at major milestones every six weeks or so), but in other contexts we work strictly in the environments of the teams, and in a more ‘workplace-driven’ structure. In other instances, we have relied almost completely on remote correspondence (through online course engagements, for instance).

There are other variations in the experiments, all intended to help us learn from experience about what works and why. The experiments have yielded many lessons, and humbled us as well: Some of these experiments have become multi-year interactions where we see people being empowered to do things differently, but others have not even gotten out of the starting blocks, for instance. Both experiences humble us for different reasons.

This work is truly the most exciting and time consuming thing I have ever done, but is also—I feel deeply—the most important work I could be doing in development. It has made my sense of what we need in development clearer and clearer. I hope you also benefit in this was as we share our experiences in coming blog posts.

 

The “PDIA: Notes from the Real World” blog series

written by Salimah Samji

We are delighted to announce our new PDIA: Notes from the Real World blog series. In this series we will share our lessons from our PDIA experiments over the past five years, on how to facilitate problem driven, iterative and adaptive work . We will also feature some guest blog posts from others who are experimenting and learning from PDIA. We hope you will join us on this learning adventure!

Read the first blog post written by Matt Andrews here.