Adaptive management – the idea that development projects should respond to real life complexities and be flexible enough to respond to unforeseen changes – is an often-praised approach to doing development differently, with donors and partners exploring how to apply it within their programming.

We consider ourselves an organization that promotes and integrates adaptive management into our approach. Our Results Data Initiative (RDI) program is based on the Problem Driven Iterative, and Adaptive (PDIA) framework, for example, which has allowed us to co-create solutions together with those solutions’ actual end users. The basic concept of adaptive development, however, is neither new nor specific to international development – it is used across sectors.

DG has long used the Scrum framework (a type of Agile methodology) that improves cooperation and increases productivity in building complex technology tools. By regularly re-prioritizing new features throughout the development process, we ensure our solutions meet the actual needs of users. We see adaptive management as a natural extension of using this process.

Figure 1: Identifying user priorities to co-create solutions

Planning – and Budgeting – for Adaptation

As we’ve integrated adaptive management more and more into our programs, we’ve learned that implementing adaptively does not come without hidden costs, particularly in our heavily tech-focused work.

To enable successful implementation of an adaptive technology program, project budgets and contracts need to be designed from very beginning to take these costs into account.

Development organizations seeking technology projects often release Terms of Reference with highly detailed functional requirements – serving more as a Request for Quotations, with mostly-financial considerations, rather than a Request for Proposals, allowing room for new ideas, vision, and methodology. As adaptive management practitioners know, it’s important to focus on objectives and outcomes, rather than outputs. This same mentality should be applied to tech implementations, in order to ensure tool sustainability and use.

In these traditional implementations, the budget line for iterative changes or new features is missing. Without funding specifically set aside for adaptation (and trust us, there are ALWAYS changes and new requests), we’ve seen clients grapple with prioritizing new, legitimate needs versus previously (still legitimate!) scoped features. Meanwhile, there are also unplanned costs for scoping out new features, even when the feature ends up not being implemented, typically due to not having budgeted enough for adaptation from the start.

To avoid these cost frustrations, whenever possible, we’ve added budget lines to allow for new feature requests and changes as they arise. We’ve found that prioritizing flexibility has made a significant difference in the satisfaction of our users and partners, as it allows our partners the freedom and flexibility to adjust to unforeseen needs. Is there a new data source they’d like to include in a dashboard? A request from a high level executive calling for a particular capability in exporting reports? When the end goal is a usable tool, and when procurement mechanisms allow for portions of a budget to be allocated to specific tasks after project launch with adaptation in mind, teams can expect with a stronger product, better aligned with the project objective.

At a larger scale, we are seeing more tech-focused programs designed and managed adaptively. Flexible budgets allow us to learn, develop, and adapt all within scope of the contract. We are able to take the time to assess needs, plan, and implement – and then, if needed, adapt, plan, implement, and adapt again.

Figure 2: Time, Cost, and Scope of implementing a quality technology project

We encourage development partners to consider building adaptive budgets for technical programs that allow organizations to not only identify needed changes, but actually act on them.