Thoughts on the use of hypotheses in adaptive management

Tim Sparkman shares Lean Startup lessons for adaptive management in development projects.

Since August last year, I've been building the business model for a networked logistics services startup called a2b, following the Lean Startup method, with support and funding from Mercy Corps' Social Ventures team. a2b's goal is to provide a middle market transport solution for wholesalers and retailers throughout Uganda by networking the more professional owners of the local transport class while providing shipment brokerage, real-time package tracking and insurance. From a systems perspective, a2b seeks to become a disruptive new attractor in a relatively stagnant transport system, coaxing performance improvements among a group of agents by providing consistent rewards.

After a few months of market research, spreadsheet obsession and a trial shipment, a2b is ramping up to build out a tracked network of independent operators and run a large volume of trial shipments. Building a2b has been a fascinating experience for many reasons, among them the opportunity to experience the difference between adaptive management of a development project, on one hand, and the Lean development of a business model, on the other. I have to admit I thought they were the same when I started. I assumed that a results chain was the equivalent of a Lean hypothesis and I assumed that the swarm-like, serendipity-seeking attitude I had brought to Mercy Corps Uganda's Northern Karamoja Growth, Health, and Governance Programme (GHG) was called for with the exploration required to build a viable business model.

I was wrong on both assumptions and I've been wondering if those lessons could be applied to development projects,[1] specifically with the way we write proposals and workplans, because Lean requires the level of clarity donors appreciate.

Be specific

In both assumptions I underestimated the level of specificity and short-term purpose Lean requires. Where results chains lay out a long-term theory of change split into a series of short-term pieces, Lean Startup demands only short-term hypotheses that address significant, identified challenges to the validation of the business model. With Lean, you’re not looking for great new opportunities that come from shaking up a system or laying out a path to broad-based income generation for a whole class of people – you’re just trying to, for example, prove to yourself and your funders that you can track un-utilized capacity in an existing system of independently operated lorries so that you can (next hypotheses) sell that unused space for a bargain price to shipping clients. It occurs to me that this level of specificity, so difficult for facilitative, adaptive programmes to provide in a long-term planning framework, speaks to the progress measurement incentives facing donor staff. So a potential compromise lies in committing to a high level of specificity for immediate hypotheses in proposals and workplans.

To illustrate, here’s a2b's workplan for the next three months:

While it is unrealistic to ask an adaptive programme to lay out more than one years' worth of programming, it is both realistic and useful to ask a programme to explain its short-term hypotheses for interim changes and the sprints it will execute to evaluate those hypotheses. This could constitute a workplan that is as informative for donors as for programme staff, with major decision (or pivot) points scheduled every few months. It could even be used as the basis for proposals, with applicants using short-term hypotheses to lay out their admittedly incomplete understanding of the problems donors are asking them to address, and sprints to show their understanding of the types of activities they’ll execute to explore their hypotheses. It would be great to never again have to write a proposal that claims superhuman awareness of outstandingly complex problems, simply because the money expected it.

Keep track

Lastly, a concern with any new trend in development is that the framework’s jargon always spreads faster than the actual knowledge of (or dedication to) it. That’s a danger with adaptive management as well, opening the possibility of using the approach as a justification for any programme change, well founded or not. A good way to mitigate that concern would be for donors to require a pivot log that chronicles the evolutionary path of a programme through its stages of hypotheses, sprints, learning and redesigns, for the programme's duration. If programme staff are thoughtful in their pursuit of adaptive management, they should be able to explain it clearly. Published alongside a final report (or even interim reports) they would provide some donor-satisfying clarity as well as fascinating accounts of a programme’s exploratory process and a rich learning resource for other implementers (imagine having access to this level of insight into the paths of dozens of projects. I would start mine with 'stardate'). Regularly maintained, a pivot log would also give a donor liaison, advisor or programme visitor a quick understanding of what a programme has done and where it is going, saving a lot of time and misunderstanding.

Thoughts in a nutshell.

[1] Quick disclaimer – I think we should be sceptical when applying business paradigms to development. Development involves an aspect of scientific exploration that business usually does not. In this instance, however, the business paradigm offers the advantage of a potential compromise between donor preferences for specificity and implementer preferences for flexibility.

> Read more on adaptive management and watch the webinar recording.

Tim Sparkman is a development economist, entrepreneur and systems thinker. He had the opportunity to lead the design and management of Mercy Corps' USAID-funded Northern Karamoja Growth, Health and Governance Programme for its first two years, and since August 2014 has been working on a startup logistics company based in Kampala.