The Danger of PDIA Becoming a Development "Best Practice" class=

The Danger of PDIA Becoming a Development "Best Practice"

Doug Hadden, VP ProductsDoug Hadden, VP Products
“Mimicry” – this is what Professor Matt Andrews of the Harvard Kennedy School describes as the bane of aid and development projects in emerging economies. Development agencies mimic a project that worked in one country in other countries where the context is much different. Projects that adopt so-called “best practices” are more likely to gain funding. Andrews is part of a group of academics and practitioners that believe that development success comes from fully understanding the problem and adapting to the problem.
This strategy is called Problem-Driven Iterative Adaptation (PDIA). PDIA isn’t some “fly-by-night” fashion. It’s built on deep analysis of what works and what doesn’t. (Unfortunately, there’s a bit too much of what doesn’t). Andrews has laid out the case in The Limits of Institutional Reform in Development, and the Harvard Kennedy School Executive Education Leaders in Development: Managing Change in a Dynamic World that I’ve attended. Andrews points out that there is a big difference between simple problems (build a bridge), complicated problems (build a road and bridge) and complex problems (improve growth through infrastructure and other interventions).
I’m a big fan of PDIA. It’s helped us at FreeBalance to better manage the change challenges of implementing government financial software in developing countries. Lant Pritchett, also at the Kennedy School explains PDIA.

The problem is that I’ve begun to notice development agency claims of using PDIA. And, the evidence of PDIA appears to be a little light. It’s almost as if PDIA could become the new “best practice” to justify project approaches.
That’s a horrible prospect: turning a powerful toolset into a check list.

When PDIA isn’t Problem-Driven and Iterative

It may be easier to determine with more certainty when projects are not using PDIA:

  • The solution domain was selected prior to project funding
  • The donor selected the project, not the country selecting the donor first
  • The actual budget equals the initial proposed budget meaning that there may not have been much iteration that could have resulted in lower or higher costs
  • The project followed the project plan rigorously, so there was not adaptation
  • No part of the project experienced failure, so there was no iteration
  • There was no prototype, so there was no testing
  • PDIA activities are presented as process milestones, such as “here is where we spend an afternoon talking about iteration”
  • The project evaluation is good to excellent but the outcomes were mediocre
  • Outputs (number of students) measured, not outcomes (educational improvements)
  • The resulting activity requires outside experts to maintain – it’s not self-sufficient, therefore didn’t adapt to the local context
  • The main focus was to make the government look good rather than improve behaviour
  • The project failed to scale

Agile, Lean and PDIA

The notion that iteration is effective in conditions of uncertainty is not new. Andrews sees the parallels with agile product development. Agile development was not met with universal acclaim among software firms. I remember the suspicion that agile lacked direction. Confident product managers thought that they had the expertise. Many elements from agile processes were skipped like peer programming, A/B testing, and usability analysis. The results weren’t pretty and it was blamed on agile methodologies by many. Agile has matured into an innovation methodology known as lean or lean startup. Agile and lean has generated significant innovation and has become mainstream in Silicon Valley.
Chuck Eesley at Stanford University describes lean as the “scientific method” in action. Lean is all about identifying the problem to be solved and testing it with prototypes with target customers. Feedback is critical. This is very much the science behind PDIA, when done right.