🔎Community Needs Assessment and Accountability

Assumed need vs expressed need

The starting point of any community programme is not what the supporting organisation believes, but what the community itself says when genuinely given the chance to speak.

When a humanitarian or voluntary organisation enters a community, it usually carries pre-formed ideas about what that community needs. These may be grounded in national statistics, previous experience in similar areas, or studies conducted in different contexts. But the assumed need — what the organisation supposes without asking — is not necessarily what the people in this specific neighbourhood with this specific family at this specific moment are living. The difference is not philosophical; it is entirely practical. A food-distribution programme set up in an area where people lack income rather than food will change nothing lasting. A health-awareness campaign designed for diseases that are common nationally but rare in this environment will spend the team's time and the community's trust for nothing. Most dangerously, a programme built on a wrong assumption teaches the community that organisations that come do not listen, and when a suitable programme comes later it will face a wall of scepticism that we ourselves built.

The expressed need is what people say when genuinely given the chance to speak: in suitable conditions, in their own language, with assurance that their answer will not harm them and that a real person will hear and respond. That last condition matters more than it seems: people quickly learn there is no point in answering if nothing ever changes. One common error is to believe that asking "what do you need?" at the end of a group meeting constitutes an assessment. In meetings, people speak in line with what is socially acceptable, what they think the organisation wants to hear, and what the most influential person in the room is saying. Genuine expression needs a context designed for it.

• Assumed: "Families need literacy classes" — Expressed reality: "Mothers need childcare during the class"
• Assumed: "Young people need vocational training" — Expressed reality: "Young people need a professional network connecting them to employers"
• Assumed: "Older adults need home health visits" — Expressed reality: "They need social connection, not medical care"
• Assumed: "Children need school supplies" — Expressed reality: "The main need is transport to and from school"

Data-collection tools — choosing the right one

Every tool gives you information that no other tool can in the right context. The error is not the tool — it is picking the wrong tool for the wrong question.

Community data collection is not a single procedure but a set of tools the team selects based on the type of question it wants to answer and the nature of the community it is working with. The wrong tool does not only give you poor data; sometimes it gives you data that looks good but is misleading, which is far more dangerous. A survey asking "do you attend sessions regularly?" will usually get a "yes" because people tend toward the socially acceptable answer. An individual interview asking "tell me about the last time you missed a session" will give you the real reason.

The most reliable methodologies triangulate: they use more than one tool on the same group and check whether survey answers are consistent with what people said in interviews. When results conflict, the surprise is more useful than agreement — conflict signals that the right question has not been asked yet. With the limited resources most volunteer teams have, perfection is not needed: two or three individual interviews with one focus group is far better than relying only on the team's impression.

Designing questions and avoiding bias

A poor question gives you an answer — but an answer to someone else's question, not your own.

Designing questions is a learnable skill, and it is not only about choosing words; it is about defining what you actually want to know and then finding the shortest path to that knowledge without inserting your own assumptions along the way. The most common question-design errors are leading questions — those that hint at the expected answer through their phrasing. "Do you think this useful programme will help your family?" is a leading question. "What is your view of this programme?" is an open one. The difference in answers is enormous.

Bias does not come from phrasing alone; it also comes from circumstance. When you conduct an interview at the organisation's offices, you receive different answers than if you had it in the person's home or a neutral location. When the interviewer shares the gender or background of the interviewee, people speak more openly on some topics. And when you conduct the interview in the presence of another person — a spouse, a supervisor, a teacher — the answers change because people are not answering the researcher but answering in front of a witness. The team's duty is to design the collection circumstances consciously before the collection, not after.

Selecting participants fairly

Who you choose to speak with ultimately decides who you are working for. The easiest access is not the fairest access.

In every needs assessment, the team faces a practical question: who do we speak to? The easy — and therefore dangerous — answer is to speak with whoever is readily available, whoever welcomes you, whoever is socially visible and accustomed to meetings. This choice produces an assessment reflecting the needs of the most accessible group, which is usually the least vulnerable and the least in need. Those who need help most remain outside every assessment because they are outside the circle of the visible.

Fair selection begins with a clear definition of the target community: who are all those who will be affected by or are intended to benefit from the programme? Then ask: do our participants represent that definition, or only part of it? Who are we not hearing? And why are we not hearing them? The answer to "why" matters because the reasons differ and so does the fix. Someone not heard because they are geographically distant needs you to go to them. Someone not heard because they fear consequences of speaking needs confidentiality guarantees. Someone not heard because they speak a different language needs an interpreter. Someone not heard because your meetings are at times when they work needs different times. Absence is not always a choice — usually it is a barrier that has not been removed.

• Define eligibility criteria beforehand and publish them in plain language before work begins, in a visible place
• Actively seek out the absent: speak with teachers, doctors, and neighbours about those who do not know the programme exists
• Vary the times and locations of collection sessions to reach those who cannot come to one time and one place
• Check the representation of women, young people, older adults, people with disabilities, and minorities separately
• When you hit an access barrier, document it and do not overlook it; find a community partner who can bridge the gap
• After data collection, compare the composition of your participants against the original definition and understand the gaps before preparing the report

Opening a complaints channel and accountability

Someone who cannot file a complaint is not a beneficiary in any real sense — they are a target of a programme that does not ask their view.

Community accountability begins with a simple question: can someone harmed by our programme tell us so in a way that costs them nothing and exposes them to no risk? In most programmes, if we are honest with ourselves, the answer is no. Complaining in many cultures requires social courage that not everyone has, and is usually directed at someone in authority — two conditions that keep most real problems suppressed. The apparent satisfaction in an evaluation of a programme without a safe complaints mechanism does not reflect genuine satisfaction; it reflects that people have learned that speaking up does not help.

An effective complaints mechanism does not wait for people to come to it; it goes to them, tells them about it, makes it easy to use, and proves through visible action that it works. That last part is the hardest: people use complaints channels when they see that previous complaints actually changed something, and stop when they see them disappear into unknown air. Building trust starts with the first case: the first complaint you receive, how you respond to it, how long you take to respond, and whether the response reaches the person — this will decide whether anyone complains a second time.

1. Decide which channels are available: a paper box, a dedicated phone number, WhatsApp, email, and a face-to-face option with a named person — there must be an option for those who cannot read or write
2. Announce the channel out loud at the start of every activity, on visible signs in plain language that explains how it works
3. Appoint a named responsible person who receives complaints and keeps a written record of them and the dates received
4. Set a maximum response time and write it in the public space — five working days is reasonable for most complaints — and tell the person who filed the complaint how long to expect
5. Reply to every complaint, including those you cannot resolve: "We received this, but it is outside our authority, and we have referred it to [party]" is a complete reply
6. Review complaints monthly as a group to see whether a recurring pattern points to a structural problem rather than an individual case

Closing the feedback loop

Hearing a complaint is half the journey — closing the loop is what teaches people that their voice lands and that the listening is real.

Closing the feedback loop means that the person who filed a complaint or observation receives a real response proving that what they said was read, understood, and acted upon. This response might be "we corrected the problem you mentioned", or "we cannot change this for these reasons", or "we have referred your request to the relevant party". What is not acceptable is silence — and what is worse than silence is "thank you for your valuable observation" without any action, because that kind of response convinces people they were soothed rather than heard.

Many teams prioritise gathering feedback and neglect responding to it. This pattern teaches the community that its participation is merely data collected for the team's purposes or donor reports, not a voice worth acknowledging. The predictable result in the next round: greater reluctance to participate, less frank answers, and less trust in the organisation overall. Building trust takes months while destroying it takes one instance that proves the organisation does not really listen.

• Send an acknowledgement as soon as the complaint is logged — you do not need an immediate answer, but the receipt proves you heard
• Keep a central record linking every complaint to a decision: addressed, under review, referred — with a date for each
• A response that does not reach the person is an incomplete response: ask which contact method they prefer, not which you prefer
• Explain the reasons when you cannot make a change: an honest "no" with explanation is far better than a promise that does not materialise
• Set aside fifteen minutes each month to review closed complaints and verify that solutions were actually implemented, not only recorded
• In community settings, a public response — a sign saying "we heard your feedback about X and changed Y" — is sometimes stronger than individual replies

Documenting community needs assessment findings and sharing them with participants is both an ethical and practical requirement. Ethical because the people who gave their time and opinions deserve to know what was done with what they said. And practical because a team that returns findings to the community builds a bridge of trust that makes every subsequent assessment easier. The common problem is that assessment findings are written in a report for the funder or the organisation's archive, while the community sees nothing of it. When the team returns the following year for a new assessment, people are less willing to participate because they saw no outcome from their previous participation. The assessment loop closes when the team tells the community: this is what we heard from you, this is what we discovered, and this is what we decided to do based on what you told us — then verifies this understanding by asking: "did we understand your needs correctly?" Returning findings to the community requires no complex technology: a visible sign, an open meeting summarising what was gathered, or a message in plain language rather than professional report language. What matters is that people see their voice was received and a decision was built on it. When presenting findings, expectations must be managed clearly: there is no need to promise implementing everything people said, but a promise of honesty about what can and cannot be done. "We heard the main need is a day care centre, but our budget does not allow it this year" is honesty better than a promise that cannot be kept. Closing the assessment loop this way transforms data collection from a technical tool into a community relationship that accumulates trust year after year.