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:

Hypothesis Test - activity detail Milestones Timeline
a2b can sell at a price point that is less than or equal to 80% of the price for similar services charged by the headline couriers and earn a contribution margin of at least 40%.

sprint 1: discover headline competition cost structure

sprint 2: evaluate shipper willingness to pay, reliable performance parameters and the cost structure of door-to-door service with a critical mass of shipments

DHL and DAKS cost structure understood.

20 transactions show a progressively increasing contribution margin, reaching at least 25% by end of March.

January 30 for headline shipper cost structure.

Delivery pilots will happen throughout 2nd Assess Phase.
a2b can identify exploitable cost inefficiencies within local transporter operations

sprint 3: interview 30 truck owners to better understand their models and constraints and gauge underutilized capacity (include drivers)

sprint 4: install trackers in up to 25 lorries and use an SMS shortcode to allow truck drivers to report destination, tonnage, amount of space open, points of refueling and fuel quantities, etc.

30 truck owner interviews completed and cost structure refined.

Network recruited and 25 thinvoid trackers installed.

January 30 for truck owner interviews.

January 30 for network recruitment and tracker installation.
a2b can use local transporters to run shipments at a reliably consistent performance level sprint 5: performance tracking of the network and trial shipments, examining parameters related to reliability (trip duration, delay frequency, etc.)

1.5 months of network performance data collected and analyzed prior to end of March funding call.

IT systems spec’d out.

Movement data recorded throughout the 2nd Assess Phase.

March 30 for setting backend IT system specifications.

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.

Add your comment

Sign up or log in to comment and contribute.

Sign up