Reacting or adapting? Purposeful adaptation and response to contextual change.

Adaptive management is increasingly on the ticket for development programming, and has been crucial in the wake of covid-19. I’ve been working with adaptive programmes for most of my career, and yet the question I hear frequently is ‘but what does good look like?’. I wanted to take time to reflect on that.

This particular blog post was prompted by a conversation I had with a fellow thinker and friend Ben Kumpf (@bkumpf), Head of Innovation in DFID (then-called if reading after September 2020). We had been discussing enablers of adaptation and he asked me if I had any case studies of tools and methods that worked well… which is what sparked me to say ‘I don’t think I can do that, as I don’t believe those are what meant adaptation worked well’. After some discussion we distilled what that meant, and I have since been having multiple conversations about what ‘good’ adaptation looks like.

To me, good adaptation is actually not the tool you use or method you employ, or space you create in your schedule, but ways of working. Tools and space help, of course, but it’s a mindset and a way that you set up a team that really makes the difference. But before I get onto what causes it, I wanted to talk about what ‘good adaptation’ actually looks like.

There is a stark difference between purposeful adaptation that identifies changes in context early and responds in a proactive and planned manner, and reactive repair work that scrambles to hold a programme in-place in the face of change.

To illustrate, let me describe two scenarios with the case study of two programmes in Uzbekistan and the Kyrgyz Republic. These are entirely fictitious and do not represent any existing projects, people, or realities.

Case 1: in Uzbekistan, healthcare provision have been improving due to increased funding and the transformational plan rolled out by the president. There is a lot to do, however, and risks of shifting leadership is still high as hospitals adapt to the new requirements.

The delivery team are working to strengthen health system reform, and have developed an Actor-Based Change framework to inform a theory of change, both of which they built with their counterparts in hospitals. The team are driven and results-focused, generally contextually-savvy, and have worked in lockstep with their counterparts.

The key hospital leader they work with has been under a lot of pressure and struggling to meet requirements. He had been appearing at fewer and fewer events and giving less direction. The team have been ploughing on trying to meet their milestones, and despite faltering leadership are fully in the thick of it and riding the wave of initial accomplishment in the face of challenge. Unfortunately, the key counterpart falls ill and is quickly replaced with a new leader. This leader changes the direction of the implementation efforts fairly swiftly. The delivery team scramble to meet the change of direction, using a scheduled reflection point to desperately reschedule their separate activities, flights, and plans. They try to catch up with the new direction and have re-positioned their original activities to maintain their initial theory of change, but may not meet their milestones. The systems map and ToC remain in their original form and get left in a shared folder.

Case 2: in the Kyrgyz Republic, local government stability is low. Due to endemic corruption, nepotism, citizen unrest, poor communication lines with central government, and conflicting Former Soviet Union structures the turnover is high and the central government collapses roughly every 8 months. While this can occur suddenly, the warning signs are spottable.

A delivery team has a project strengthening the interaction between civil society organisations and local authorities on key agricultural issues. The local authorities are in flux, with key players swapping out and changing with each collapse and restructure.

The delivery team in question is aware of this, and based the project on an Actor-Based Change framework that they built hand-in-hand with their civil society counterparts and used to create their theory of change. The team are driven, creative, collaborative, and meet regularly. The delivery team have been working through their communication and collaboration agenda with their counterparts, and have reached a scheduled quarterly reflection point. In this reflection session, they discuss progress against their theory of change and revisit their systems map. They reflect on the environmental changes occurring and the rising instability around the current leadership in their target areas as a result of a new corruption charge levied against key players. The likelihood of a topple in the next quarter is quite high, and so to maximise success the team suggest adapting their capacity building to include a wider pool of trainees, as well as to start building relationships with other influential actors in the system. Shortly thereafter, some corruption charges gain traction and the local authorities’ leadership changes. The new leadership have a slightly different agenda, which the delivery team are aware of due to already diversifying relationships. They had been altering and expanding their capacity building work in anticipation of this already, and had the traction to pivot more sharply in response to this change. They alter their systems map accordingly and reposition their altered activities (letting go of those that are no longer appropriate) in an updated theory of change.

To me, the difference here is Case 1 reacts to a change, whereas Case 2 adapts. The difference between purposeful adaption and reactive repair is fairly clear.

Case 1 is a situation where the team were so focused on delivery and so tied to their identified lines of activity that instead of noticing the leadership issues and subsequently preparing for a change of leadership, they desperately try to plough on and get their milestones over the line before something happens. This means they are caught off-guard, and end up scrambling: this wastes money, time, and effort. Instead of using their reflection point to think and adjust, this space is used to react. Ultimately they don’t shift their plans or theory of change to respond to the change in power and direction, and instead cling to original plans and try to shoehorn them in. The ABC and reflection point references were a red herring here. Although ABC was a useful tool initially, the team doesn’t continue to use it and lets it stagnate along with their theory of change, and instead use their reflection point to try to push activity: these are treated as tick-box requirements and there wasn’t a commitment to really use them.

Case 2 is a situation where the team were also focused on delivery, but were by nature collaborative and clearly led by context. The ABC reference was also a red herring here, as although it was a useful tool, the reason they were able to adapt so well was because of how they worked together: they used their scheduled reflection points to problem-solve, collaborated closely, used their systems map and ToC, and habitually took account of the context and questioned their approach. This team were not so attached to delivery that they couldn’t pull the plug on activities that were no longer viable, and were horizon scanning constantly in case of signs of instability. They used the time and tools to-hand effectively. These ways of working empowered their ability to purposefully adapt. They didn’t need ABC or strategy testing to do all of this, though it was a useful vehicle to channel their adaptive approach through.

Good adaptation is simply this. It is about fostering ways of working, supplemented with any tools and structures that may be useful, to permit programme teams the ability to horizon scan and leverage their analytical and creative problem-solving skills to alter programmes to overcome a barrier or lean into a success. It is about being willing to let go of things that aren’t working. It is about trusting your team, communicating effectively, and thinking creatively. It’s about being comfortable with uncertainty.

There are a whole host of different adaptation methods documented, from strategy testing to AdaptScan to CLA. If you want to get more sophisticated, consider involving a Socratic facilitator (not a troll!), systems maps, and real-time monitoring, but it’s not essential. Ultimately these mechanisms should always be proportionate to what is available to the programme team or they will not be useful. These structures and any tools introduced are only as useful as the teams using them: teams need to be committed to use them well, have the freedom to do so, and be open to adaptation and change. You can have the best tools and structures in the world, but if a team isn’t bought-in or holding the right soft skills, they won’t help you.

A similar argument goes for the space to adapt. Having senior decision makers permit the team space to adapt gives a team the breathing room to take five and reflect, like in Case 2, but similarly this is only as useful as the team’s use of it. In Case 1, the team had both tools and space, but simply didn’t use it effectively.

Effectively, I see it a little like the diagram below. The tools and space to adapt are necessary components, but are not sufficient for adaptation to occur. You need those ways of working:

• If you take a team with the right mindset and ways of working, but they don’t have sophisticated tools, you will find that informal structures and tools often come into being even if they’re not tidy.
• If a senior decision-maker isn’t bought in and won’t sign off on a ‘capital ‘a” adaptive programme, I have still seen creative, adaptive, ways of working emerge despite it (though often in more ad hoc bursts). It might be that teams still communicate issues on the horizon and a shift happens in a less formal manner.
• However, if you provide tools and space to a team that isn’t engaged… Nothing will happen.

So I’ve laboured ad nauseum about teams being crucial here. But what do you do when you don’t have that component? Well, when talking about adaptation a reaction I hear a lot is ‘Why would I want to be adaptive? It sounds like a lot of work’. This is the attitude that often causes the forth diagram in the image above.

There is argument that adaptive management requires a time and resource cost that may not be worth it. Or, even, argument that some situations happen so quickly that they cannot be predicted.

In the case of the latter, this is of course true. There are black swan situations that cannot be anticipated, such a natural disaster or an outbreak of Legionnaire’s disease in the local water source. However, this is not a situation where you can be let off the hook for purposeful adaptation. Just because the events are unpredictable, doesn’t mean that the response should be frantic (and, in fact, often you are judged more on how you respond in black swan instances than in others). If there is a habit and familiarity within the team of taking space to think and adapt, this can be applied in these contexts: simply take some time out as soon as possible to reflect, prioritise, and adapt based on any evidence you have to hand. Remember: in complex contexts we are not ‘solving’ the situation with a binary sense of certainty, we are making the most evidence-informed decisions we can to contribute to meaningful change.

As for the timesink argument, this is true to an extent. It does require time to engage in adaptive management, of course. This time will include the reflection sessions but also any follow up: updating of risk registers, design of new activity, wind-down of old activity, updating logframes, documenting changes, etc. Not to mention designing MEL systems that are also adaptive in their nature. Expectations do need careful managing on this. However, even basic cost/benefit analysis analysis shows that this input of time is worth it for a programme that delivers more effectively in a changing environment.

A programme of mine once made the hard choice to pull out of a situation when things weren’t working, and reinvested those resources elsewhere. It is huge credit to their willingness to let go of a line of activity, as in some ways this wasted the time invested already in that country, and further time was needed to identify the issues in the first place and make all the changes responsibly. But this is a sunk-cost fallacy. In many ways this saved time. Instead of charging ahead in a context where something wasn’t working and ultimately wasting time, resource, and money on something that would have minimal results, we took all of that potential and invested it where it would. The subsequent successful results were more than worth it when you compare input vs results from both scenarios.

Aside from the cost-benefit argument, adaptive approaches are simply necessary when working with complexity. The high degree of uncertainty that we face globally means that a test-and-learn approach is increasingly relevant. The nature of complex systems is such that they are always in flux, and so programmes simply have to adapt with the environment. Doing so in a structured manner ensures greater leverage of the resources you have to hand, rather than panic-driven repair work that is still common.

Adaptive approaches really are worth it, and they are always viable. It’s becoming increasingly crucial to move out of the reactive repair space and to instead invest that time in designing adaptive results frameworks and MEL systems, and cultivating that culture of adaptation. To invest in your teams.

This is why it was hard for me to provide my colleague Ben with a good case study. Ultimately the tools and nuances of a case really don’t matter because they were specific to that instance. What did matter in successful adaptive programmes of mine were the personalities at play, how people identified and interacted with problems, how we navigated emerging success, and the overall willingness to change and learn. This is a lot harder to replicate play-for-play than a tool, but I believe it is the heart of what good looks like.

—–

Thanks to Ben Kumpf (@bkumpf), Jamie Pett (@JamiePett), and Emma Proud (@EmmaProud) for fascinating conversations that provoked me to write this. Thank you to Lauren Sweeney for being a fellow adaptive management champion in my MEL team and a constant source of insight. Thanks also to Alex Jaggard for being a critical friend on this piece.