ICTworks

We all want to be good at our jobs. We want to accomplish the things we set out to do. If we aren’t accomplishing them, we want to figure out why or try new solutions.

The trend toward Adaptive M&E is exactly that: a desire to be better at our jobs. Similar trends exist in the software world (agile) and in manufacturing and start-ups (lean). But by any name, this process of seeking to improve is about speeding up decision-making and solution delivery by focusing on incremental, iterative planning and execution.

I presented on agile with Monalisa Salib of USAID Learning Lab at MERL Tech 2016. I talked about creating software; she talked about creating evaluation tools for USAID missions, but we were describing the same basic process: Develop, Release, Reflect, and Adapt.

You can see our slide deck for more details, but here are the key discussion takeaways that won’t show up there:

1: Eyes on the Prize

Any effort should start with a clear definition of what you’re hoping to achieve. What theory of change are you testing? What service or benefit do you hope to deliver to your beneficiaries? We’ve found it useful to start with the end state and work backwards—by clearly defining a Minimum Viable Product, laying out a blog post of what you hope to achieve, etc.

2: Limit Decision-Makers

The goal is fast learning and pivoting—you want to try something, collect feedback, and immediately decide if you want to tweak it and continue or start fresh. It’s easier to generate new iterations on a solution or product if you confine decision-making. Identify an Owner and give him/her the responsibility.

3: Know your User(s)

Many guidelines talk about getting “end user” input, but in reality there are tiers of stakeholders with overlapping but different needs. Alexandra Warner of ALNAP categorized “users” this way:

• Gatekeeper: the decision-maker who must buy into the solution, like a government official or senior manager
• Primary Beneficiary: the person who actually benefits from the solution, such as a Program Officer
• End User: the person who actually has to use the solution but may not derive benefit from it, like a field volunteer entering data

At DevResults, we call this the Russian Doll effect: site administrators usually end up being the “primary” beneficiaries, but our software needs to be intuitive and accessible to anyone collecting data in a remote field office and sophisticated enough to appeal to a CEO. Consider these tiers while you’re designing solutions and seeking input.

4: “How Can I Convince My Donor/Partner/Etc.?”

Many attendees really wanted to try out an agile approach, but the resounding question was: “how can I convince [someone outside my organization] to trust me that this will work?”

I don’t have a magic bullet answer, but as a group we generated a few potential solutions:

• Try the approach on internal work or small subprojects first. This lets you refine it and generate some successes that you can later reference in a low stakes way.
• Diplomatically use risk management as a motivator. It is in your mutual best interests for you not to fail. You’re suggesting this approach because an iterative approach has more opportunities for feedback and correction, minimizing overall risk.
• Be the voice of agile. One attendee noted that you’re selling the methodology rather than a specific product. You’re saying: “yes, I will achieve this milestone, but all the work I’m going to do to get there is a bit of a mystery, except I can tell you I’m going to follow these processes, and the iterations will help me correct faulty assumptions faster.”

In the long-run, an agile mentality will serve you well. We work in an industry that is constantly evolving, and to truly meet those needs, our methods have to be flexible. Conflict areas rise and fall; natural disasters strike unexpectedly; political climates shift. Your work, too, must adjust.

And if you can convince your team, donor, and partners that you understand this and have an approach to incorporate that into your work, you might be surprised at how willing they are to let you iterate away. So try it today—check out our slide deck for resources, identify a Product Owner, and start testing some MVPs!

By Kate Mueller and Monalisa Salib with visual notes by Katherine Haugh.