The Practice of PDIA: Building Capability by Delivering Results Podcast is a 12 part series that will walk you through the PDIA or Problem Driven Iterative Adaptation approach to solving complex development problems. 1,500 development practitioners in 90 countries have used the PDIA approach. Visit www.bsc.cid.harvard.edu for more information about PDIA or download our free DIY Toolkit: bsc.cid.harvard.edu/PDIAtoolkit Watch the Practice of PDIA videos: vimeo.com/84361642
Part 11: Designing and learning from your iteration
Welcome to Part 11 of the Practice of PDIA: Building Capability by Delivering Results Podcast series. This 12 part series, based on a video series used for our PDIA online course, will walk you through the PDIA or Problem Driven Iterative Adaptation approach to solving complex development problems. More than 1,500 development practitioners in 90 countries have used the PDIA approach.
We believe that the answers to complex problems do exist but they must emerge through active iteration, experimentation and learning. In today’s podcast, Professor Matt Andrews will discuss the PDIA principle of iteration.
Matt, can you share with our listeners how iteration can help build both legitimacy as well as functionality.
Could you walk us through the process of an iteration? What is it and how does it work?
Iteration is Research in Action.
Thanks Matt. Can you explain the process of designing the first iteration?
Designing your First Iteration.
Thank you for listening to Part 11 of the Practice of PDIA: Podcast series. Tune in to listen to Part 12 where we will discuss how we think about scale. To learn more about iteration in PDIA, download our toolkit at bsc.cid.harvard.edu.
PDIA in Practice 11: Designed and Learning from you Iteration
[00:00:05] Welcome to Part 11 of the practice of PDIA Building Capability by Delivering Results Podcast Series this twelve part series based on a video series used for a PDA on course. We'll walk you through the PDA or problem driven iterative adaptation approach to solving complex development problems. More than fifteen hundred development practitioners in 90 countries have used the PDIA approach. We believe that the answers to complex problems do exist, but they must emerge through active iteration, experimentation and learning. In today's podcast, Professor Matt Andrews will discuss the PDA principle of iteration.
[00:00:51] Matt, can you share with our listeners how iteration can help you with both legitimacy as well as functionality.
Matt [00:00:57] Organizations have many objectives. We often like to think that organizations are always trying to achieve results and do better than they did last year. But one of the major objectives that sometimes clashes with this is they just trying to kind of maintain their legitimacy, which means ensure that outsiders support them. In the private sector, this means that you're trying to ensure that people are still buying your shares and that people are still buying your shoes that you produce. And sometimes it's got nothing to do with how good your shares look or how good your shoes actually perform. It has to do with whether your company is perceived to be doing the right thing in terms of how it's managed and who it hires, et cetera, in the public sector. This is a really big problem. And this kind of search for legitimacy often clashes with the search for functionality because a lot of public sector organizations are assessed and rewarded based on what they look like rather than how they actually perform.
[00:01:51] Now, this creates a problem for a lot of the change processes in developing countries, especially when they are informed by international scripts about what you need to look like. In that situation many organizations or governments will try to meet the script. Meaning do well on the indicator set, even if it doesn't necessarily lead to them looking better. Now we suggest a completely different approach to doing reform. We basically say that you need to get legitimacy plus functionality and that the way in which you do that is by trying things, learning from those things, and then iterating again so that you can get better gradually over time.
[00:02:31] Let me give you an idea of kind of what we suggest and how the dominant model works. The dominant model would say, look, I as an organization or my own organization wants to become legitimate. So it looks good and we get support but also become functional. But at the moment, we're sitting down here where we don't have either. People think that we don't really do things that are worthwhile. And if we look at it, we don't really do things that are worthwhile. So we look around and people say, well, yes, what a solution looks like. There's a solution that Germany has and Germany use that solution and those fantastically well with it. So we think, well, maybe we're going to go all the way there and we're just going to adopt what the Germans have. The problem is that we don't know how to do that. So we end up just doing the thing that looks like Germany and it makes us legitimate for a period of time. But then we find out that we don't have any functionality and people say, what are you doing? You say, well, we're not Germany and you blame the Germans. Now, I suggest there is something completely different. We say, how about trying something in your cont ext to become a little bit more functional and then learning from that thing, getting some legitimacy from the lessons and the quick wins you get when you start iterating again with maybe a bigger step the next time around, learning again and getting legitimacy again and working your way up step by step until you get to the top. This is what we call iteration, and it's really important that as part of the iteration we get quick wins. It's really important that we have a lot of learning and we have feedback loops that allow us to take better steps the second time, the third time and the fourth time. And ultimately we're going to end up somewhere near where Germany is, but hopefully not looking exactly like the Germans, more like who we are.
[00:04:12] Could you walk us through the process of iteration? What is it and how does it work?
[00:04:18] So some people believe that you can solve really, really tricky problems by just coming up with a solution and just simply doing it. We don't really think that the world works like that. We think that you need to iterate. What is iterate mean? Well, it means that you need to take steps. Take steps doesn't mean taking thousands of years. It just means that you try something, you learn from the thing, you try something else, or you try a second version of that. You learn from that and then you finesse it. And over time you actually come up with a solution. I think we see it all over the place and we see it in our personal lives. I think we see it in more developed states and how they've emerged over time. Now people will say to me, well, how do you iterate? How does it work? Precisely. And what I thought I would do is just go through very, very quickly the exact process that I tend to use in countries. Some people who are familiar with action research will be familiar with this kind of approach because it's actually the approach that action researchers take when they are doing experiments with real people in real places. This isn't about controlled trials. It's about doing work with real people who have flesh and blood where things go right and things go wrong and where the things that you have to learn are things that you're not controlling and therefore that are surprising you at every turn. So let me tell you our start with probably you've heard me speak a lot about problems. And so I'm not going to go through the process of defining a problem, but that's really the starting point. It's working with the group to define the problem. When they define the problem, they break the problem down. They get empowered. They get inspired. And you start to say to them, what ideas do you have to actually solve the problem? They come up with some new ideas. And some of these ideas may be best practice ideas that they've seen in other places. That's fine. Some of them may be ideas that actually came from the past and people have given up on. That's fine. Some of the ideas may be crazy. That's also fine. It's actually better if you're dealing with a team and people are trying three or four different things and they say they're using those things to look for new ideas again and also to look for new information. The thing that I'll do very quickly out of this is I say to people, OK, what are you doing on Monday? What is the action that you're doing in the iteration that goes off to this discussion about the problems and the ideas? And this is something that many people don't get you when they do the kind of work that I do. A lot of design thinkers spend a lot of time designing the problem and designing the new ideas. But this jump to implementation is something that doesn't really happen. It's very important where I work that I have authorization to go beyond the conversation and into action, which means that someone has to authorize that the people involved in this conversation are going to be available to work on this project. Next week, next month and probably for six months to come. So the thing is that they get straight into action and action stage is really important. Everybody needs to have tasks. Everybody needs to be trying something of these new ideas and they need to be doing them quickly. Usually the first iteration I'll have will be two or three days or maximum of week. And then at the end of that time, you have your results, whatever they may be. Maybe people have gone out and they've had two conversations with people that they hadn't had before to gather new information. Maybe that was a key idea in a recent place I work. The key idea was, well, maybe we need to be speaking to another agency. They went and they spoke to the other agency. And at the end of the week, they came back and we had a conversation about what they learned in that process. Now I ask four questions about the learning, I say, what is it that you did? What is it that you learned? What are you having trouble with? And have you asked anybody for help? I asked that of all the individuals who are involved in this situation and also asked of the group. And then we get together and we talk about what it is that we learned that made a difference that we haven't done before. And we also take some of the results and we create a product for the authorized us so that they know that they are authorizing something that's moving in a positive direction. We may not have solved the problem, but we have some gains. We then move into a discussion about, well, did what we do solve the problem? And if the answer is yes, then we don't have to iterate again because we've completed our task. But if the answer is no, we go back into a second iteration, which may involve redefining the problem again, based on the new information we have, or it may just involve establishing a new set of ideas and then going straight back into action again, back into our experience of learning and then asking the question. What I found over time is that the iterative steps broaden because the set of actions becomes more expensive. Usually it'll go from a few days to a week to two weeks to a month, maybe to three months. This is where the hundred day approach comes in. But in my work, it comes in a few steps down the line. Always you're trying to learn. Always you trying to build authority. And always you focused on did we solve the problem? This is iteration. It's not something that takes a thousand years. It's something that can be done really quickly. In my experience, it's often done quicker. Then some of the donors prepare their projects.
[00:09:22] Thanks, Matt. Can you explain the process of designing the first iteration?
[00:09:28] So one of the things that is very different about PDIA and other projects is in PDIA your next step is always the one that matters the most. It's it's the the thing that you are going to specify and the thing that you're going to learn from your next step always leads to a next step afterwards. You're always going to have some idea about a trajectory that you think you're going to follow. But the next step is the one that is certain for you. So it's very important that you design that next step really, really well. Now, I'm going to speak about designing the first step of your iteration, because I'm not going to assume that people have done this before. In most projects the first step is always going to be one that is carefully constructed amongst the 100 different steps. And so that's why this is very different, because this is one specific incremental step that you're going to take and you're going to be designing it, knowing that it's incremental and knowing that you're going to be using it to learn things, you're going to be using it to build teams, you're going to be using it to try things out. So it's a little bit different to just saying it's the first step. In a sense, it is the only step at this time. It will be the thing that opens up the steps that come afterwards. The other things you need to think about when you designing the step is firstly, what are the ideas that you're going to act upon? You've heard us speak about multiple ideas. This is really about odds. You know, you don't know which path is going to get you there. You don't know which idea is going to is going to be paying off for you. You also don't know what you're going to learn if you tried different routes. So you need to be thinking in your first iteration how many ideas do I try, do I try two or three different teams with two or three different ideas, because I think I'm going to learn different things from them. Can I afford that or am I just locked into one. In most of the things that I try, I try to work with four or five different teams, partly because I feel that they can compete with a little bit with each other and you get some momentum going in. Momentum matters a lot. Partly also because the more you do, the more you learn and the more you learn, the quicker you move.
[00:11:23] So if you do one thing, you kind of lock yourself into any one line of learning. So the first thing in design is kind of how how many things do I want to act on? Which ideas am I going to act upon? The second thing is what's my timing going to look like? And what I mean here is how long are you going to spend between the day you start and the day you bring the teams together so that they can actually reflect on what they've learned? When I do the first iterations, I tend to try and make them really, really quick. Now, what do I mean by that? If I'm in-country and I'm working with the team, the first iteration sometimes can be a matter of hours. Sometimes we'll work with the team and say, what's the first step? And they'll say, the first step is we need to get data. And I'll say, well, let's go and get the data. And they'll say, see you in three months. And I say, why do you need three months? Let's reconvene in two hours. And they say, but we can't get the data in two hours. And I say, well, if we can't get the data in two hours, then that's an incredibly interesting thing for us to learn about, because in a lot of places you could. So if you can't, then we sit back and we say, why couldn't we get it in two hours?
[00:12:26] You may do it for a day, you may do it for two days, you may do it for three days. I would never leave the first iteration beyond a week. And one of the reasons is that in many of these places, people are used to having a substantive conversation and get excited about what they doing and then they don't reconvene for three months. Or they're used to ministers shouting at them and telling them to do things and then forgetting about those things. And so there's a learned ability here to not act after you get excited. What you want to do is you want to say you will do it. We will reconvene at this time in maximum seven days. And at that time we going to ask these questions. What did you achieve? What did you learn and what is next? Very important in the iteration. So we thinking about the design, we thinking about the timing. We also thinking about who's going to be involved. Oftentimes people will spend their time waiting on the first iteration until they have the perfect team. And I run into this. Some people say, well, who do you have in your teams? How do you know the right people? Here's the thing. We don't. Part of the iteration is actually about learning who the right people are. And what you find out is after the first week, some people come back and some people don't. Some people come back and haven't done any work and think that that's OK. And some people come back and they give really, really interesting looks to the others. Parts of your iterating process is finding out who the right people are. So you're not after perfection here. You're just after momentum, the starting point. So I would really encourage you identify your ideas, design steps that are really possible. And what I mean by that is make sure that there are no easy excuses for not doing that. If you tell people to do something or they commit to do something, and in the back of your mind, you're thinking. No, they can't do that. What I guarantee you is in a week's time, they're going to come and say, well, that was a stupid thing to tell us to do. No, we can't do that. Need to be practical, need to be possible. And you need to even negotiate with them and say to them, it's dumb it down, let's bring it down. Let's bring it down. So that it's really, really something that you feel that you can do that you can be empowered with. Part of the reason why you do that is when you have that meeting at the end of the first week. The more they can say, yes, we did it, the more you're going to build momentum for the second step. So take time and care in designing the first iteration because it is the step that opens up the next iteration and the next iteration and the next one.
[00:14:52] Thank you for listening to part eleven of the Practice of PDIA podcast series. Tune in to listen to part twelve where we discuss how we think about scale. To learn more about iteration in PDIA, download our toolkit at BSC.CID.Harvard.EDU.