📐Designing Initiatives and Writing Proposals

From idea to problem statement

A project that starts with "we want to help young people" does not know what success looks like.

Many initiatives start with good intent and a general idea: "we want to support youth in our neighbourhood," or "there is an employment problem and we must do something." The intent is excellent, but a general idea cannot be planned, assessed after it finishes, or evaluated for its results. The problem is not that the intent is poor; the problem is that "the employment problem" describes a symptom, not the real issue. Young people who do not know how to write a CV? Employers who do not trust graduates of certain programmes? Jobs that exist but in sectors young people do not know about? Three entirely different problems, each needing a different intervention, different resources, and different partners. A good problem statement answers five questions: what exactly is happening? To whom? Exactly where? Since when? And at what known scale so far? When you can answer those questions with numbers, names, places and sources, you have a problem you can work from and defend to a funder or partner.

1. Start with what you observed: write one sentence describing what you saw with your own eyes or heard from people living the situation — this is your raw material
2. Ask "why does this happen?" at least three times, writing a different answer each time — each answer takes you a layer deeper toward the root cause
3. Define who is affected precisely: not "youth" but "18–25 year olds in the Baalbek area who graduated a year ago without finding work"
4. Look for numbers or evidence to support your observation, even informal — a small survey, a municipal statistic, or ten short interviews give you numbers better than nothing
5. Find out what has been tried before in this context and what happened — do not start from zero if someone has already worked on this problem and succeeded or failed
6. Write the problem statement in four sentences: what is happening, who is affected, how large it is, and the root cause you identified

• Can you read the problem statement to someone unfamiliar with the subject and they understand the point in one sentence? — if it needs explanation, it is not ready
• Does the sentence point to a specific cause or factor? — describing the situation is not enough; you must point to what keeps it in place
• Can you tell precisely who is affected? — "people" or "the community" are expressions too broad to build an intervention on
• Are there numbers or data to support it? — even informal data is better than nothing because it turns an observation into a verifiable claim
• Does the statement distinguish between the problem and the solution? — "lack of libraries" is a cause claim; "we will build a library" is a solution — do not mix them

Objective, outcomes and outputs

Confusing these three concepts is the most common reason proposals are rejected by funders.

Imagine a project that trains a hundred young people in CV writing and interview skills. At the end, the project report writes: "we successfully trained a hundred young people." The question: did the project succeed? You do not know. Training a hundred young people is an output — something the project directly produced. The outcome is what changed in those young people's lives because of the training: did they actually apply for jobs? Were twenty of them accepted for interviews within six months? Did their income rise? And the objective is broader: what does this employment mean for the neighbourhood or area in the long run — a lower youth unemployment rate, a more economically stable community? A good project draws a clear line between what it will produce (outputs), what will change (outcomes), and what it wants to help achieve in the long run (objective). Each level needs an indicator that tells you in numbers whether you have arrived.

Needs analysis and target group

A project that never asked its beneficiaries what they need will deliver what you thought they needed.

Needs analysis is not a formal step you write into the proposal to satisfy the funder. It is the difference between a project that solves a real problem and a project that keeps people busy with activities they do not need. Organisations that do needs analysis well discover things that surprise them: the mothers assumed to need nutrition training say their main problem is insufficient income, not insufficient knowledge — meaning a nutrition course alone will change nothing. The young people assumed to want technical courses say they want a space to build professional networks because their network is what opens doors to the labour market. This does not mean that everything people say is everything they need; sometimes there is a need people do not see a connection to what they are reporting. But a good project does not assume — it investigates methodically, then designs on the basis of what it found.

1. Define exactly who you are serving before asking them anything — the age group, gender, location, economic situation, and particular circumstances
2. Collect primary data directly from the target group: individual interviews with 6–10 people, a small focus group, or a short survey — listen more than you speak
3. Collect secondary data from existing sources: studies and reports about the area or group, even if relatively dated — they give you context you cannot gather alone
4. Find out what others are doing in the same field and area: are there similar projects running now? What are their results? Will you complement them or overlap and waste resources?
5. Categorise the needs: what is acute and urgent? What is important but can wait? What can your initiative realistically address with available resources?
6. Return to a sample of beneficiaries with your understanding and verify: "this is what we understood to be the core problem — does it match what you are living?" A negative answer is better than a surprise after signing

• Who are the direct beneficiaries? — those who interact directly with your project and receive the service or training
• Who are the indirect beneficiaries? — those whose situation improves because of the change in the direct beneficiary's life: their family, their neighbourhood, their employer
• What prevents the target group from solving the problem themselves? — economic barriers? Cultural? Geographic? Legal?
• Is the target group homogeneous or does it contain sub-groups needing different approaches? — for example "youth" may mean very different groups in terms of education, gender, and need
• Who are the most vulnerable within the target group? And how will you ensure the project actually reaches them, not just those who are easiest to reach?
• Will the need end when the project ends? Or does the structural challenge continue and must continuity and transition be planned from the beginning?

• Field observation: spend two hours in the place you will work before asking any question — what you see with your own eyes sometimes differs from what people say when asked
• Semi-structured interview: prepare five open questions as guiding prompts, but follow what the speaker mentions rather than just the question order
• Focus group discussion: bring 6–8 people from the target group and push them toward dialogue rather than just answering questions — dialogue reveals contradictions and priorities that do not appear in individual interviews
• Short survey: effective when you want to measure the prevalence of a problem on a wider sample, but unsuitable for exploring details — use it after interviews, not instead of them
• Records and reports review: municipal reports, school records, health statistics — secondary data that may give you numbers you could not collect yourself

Implementation plan and timeline

The timeline does not only organise time — it reveals contradictions in the plan before you begin.

Many projects are written with an apparently logical order, but when the timeline is drawn, problems become visible that were not there before: two major activities at the same time both needing the same team, or a training planned for August which is the holiday month in the schools where it will be held, or a data collection phase that reads in the schedule as a week when in reality it will take three. A good timeline is not a list of activities with dates beside them — it is a thinking tool that forces you to answer: who exactly does this, how much time does it actually need, and what must be completed first for it to start? The connected lines in the schedule reveal dependencies, and these dependencies are the primary source of delays in projects.

1. Full activity list: write every activity in the project including small ones — signing contracts, hiring, communicating with partners are not trivial activities but take real time
2. Activity sequencing: define what must be completed before each activity starts — "the team cannot be trained before it is hired" is an obvious dependency; look for the non-obvious ones too
3. Duration estimates: how many weeks or months does each activity actually take? Start with your estimate then multiply by 1.3 — most activities take longer than we estimate
4. Responsibility assignment: write the name of the person or entity responsible for each activity, not just the job title, so it is clear who is accountable
5. Milestones: identify 4–6 key review points during the project — moments when you decide "does what we have achieved so far allow us to proceed as planned?"
6. Time buffer: leave at least two weeks at the end of the project as reserve — not laziness, but because every project faces at least one unexpected event

The concept note and simplified proposal

A concept note is two pages to test the idea with the funder before investing weeks in writing a full proposal that may be rejected for a reason discoverable in a day.

Many new organisations spend weeks writing a detailed twenty-page proposal, then discover that the target funder does not fund this type of intervention at all, or that the project geography is outside their current priorities, or that they require the organisation to have been registered for at least two years. The concept note exists to avoid this waste: you write a short document of one to three pages presenting the idea at its core and send it to the funder before fully investing in writing the proposal. If the funder gives you the green light or invites you to submit a full proposal, you begin the detailed writing knowing the idea is suitable in principle. Some funders require the concept note as a first stage to select who is invited for a full proposal — they too want to save everyone's time.

1. Title and summary sentence: project name and one sentence saying what it does, for whom, and why now
2. Problem statement: half a page built on data — the current situation, who is affected, and at what scale
3. Proposed approach: how will you address the problem? What are the main activities? Why this approach specifically?
4. Target group: who are you serving? How many? And how exactly will you reach them?
5. Expected results: what will be different by the project's end? With measurable indicators
6. Indicative budget: one figure or estimated range — no detail at this stage
7. Duration: from when to when, with a note that adjustment is possible
8. Who you are: two sentences on the organisation and previous relevant experience in the field or area

For the initial budget in the concept note stage, absolute accounting precision is not required — honest estimation is. Organisations that specify an inflated budget put the funder off. Those that set a deflated budget then request repeated revisions lose credibility. A practical approach: list the major budget lines — human resources, transport, materials, general operations — and estimate each realistically. For human resources: how many days or hours of work from each person, and what is the realistic daily rate in your context? For materials: enquire about actual prices instead of guessing. Then add a 10–15% contingency for emergencies and price fluctuations. This contingency is not inflation — it is honesty with yourself that you do not know everything in advance.

Risks, assumptions and success indicators

A project that did not write its risks before starting will discover them after starting, at the worst possible moment.

Writing risks and assumptions before beginning project implementation is neither pessimism nor empty bureaucracy — it is the difference between a team surprised by obstacles and a team that had thought about them and prepared alternatives. Every project rests on silent assumptions: we assume beneficiaries will come at the set times, we assume the local partner will honour its commitments, we assume prices will not rise sharply, we assume the political situation will remain stable. These assumptions are not necessarily wrong, but if they are not written they are not tested and no contingency plans are made for them. A risk is the possibility of an event outside your control that may affect the project. An assumption is a condition that must be true for the next part of the project to work as planned. The practical difference: you manage a risk with a prepared contingency plan; you monitor an assumption regularly and act when it proves no longer true.

1. Generate a list of everything that could go wrong: gather the team and together list every possible obstacle — no filtering at this stage, every idea is welcome
2. For each possible risk, estimate the likelihood of it occurring (high / medium / low) and its potential impact on the project (serious / moderate / marginal)
3. Focus your resources on risks with high likelihood and serious impact — these need real, specific contingency plans with named people and defined actions
4. For each priority risk: define an early warning sign that tells you the risk is materialising, and a contingency plan ready if it does
5. For each assumption: define an indicator telling you the assumption still holds, and set a review frequency (monthly? fortnightly?)
6. Document all of this in a simple risk register — a table with rows and columns — and review it at every periodic progress meeting

• A success indicator answers: how do we know we achieved what we promised? — if the indicator has no clear answer, it is not an indicator
• A good indicator specifies four things: quantity (how much?), level (to what quality?), timing (by when?), and group (for whom?)
• Make your indicators verifiable by multiple means: attendance records, a post-programme survey, a field visit — do not rely on one source because multiple verification sources give a more accurate picture
• Avoid satisfaction-opinion indicators: "beneficiaries expressed high satisfaction" is an opinion, not evidence of actual change — satisfaction with the experience does not necessarily mean a skill gained or a behaviour changed
• Set a baseline before starting: what is the level of the situation now, before your intervention? — without this you cannot know how far you moved or in which direction
• Set a maximum of 5–7 indicators for the whole project — too many indicators are not measured well and turn monitoring into a burden rather than a tool