The Project and the Lake
A story of the man who threw a stone
There are so many subtle distinctions in the international development sector when it comes to project management. We’ve talked about some of them in previous blogs. In this one, I want to examine The Project itself, and how it is distinct in the context of the international aid framework. So let’s get right into it!
In this simple visual - we see that a project is made up of different Inputs (like materials, money, sweat equity, etc.). These inputs are then utilized or spent over a specific timeline (which is finite). The result of that action of spending (or implementing) is something that is immediate, often tangible or measurable right away; maybe even something that you can touch. This is your Output from those set of activities and in most projects leading up to the mid-90’s, that was quite enough to report on to most donors. "I did the activities, I completed the activities and have some outputs to show for the money you gave me."
Here’s a concrete example:
I give you some money to build a well, you build the well in the prescribed timeline. Done!
This simple process is what led to the equally simple definition of The Project. It is:
"A temporary endeavour undertaken to create a unique product, service or result. It is agreed on, planned and executed to achieve a specific goal through a series of inter-related tasks!" (Project Management Institute, PMI).
It Unshackled my understanding of project management!
Unfortunately, The Project in international development got a lot more complicated from there – Sorry! It started back in the 80’s with a big commotion over a project blueprint approach versus a process approach. Essentially, what we now know as Results Based Management (RBM).
RBM is a method by which we can look beyond processes, activities, products & services and instead, examine the social and economic results (often longer term) of projects. It emerged from the idea that projects should facilitate continuous learning and interaction! This would allow managers to adjust and modify projects as they go along, allowing local context to drive change; using what we now call ‘adaptive management.’ If you want to read more about this foundational RBM discussion, you can click on this article, written by yours truly. https://www.thegrantshouse.com/product-page/journal-article-the-project . Yes, I was giving out grants in the 90's whilst working at UNDP, and talking about the development of projects and grants even back then!
And I was privileged to be part of the early discussions on RBM at CIDA (now GAC) – but please do not blame me for it! I had discovered the unique flexibility offered by development projects, (as opposed to blueprint projects) being able to respond to changes in my environment, in staffing, in funding, in policies and all those lovely things that are often outside of your direct control as a Project Manager. Since I worked mostly in conflict affected areas – this discovery unshackled my understanding of project management. But it also challenged my core training when I was preparing to become a project manager.
Another layer of complexity?
Anyway, here's where The (development) Project definition gets even more fun – and confusing! If we look back at the previous diagram, we can observe that after those Outputs are realized, there are a set of results referred to as Immediate Outcomes. Actually, these are give-away results in the design of your project because they essentially happen at the same time as your Outputs. Always think of it that way when you’re writing your next grant proposal or designing a logic model.
If you just built that Water Well I paid for, then you have essentially given Access to a lot of people in those villages nearby. It happened as soon as you drew the first gallon of water from it.
So tell me about it in your proposal. How many people are accessing the well, what types of people (ages, adults, children, gender?), where are they from, how do they get there, etc.? In the past, that too would have been more than enough results to call it a day and move on to the next project. But RBM is a demanding task master, and it wants to know more. So we have to apply some analysis in our grant funded project designs. This is where the Intermediate Outcome came in; and our lives as program and grants officers got a lot more complicated.
The Behavioural Change Element of The Project
When the Intermediate Outcome was included in project grant calls, it basically stated that there will be ‘behavioural changes’ that the donor wants to know about. It’s not enough that we built that Well or gave access to clean water to 1,000 people in a community.
Cause and Effect?
Now, donors started asking tricky questions about measurable and describable change from those results. This demanded that we start looking at ‘cause-and-effect’ relationships in The Project. In other words, “what happens to those people who have access to the water wells? Does it actually make any difference in their health and nutrition, in their livelihoods, in reducing drudgery for women, does it reduce the incidence of disease?” - and so on. The questions just got a lot tougher for the designer, the planner and the implementer.
And these are not quick results. In fact, a whole new set of activities had to be incorporated into your project to get to that next level. The activities that helped you build the well, aren't going to be helpful in making change at a behavioural level. For instance, you need to know if people are boiling their water before drinking it, are they covering the vessels it’s stored in, are they washing their hands before eating, etc. So you will need to start building activities into your plan that will be effective in steering that change with the community stakeholders.
And the most important thing to remember is that it doesn’t happen overnight. While a person’s basic needs might be satisfied by building that Water Well, they don’t necessarily change their behaviour right away or fulfil any higher hierarchy of needs. Yes, I realize that I put Wi-Fi at the top of my needs in the photo.
So, the project results have to be tracked and reported over a longer length of time. Your 4-month project is now possibly 3 years and you are no longer as interested in the Water Well as you are about it's impact on the lives of people on a deeper level. There are some great organizations who have delivered the basic needs of clean water and sanitation for decades - but who are now contributing to gender equality, climate resilience and food security as part of a wider impact of their important work.
I just wanted to build a well!
Let's say that a donor came to visit your increasingly complex Water Well project and declared – “you know what – what we really need to do is track and reduce the incidence of Child Mortality in a community.” And their team of health specialists poured in and described how we now need to track health metrics, nutrition (vitamins and micronutrients), maternal health, inoculations and sanitation metrics. Half of our staff started getting their CVs ready and decided they hadn't signed up for this. The other half was determined that this was achievable and, in fact, it had been an 'unexpected outcome' of all of their previous Water Well projects over the years - so they asked, "why isn't it part of our normal project design?"
And while I was absorbing all of this, I thought: I just wanted to build a well! At this point, the Ultimate Outcome was born. But again, herein resided a big problem for the development sector. So I asked my staff, "How does one singular project contribute to something so big?"
Finite but not Forgotten!
So we took a breath and considered that an outcome that lofty couldn't be done in the short span of time of our project. We also realized that there was a big technical problem for the management team of The Project. Remember that pesky characteristic of a Project I mentioned earlier? It’s finite!
All projects, by definition, have a definitive end-date. And if, by the end of the project, we are unable to measure changes in people’s behaviour – and even further, a reduction of child mortality, then how are "we" as Project Managers supposed to be accountable for it? Remember that another characteristic of a project is that the management cycle starts once a Project Manager is hired and becomes accountable. Once the project manager leaves at the closing phase, by definition it ceases to be in the project management cycle. I realize that by now you are probably thinking that I am being very pedantic about definitions but it is important to understanding the nature of a project and how we manage them in a development context.
No Beans to Count
After the project closes, we can’t count the ‘beans’ (the activities and outputs). We also can't report that we did everything that we said we would, with evidence and data to back it up. After all, we've closed the project, submitted the final report and all of our staff have left to do other water projects. From the RBM method perspective, this is where we now have to be strategic – and we have to have a set of pretty robust ‘assumptions.’ For the first time, since RBM started, Project Managers had to relay outcomes from their project that they may never see in their tenure as a Project Manager. Intermediate outcomes can take up to 3 years to materialize and ultimate outcomes may take longer – which is usually after the project is finished.
My Project didn't fully achieve the stated ultimate goal?
In fact, for the professional project manager, getting his or her mind around those results not fully materializing at the end of the project gets even more concerning. That is because your project may not be able to attribute its outcomes solely to the activities that contributed to reducing child mortality. What? Didn't we say that, by definition, a project is "to achieve a specific goal through a series of interrelated tasks!?!" Now I'm saying that the project may not have fully contributed to reaching that goal?
Well, consider it this way - there are a lot of other projects being implemented in the neighbourhood of your Water Well+ project and the community stakeholders are doing a lot of the work as well, because they’re the ones doing the behaviour changing. Our project is likely only one of many acting as catalysts in the change process - albeit an important one perhaps. Because our results may come after the project closes and we may not be able to attribute our project fully to achieving the ultimate outcome, we will have to have some very convincing ASSUMPTIONS to show the donor. This is where I recommend a strong logic model and an equally strong Theory of Change in your Grants Proposal design.
IF this happens – THEN that is likely to happen!
Along with a clear problem statement (or development challenge), usually done through community consultations, our Causality Analysis is going to be one of the first things we do as Grant Writers in order establish the results (cause and effect). What I mean is - Ask the question, “If this happens – then that is likely to happen?” We all learned this way of thinking from a very early age.
Remember your Mother saying, “If you eat too many chocolate bars, then you’re going to get sick!”? That’s causality and your Mom can walk away from your room, where you just consumed 10 chocolate bars and even though you feel great right now, she will probably start preparing some medicine in anticipation of the likely result. Unfortunately, the higher up you go in your results chain, the more unpredictable it becomes, the less control you have as a project manager, and the more planning you’ll need to do to determine the outcomes. Thankfully - this is where the “Theory of Change” comes into play when you’re writing your grant proposal: a useful addition to the RBM toolkit. And I came to really understand this concept when I was 6 years old - skipping rocks on the Touqian River, in Hsinchu, Taiwan. I just didn't know it at the time!
Splash and Ripple
Let’s look at this element of project unpredictability in a bit more detail because it is one of the most complex aspects of developing a project in the international aid sector. It's also one of the biggest headaches for project managers.
Imagine you’re out by a lake or river one day and you decide to throw some stones into the water. I’m sure you’ve tried it. Let me describe the ‘stone’ as a material INPUT into a project (imagine, then, that you’re the human resource input). When you throw the stone in, you have created an ACTIVITY. When the stone impacts the water, it creates a splash – and that is your OUTPUT. It’s the immediate effect and first level result from your activity of throwing the stone. It happens right away! And you likely were pretty satisfied with it and decided to throw another one. But there are also ripples from that splash.
As a 6-year old, I was delighted by this result from the thrill of throwing a rock at the surface of the water. The ripples that resulted from the stone impact on the water could be considered as your OUTCOMES. And the farther out those ripples go, the higher the outcome result and the more unpredictable the shape and intensity of those ripples are. If you look around the environment, you might notice boulders in the water, water plants, sand-bars, or even crocodiles in some places! All of these environmental issues may impact how those ripples respond from that initial impact.
Time, Reach, Control, Context and Learning
As such, there are 5 important lessons about Project Management that we can take away from this Splash and Ripple analogy: Time, Reach, Control, Context and Learning.
1. The Time variable provides us a finite period in which we could throw the stone, achieve the output of our splash and even get the ripples going, which was the intent of the activity. But if you walk away from the water, you can be assured that those ripples will continue to sweep across the water with or without further input from you. Some of them might even be imperceptible but you can be sure that it had an impact on the water ecosystem.
2. The Reach variable has two parts: First, the splash was a localized impact and involved direct input from you. It got a reaction from the wildlife in the immediate area and jolted a few marine animals. However, the second part or effect – the ripples - moved across the water, impacting more of the area. You could say, in fact, that the initial impact fundamentally changed the surface of the water far beyond the limited splash impact that you first observed.
3. The Control variable speaks directly to the ability to manipulate results as a Project Manager. For instance, we can control the immediate splash – that’s easy! I’ve played around with direction and aim, how hard I throw the stone and at what angle. We can even predict, to some extent, the shape and duration of the ripples – but we can’t control them. This is where the ‘cause-and-effect’ chain reaction happens. Remember, “IF I do THIS, then THAT happens.
4. Our Context is first defined by the boundaries of the lake but it is also governed by obstacles and other disturbances or forces at play; the frog that leapt clear of the splash, the rock peeking above the surface, the fish scattering out of the way or the water current at that time of day. Imagine – if we’re able to predict those extraneous factors, we might be able to improve the ripples' shape, force and direction more effectively. This means we would need to address obstacles, barriers, influencers, and constraints and, identify our enablers (maybe the current, in this analogy, carries the ripples further). Ultimately, when the ripples reach their furthest boundary line, you’ve established your Ultimate Outcome. And while there isn’t an absolute certainty that you can reach it or that your stone-throwing helped it get all the way to its furthest point – you can certainly claim that you influenced it!
5. Our Learning (and improvement) variable is how we modify our methodology and approach in order to change an outcome – that's the adaptive management approach that I spoke about earlier. Have you ever thrown a stone into a lake a few times and noticed that each time is different from the one before? You begin to learn that the angle, the force with which you throw, the weight or size of the stone are all influential in predicting how the splash & ripple will result from the impact of the stone. And quite frankly – it’s fun for all ages to do it! I highly recommend you do! I remember conducting that experiment as a kid – throwing a great big brick in the water and then throwing some stones of different sizes that I had piled up. The more you know about those different variables, the easier it is for you to control what kind of splash and ripple you’ll have as your project results. You'll develop some assumptions (as described above), you'll develop a pattern of activities from experience, you'll establish some preconditions to determine outcomes, and so on.
These Outcomes Aren’t Part of The Project!
The entirety of this analogy applies to the principles of designing and managing an international development project. However, the problem for the ‘purist project manager’ is that many development projects don’t fit within the classic definition of “The Project.” As I mentioned earlier, Project activities, by definition, can’t continue after the project has closed (even if through traditional sustainability models of community or government support). However, through experience and a carefully designed RBM model, we can establish outputs and outcomes that are built on assumptions, informed by evidence, and which predict logical results. If I do this...then... (this will happen).
This is what the modern donor is looking for when they review your proposal. How carefully have you laid out your theory of change and is it convincing - and logical? They know that the project is finite and they know that it won't achieve the ultimate outcome all by itself. But they will depend on you, as the implementer, to explain the results and to report on the contribution that their project has made on the higher behavioural change outcomes - with data during the project cycle and with assumptions (or post-evaluation follow-ups) as to what happens after the project is closed. Unfortunately, many proposals do not explain the cause-and-effect relationships of their outputs to outcomes sufficiently and so it becomes a little fuzzy as to what is being proposed. These projects are rarely funded.
The Project Manager goes home after the ‘closure phase’ of a project. Thus, by definition, there is no longer a project management cycle in play. And unless we do some post-evaluations of our projects (or the donor does) or we roll the project into a larger program, we won’t know if the results have been achieved either (except maybe anecdotally). So our purist project manager might say “this higher achievement result is not part of the project.” And yet - surprise - it is! And you will need to go back to your theory of change logic and predict the results and behaviour that are likely to occur 'after' your project is closed.
My Project is Not Finite?
We use some great tools and methods, like the causal or critical pathway analysis, the problem tree, the logic model, etc. That is because the more we know about the enablers, the constraints, barriers and forces in the community and government, the easier to predict what outcomes we might expect. And then we can form those all-important assumptions and pre-conditions as we do the project design.
Eventually, we will be able to create what RBM defines as a “results chain.” Basically, a chain reaction that starts from inputs and leads to outcomes – just like our ripple analogy. This is also why it is incredibly important for us to consult and work with the community – those living in the environment, day by day – to properly form our assumptions and our preconditions when we develop the project strategy. We need to understand the boundaries of our body of water and those things which might affect our activities before we can make some educated guesses about the result of skipping those stones. That comes from in-depth community consultations with our stakeholders. Ultimately, they are the key change-makers and the ones who will have the biggest influence on the results of their project – and benefit from them.
From that perspective - despite the classic definition provided by the Project Management Institute and what we learned in school - the social, economic, advocacy, rights, livelihoods security (and numerous other) projects DO (or should) go on and are NOT FINITE every time! It’s why donors are impressing on implementing agencies just how important it is to have clear Theories of Change, consultations with stakeholders and sustainability strategies, so that we can assure them that – in the words of the Titanic Theme Song – Our Project “will go on!”
Happy Grants Hunting!
I'm Dr. Phil Tanner, founder of The Grants House. Don't forget to check out our proprietary training courses!
And don't forget to give us a thumbs up when you read this blog and let us know if you want to hear more about RBM and other unique features of Projects in International Development.
@The Grants House, 2023
1-416-456-4718