How to design a new program

Designing a new program can be both challenging and rewarding. Challenging because it’s difficult to know if you’ve designed it the right way. Rewarding if your program ends up working (or discouraging if it ends up not working!).

There are plenty of manuals on how to design programs, like these ones from the IFRC and UNDP. The problem is that while most of the manuals are suitable for large scale programs, they can be “over-kill” for smaller programs or situations where you have limited time and resources.

This guide describes the minimum steps that you should follow when designing a new program. The steps can be done in a different order to the one presented here, or even in parallel if it suits your situation.

Find out what the problem is

The first step is to understand what problem it is that you want to solve. This normally involves some type of “needs assessment”, where you conduct a survey, interviews, focus groups and/or meetings with beneficiaries to find out what problems they are facing, the size of the problem, and how important they think the problem is.

Once you think you’ve identified the problem it can be helpful to do a Problem Tree Analysis to investigate the causes and effects. Start by writing the core problem in the middle of the board or flip chart paper. Then ask yourself: What is the cause of this problem? And what is the cause of that cause? Keep listing causes down the page so they become the roots of the tree, until you think you’ve reached the very bottom root cause. Then go back to the core problem and ask: What are the effects of this problem? And what are the effects of those effects? List them up the page to become the branches of the tree. The result will look something like the example below.

When you’re doing the problem tree analysis it’s best to involve all the members of the team, as well as some representatives from the beneficiaries you’re trying to help. I often find that people can have very different opinions about the causes and effects of a problem.

It’s also very important to verify that the problems in your problem tree actually exist. This can be done through a survey or by collecting other quantitative data. For example, I once worked on a program where community stakeholders believed one of the root causes of unplanned pregnancy was that husbands would not allow their wives to use family planning methods. However, after we did a survey to verify this we actually found that only 2% of women had this problem. So we removed it from the problem tree.

Find out who the stakeholders are

No program operates in a vacuum. So it’s essential that as part of the design process you identify all the other stakeholders who might be involved. The fancy name for this is “stakeholder mapping” or “stakeholder analysis”. Start by brainstorming all the stakeholders who might be related to your project. This includes government, beneficiaries, other NGOs, and even key individuals in the target communities.

Then have a meeting with each of the stakeholders, either together or separately. By the end of the meetings you should be able to answer the following questions about each stakeholder (you can record the answers in a table):

• Problem: What are the key problems they are facing?
• Motivation: What motivates them? What are they interested in?
• Potential: How could they contribute to solving the problems identified?
• Interaction: How can we best interact with them? (e.g. through meetings, reports, phone calls, etc)

Think about what resources and skills you have available

As part of the design process you also need to consider what your own organisations and team are capable of doing. What resources do you have available? What skills does the team currently have? This information will help determine the types of programs that you’re actually able to implement. For example, there’s no point designing a micro-finance intervention if your organisation doesn’t have any micro finance specialists.

One tool that some people like to use for this step is a SWOT analysis, which identifies the Strengths, Weaknesses, Opportunities and Threats to an organisation. While this tool can be useful, it is by no means mandatory for conducting this step. Often a frank discussion with all members of the team is enough to identify the resources and skills available for running the program.

Research which interventions are effective

This is one of the most critical steps, and is also the one most often missed. You are probably not the first organisation to try and address the problem you are working on. In fact, it’s likely that many other organisations have tried previously with a range of different approaches. There are several websites and databases where you can find the results of these previous programs. This will help you find out if a particular approach is likely to work before you waste money trying it.

At this stage you should also see if there are any existing Theories of Change related to your problem. A Theory of Change identifies all the possible pathways that might lead to change, and why they lead to change. Having a good Theory of Change that is based on previous research can be very helpful in identifying possible goals and interventions, which is the next step. If you’re not sure what a Theory of Change looks like, check out these examples from DFID.

Choose your goal and how to measure it

Once you know what the problem is, who the stakeholders are, what skills and resources you have available, and what people have already tried previously, it’s now possible to decide what the goal of your program should be. You could have just one goal, or you could have one goal plus several sub-objectives or outcomes.

One way to identify the goal and possible objectives is simply to reverse the statements in your problem tree from negative statements to positive ones. For example, “lack of awareness” becomes “increased awareness”, “increased deforestation” becomes “reduced deforestation”. An example of this is shown below. This example was created by reversing the statements in the previous problem tree.

Another way to identify possible goals and objectives is to look at the Theory of Change. This can help you identify which changes would be necessary in order to have an impact on the problem.

It’s usually a good idea to start by identifying all the different goals and objectives you could have, and then choosing which ones are most relevant and achievable given the available evidence and resources in your organisation. At this point you also need to decide how you will measure progress towards the goal and objectives. This will become part of your Monitoring & Evaluation Framework.

Identify which activities are likely to lead to the goal

Once you know what the goal and objectives of the program are, the next question is which activities are actually going to lead to the goal? At this point you should have a close look at the activities and results from previous programs run by other organisations. For example, if a previous program found that outreach workers were able to increase the use of fertilizer among small hold farmers then it might be worth trying that activity. However, if several previous programs found that outreach workers had no impact on the use of fertilizer then perhaps it’s best to try another approach.

Although this seems simple enough, in practice many organisations don’t bother to look at the previous evidence before they choose their activities. As a result, a lot of money and time are wasted on interventions that are known not to work. Of course, in some cases there might not be any previous evidence, or perhaps you’ve come up with a completely new approach that hasn’t been tried before. In that case you could always pilot the approach to see if it works before scaling it up.

For each activity you normally need to identify the activity itself, as well as the output of the activity. For example, if they activity is to run 10 training sessions for 30 people each, then the output would be 300 trained people.

Create the documentation

The final step in the process is to create the documents that you need to describe the program. These documents are normally required by donors, but they are also useful for explaining how the program works to stakeholders and team members. Below is a list of key documents that you need to complete, with links to templates:

• Logical Framework: This describes how the program activities will lead to the immediate outputs, and how these will lead to the objectives/outcomes and goal.
• Monitoring & Evaluation Framework:  This describes the indicators that are used to measure whether the program is a success.
• Workplan: This shows all the activities involved in the program, who is responsible for each activity, and when the activities will be completed.

I personally like to put all these key documents, along with the problem tree, details of stakeholders and Theory of Change into a single Program Manual. This then becomes the “bible” for the program.

Be flexible

Now that your program is designed you’re ready for the next step – implementation. The most important thing to remember during implementation is to be flexible. If something doesn’t work according to the plan, or if you aren’t getting the results you expected, then change the program design. There’s no point wasting time and money on a program that isn’t working.

Unfortunately many organisations stick rigidly to their original plans because they’re afraid that donors will take away funding if they change their approach. While this may certainly be true for some donors, in my experience most donors are happy for you to change the program design if things aren’t working, as long as you let them know in advance.

Photo by City of Seattle Community Tech