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.