The Limits of Institutional Reform in Development

Constructing the problem as an entry point for change, broadening engagement (part 4 of class 14 in GTD)

I have not written about my course for a few weeks, given the Doing Development Differently posts. 

The last post on my course focused on part 3 of class 14, and focused on taking readers through the process of problem construction (constructing problem statements that draw attention, mobilize action, and provoke a search for new ways of doing things). I was using examples from places like Mozambique to explain how I work with an authorizer first to identify a problem area; and then I work with teams, asking them questions like 'why does it matter?' and 'who cares?' In these meetings I am pushing the teams to identify evidence--in data, stories and reflections on crises--that help to construct the problem.

I finished the last post with this text:

"Ultimately, the strategy was to get key data and stories about how the performance deficiency affected end users in the system--given an argument that these end users were the constituents of politicians whose support would be needed, or businesses paying taxes (who often had louder voices than citizens). The group agreed to get data about these groups, via past reports and surveys (like the Afrobarometer survey and the Doing Business Survey). 

This was another brief iteration, lasting a few hours and coming one day after the first meeting, where the group was constructing its problem to draw attention, create space for action, and ultimately move towards a new reform. The groups were asked to come back the next day with the new information."

Hopefully readers can see that the process of constructing the problem is (i) rapid, (ii) iterative, (iii) action based, and (iv) focused on the substantive engagement of local agents who will be needed to solve the problem.

The process of going back to past reports and to other constituents is purposeful. It forces the team to broaden its view of the problem, in a disciplined manner. Others' views are introduced, via past written work and even interviews and other forms of active, primary engagement. In this process I expect that team members will start contacting others who will be needed in the change process, and these folks will have opinions on the problem construction process that are often important. These folks will bring their authorizers into the process, bridging some organizational gaps that often fester.

• In the group I was working with on Justice (discussed in prior posts), the team started engaging with key people across the justice sector (as well as past analytical reports of the sector performance). They came back with real data to show the performance deficiencies--and a few new team members who actually furnished the data. This was an important iteration for existing team members; they got to see that contact with others can generate new resources that help action. Most importantly: The new team members had engaged their authorizer to ask about joining the team, and the authorizer had become engaged with the minister who initially provoked the work. So the authorization of the team grew as well. The figure below shows this, with numbers showing how the relational aspect of problem construction worked: 1. The minister engaged a facilitator; 2. The minister convened a team; 3. The team reached out to colleagues in other areas of the system; 4. The different members reached out to users and to analytical work to ask about the problem; 5. A new authorizer was engaged. The result: a broadened team, and broadened authorization, and broadened engagement.

• In another country I worked on maternal mortality problems, and the central team I had been engaged with decided to share ideas about their problem with health workers in a select set of provincial and district centers. They took two days to travel to the centers and came back with a variety of vital new ideas, data, and distributed members who felt a vital connection to the change process.
• In yet another example I worked with a small team on an industrial regeneration reform. The team had defined the problem in a specific way (focused on deficiencies in legislation and in doing business regulations, where the emphasis was on the number of days to start a business, etc.). The team decided to float this problem definition with business people in the sector they were focused on. The business people gave them new data, new views, and new points of interaction. The team came back with a completely different view on the problem, emphasizing constraints to actual production.

In all cases, this was another iteration in constructing the problem, that took the teams into a deeper understanding of their contexts and helped them to communicate a problem that they knew key players cared about... The process took days in all cases, and galvanized the team in all cases. It also helped to broaden engagement to those distributed agents who would be affected by the change. In most cases this broadening leads to expanded teams, and connections to new authorizers as well.

These are key factors that help success later on, especially when dealing with complex problems: One gets a greater handle on complexity the more one engages and the more one learns.

After this iteration, I often find folks start getting concerned about how 'hard' or 'big' their problem is: So I ask them if it's possible to deconstruct the problem into smaller bites. I will post on this process of deconstruction tomorrow.

Using PDIA to promote health sector reforms: my great students doing role play

Here is another presentation of my great students working on PDIA. They did a role play exercise to show how a team in a hypothetical country used problme driven methods to find out what was going wrong in the context and then try out some solutions and build their way to a full reform. Well done Gui, Christin, Nicole, Yadira, Jessica and Zina.

Probably the best thing in this role play is the person Gui (the tall fellow at the back of the room in the team meetings) represents...'the difficult one listening to music, on his phone, questioning things' etc. But then he suddenly comes alive and gets empowered to do things.... I also loved the 'why why why why' that went on....and the iteration and adaption that happens even when the team finds some ideas don't work. Also: the importance of evidence and lessons... This is very much like the process I commonly engage in..

listen to the last thirty seconds, and 

"Clap along if you feel PDIA is the truth"

 

From classical to NPM to PDIA reforms--more from my great class

Here is a set of three assignments by one group of my great students--Team MALIBU (Masoomeh, Arthur, Lily, Idauli, Bertrand, and Upasana). The first video offers a set of classical management solutions to help reform the health sector in a fictional country, Messaria. 

 

Then they propose New Public Management solutions to Messaria's situation... 

 

And finally, they come up with an approach to do reform in a complex context, characterised by unknowns and expected unexpecteds... using problems as entry points to change in these contexts can help provide windows to see the context and to enter with reform.

 

Another view on doing problem driven iterative adaptation...

Here is another presentation from my students, giving their view on how to do problem driven work. They were advising a hypothetical country on how to do this work in the health sector, using problmes as windows to complex contexts and entry points to change.

I find their approach to communicating the work interesting, applied, and useful. They convey some of my messages much better than I could! Well done Benjamin, Pilar, Hanieh, Daniel, and Anstes!

 

The PDIA Anthem: How do you do PDIA in song?

Yesterday I showed a presentation my students produced in response to an assignment I gave them.

I asked them to produce a PDIA strategy for the health sector in a dysfunctional state they did not know about; Messaria. One of the students, Tim McNaught, wrote a song as part of the exercise. It is his second song on this blog site. A PDIA Anthem! Thanks Tim!

Here's a view on doing problem driven iterative adaptation....

I am busy blogging about the way I taught my students to do problem driven work -- especially constructing and deconstructing problems to get a window onto complex contexts and find entry points for meaningful change.

At about the time of the class I am reviewing in my blog (class 14), my students did an assignment.

They had previously done two assignments acting as consultants advising a hypothetical government, Messaria, on health reform. They were asked to give classical administrative and new public administration solutions... "centralize", "decentralize", "use targets", "contract out", etc.

I then taught them about context and we discussed how many of the management and policy solutions regularly offered in development just don't fit the developing country contexts. They were told that the Messarian context was particularly challenging and the prior recommendations did not fit.

So: How would you develop an approach to reform in a place where you have no clue about the context. You guessed what I was looking for: Use Problem Driven Iterative Adaptation..... construct and deconstruct problems, try things out, learn about the context, adapt, repeat. 

The teams were asked to do a video or paper describing how they would work with problems to enter into difficult contexts... here is one of the products -- you see how amazing my students are. Thank you and well done Surili, Lucila, Boban, Mary, Charles and Changgi. 

 

'Who Cares?': Constructing problems in Mozambique (part 3 of Class 14 in GTD)

Yesterday I blogged about starting a problem driven process, using work I did in Mozambique as an example. I focused on the importance of starting with an authorizer nominating a problem (note that the authorizer does not fully define the problem, but nominates an itch they are willing to scratch).

"Do you have an itch you need to scratch?"

 

The authorizer then convenes a group of officials under his/her authorization, to further construct the problem. This group is led through a process of questions about the problem to identify a real performance deficiency. The question I start with is usually 'why does it matter?'

This gets the group to some common construction, which they can verbalise. I ask them if there is any evidence to support the verbal presentation of the problem: do we have data or stories to show how severe the problem is?

The groups I was working with took this question home after an initial meeting, returning the next day with some data and stories. They also mobilized new members of the group: people from other agencies whose views they thought needed to be heard to fully construct the problem.

When we met again the group was bigger and conversation about the problem was more robust and textured--more opinions, more ideas, and less of a chance that we were getting 'the wrong problem'. In the justice group, new members came from the statistics departments of the prosecutors office and courts; they added to the officials already present from the Ministry of Justice but bought a different set of voices. 

The newly expanded group also had data at its disposal, showing national caseloads which could also be broken down by province. They showed how caseloads had grown rapidly over the years and could see which provinces had the biggest backlogs. This was a key part of the performance deficiency they were concerned with. They also showed the difference between budget requests and allocations in prior years, noting the gap that the sector ultimately had with rapidly growing demand in the courts but slowly growing budget resources. All members of the group agreed with using these data to show the gap.

As noted before, I always ask a key question when faced with a gap like this--especially one that has been festering--'why has it not been solved before?' Put differently, 'who cares?' (or, 'what does the group need to do to get key players to care?'). This was an interesting question for the group and started them thinking about who was being affected by the problem but was probably not effectively mobilized to help in resolving the problem. They listed various political figures, ministries and sector organizations, and more. They argued a bit about the kind of pushes and pressures needed to 'get these key players to care.'

"Who Cares?"

 

Ultimately, the strategy was to get key data and stories about how the performance deficiency affected end users in the system--given an argument that these end users were the constituents of politicians whose support would be needed, or businesses paying taxes (who often had louder voices than citizens). The group agreed to get data about these groups, via past reports and surveys (like the Afrobarometer survey and the Doing Business Survey). 

This was another brief iteration, lasting a few hours and coming one day after the first meting, where the group was constructing its problem to draw attention, create space for action, and ultimately move towards a new reform. The groups were asked to come back the next day with the new information. 

When discussing the process with my students I emphasize a few things: 

• This is not some outsider identifying a problem on behalf of insiders working in the developing country; the insiders are doing the identification.
• The process starts with an empowered authorizer, but does not stop there; problems are identified by a growing group and with reference to a broad (and continually broadening) set of agents and information. The goal is to have many voices represented in a fairly tight, 'quick and thick', focused discussion (not an easy goal but certainly possible).
• The process is not about doing loads of external analysis and desk work; rather, it is about groups engaging and discussing/arguing/exploring their own realities, using evidence that is already in place (there is usually no lack of evidence in developing countries, given the many assessments and reports produced by development organizations). 
• The process is not just about identifying a problem; it is about using the problem to learn about the context and create space for change--by mobilizing the group to communicate how disrupted things are and create some momentum for change.

 

 

 

 

Starting problem driven work in Mozambique (part 2 of Class 14 of GTD)

I used the description of my work in Mozambique to illustrate how problems can be made into entry points for change, given ideas I posted about  last week.

These posts are thus pretty boring...they capture the practicalities of step by step engagement and will build over days.

How did the work start?

In the prior blog I emphasized the importance of starting with someone who can authorize some work and getting them to nominate a problem--something that they care about and that they are willing to support. In Mozambique I met with Ministers of Health and Justice and they nominated problems they were struggling with.

• The problem in health was a big one: the maternal mortality rate was higher than in neighboring countries and the Minister was under pressure to bring it down, from internal political allies and rivals and from external donors.
• The problem in justice was more focused: a donor funded project aimed at creating an IT-driven case management system had just concluded but the country still did not have the system (and lacked reliable data showing where it faced demand and had supply to meet the demand--in the form of judges, court houses, etc.). The minister was under pressure to produce more evidence-based budgets and did not have the evidence at hand to do this.

These problems were the starting point for engagement, and both ministers were asked to use their convening authority immediately: calling a group together to construct and deconstruct the problems. The act of calling a group together is the first window I have onto the context, and shows me a little about the authority and intention of the authorizer. (How quickly can she mobilize folks to work on this, and does she do this quickly).

The groups comprised senior and mid-level officials, mostly in the ministries under the authority of these ministers. The group members may all be in the same ministry or sector but they come from different backgrounds and provide the first point at which different views on the problem emerge...

These groups met, numbering about 5 officials each, and were asked about the specific problems, asking 'why does it matter?' (to ensure the problem was consequential).

This was an important question to ask in the health group because of the many priorities in that sector. The group went back and forth on 'why it mattered' more than many other priorities, which was a really important question and caused them to bring out data on the extent of the maternal mortality problem. They explored 'why it mattered' more in some provinces than others, for instance, which was a more defined problem than the one they started with.

This was also a very important step in justice, where the group started by saying that the problem was a lack of the IT system slated for introduction in the donor driven project. I call this defining the problem as 'the lack of a solution' and don't settle for such as a 'good problem' (that motivates change). So the group was asked 'why does it matter'  a number of times... 

• Why does it matter that you don't have the system? 
•  "Without the system we have no reliable and consolidated data"
• Why does it matter that you have reliable and consolidated data?
•  "Without that data we cannot manage our sector effectively."
• Why does it matter if you cannot manage the sector effectively?
•  "If we manage poorly we don't provide effective or efficient justice and we don't earn trust to receive budgetary funds needed to manage growing demand for justice."

Now this is interesting. The group moved towards a new problem statement (it was not formalized at this point but would have read something like the following): A lack of data compromises sector management, undermining the efficiency and effectiveness of justice and compromising the ability to raise budgetary resources needed to manage growing demand.

 After this good start, I asked the groups if there was any evidence that showed this was a problem: Any data on the efficiency and effectiveness of the justice sector, or stories about failures to provide justice or to get budgetary resources. This is an important act in constructing the problem (to draw attention to the problem by showing that it is both objectively important...via data...and subjectively emotive...using stories). The health group faced similar questions, though they were at a point where the questions were different for different provinces--so they needed to construct the problem for different provinces. The groups said the data existed, but they would need to get it. And they would need to ask others to join--from different ministries. 

This is understandable, so the groups adjourned and agreed to meet the next day: with data and stories in hand, and with new members of the group in attendance.

One iteration was done, the problem was emerging, and the group was gaining some momentum and doing tasks together. I note this because theory on team building emphasizes the importance of working together when transforming loose groups into tight teams....

 

How to do problem driven work? (Class 14 of Getting Things Done, part 1)

In this class I discussed my work in Mozambique, with other references to work in places like Albania, Liberia and beyond. The class was intended to give students a practical perspective on how to engage with problems in complex contexts to use these problems as entry points for policy, systems and other reform and change. The readings for this class are:

• Andrews, M. 2014. Can one retell a Mozambican reform story through problem driven iterative adaptation? http://www.hks.harvard.edu/var/ezp_site/storage/fckeditor/file/pdfs/centers-programs/centers/cid/publications/faculty/wp/278_Andrews_Mozambique%20Retelling%20Method.pdf
• Wong, K.C. 2011. “Using an Ishikawa diagram as a tool to assist memory and retrieval of relevant medical cases from the medical literature.” Journal of Medical Case Reports 2011, 5:120 http://www.jmedicalcasereports.com/content/5/1/120

A poster to reflect on the experience in Mozambique was prepared for another event, and may be useful to help give a sense of the story, which I will use in the next few postings to summarize the practical process of working with problems to foster iterative reform.

An example of problems constructed and deconstructed to drive change (Class 13 of Getting Things Done, part 3)

This video has already appeared on the blog, but it makes sense to present it alongside the materials from Michael Woolcock's class. It summarizes a case I discuss in chapter 7 of my book, discussing a way in which a problem can be constructed and then deconstructed to facilitate space for change.

One of my summary statements is simply: "It takes work..." I don't think that constructing and deconstructing problems is intellectually out of reach for anyone but it requires working, and being patient, and building stories with real evidence and engagement--especially going beyond 'experts' and 'elites' and getting a view of the problem from the vantage point of implementers, end users and others who are most affected by the problem and who will be most affected by any new solutions.