Needs assessment

When to use it

An organization has to document community need and report it upward. A library board is building a plan of service, a municipality is setting a recreation or social plan, a nonprofit is writing the needs section of a funding application. The usual instrument is a survey, which produces percentages nobody can act on, or a public meeting, which produces the three people who always come.

This guide runs one session per priority population and compiles them into one report. Each group speaks on its own terms, in its own room, and the compilation keeps the groups distinct rather than averaging them into a single community voice.

In Alberta, the Libraries Regulation requires a library board's plan of service to be based on a needs assessment, and the plan is refiled with the Minister every five years. That is a real, dated, recurring obligation, and it is the clearest version of this job. Facilitators elsewhere should check the equivalent instrument in their own province before citing one.

Family and Community Support Services funding is often described as carrying a similar requirement. We have not been able to confirm that a needs assessment is a condition of FCSS funding, so do not tell a client it is. Ask the funder what they require and write to that answer.

Do not use it when the organization has already written the plan and needs evidence for it. That is a consultation exercise, the participants will recognize it, and the resulting document will not survive a funder who reads carefully.

The question

A needs assessment question fails when it invites a wish list. The point is to surface what is missing and what it costs people, not to collect requests for amenities.

Seeds, cultivate one with the client:

• What do you need here that you currently have to leave the community to get?
• What did you try to get help with in the last year, and what happened when you tried?
• What makes it hard to use the services that already exist here?
• If someone new arrived in your situation tomorrow, what would you warn them about?

The question that fails: "What services would you like to see?" It produces a list of facilities ranked by who shouted loudest, with no information about who is currently going without and why. If the client insists on an amenities question, run it as a second round after this one.

Recruitment

Every other guide in this set can leave recruitment to the client. This one cannot, because this guide's failure happens before the session starts.

• Name the priority populations explicitly and in writing, before any session is booked. Seniors, newcomers, youth, caregivers, people without reliable transport, people who do not use the service today. The last one is the one that gets dropped and the one a funder will ask about.
• Run a separate session per population. A single open session is dominated by whoever is most comfortable in a room with a screen, and the compilation cannot recover a group that never spoke.
• Recruit through the organizations those groups already trust, not through the client's own mailing list. The mailing list is the population that already gets served.
• Remove the barriers to attending that the assessment is likely to find: transport, childcare, timing, language. An assessment that is inaccessible to the people it is about produces a predictable and useless answer.
• Record who you invited, who came, and who did not. The report needs this and the funder will ask for it.

Session settings

• Participants: cap at expected headcount plus ten
• Anonymous participation: on
• Raffle: off. It defaults on. Collecting names and contact details in a session where people describe unmet needs and personal hardship is a serious mistake, and it changes what people are willing to write
• Blind gather: on
• Blind then reveal voting: on
• Shuffle order: on
• Access after finish: on, so participants can read what their group produced

Run of show

This covers one session. Compilation is a separate job, below.

Ends at: Resolve, the closing segment. Each population's session closes on what that group most wants carried into the report, and compiling the sessions is a separate job rather than a further step in the room.

Compiling several sessions into one report

• Compile, do not merge. Keep each population's themes labelled by session. The moment you combine them into one ranked list, the largest group's themes become the community's themes and the assessment has produced the thing it existed to prevent.
• Report a small group's distinct need at full weight. If the newcomer session raised a barrier no other session mentioned, that is a finding, not an outlier. Give it its own line in the report rather than letting it fall below a frequency threshold.
• Read across the sessions for what is common and say so separately. Needs that appeared in every session are the strongest finding in the document. Needs that appeared in one are the second strongest. Both belong; they are different claims.
• Keep the unclustered contributions. Across several sessions they accumulate into the specific, single-voice descriptions that make a funding application readable.

Reporting

Export the data from the session overview, as CSV or JSON. The export gives you:

• Every contribution, with the pattern it landed in and the question it answered, and contributions that landed in no pattern marked as such
• Every pattern, with the AI's draft name beside the name the group settled on and a flag for whether the group changed it, the number of contributions in it, its up, down and starred totals, and its comment count
• Every comment, with the pattern it was on

The export does not give you, by design:

• Any identity. No names, no email addresses, no per-participant identifier of any kind
• Any link between one contribution and another by the same person. Votes and comments are per-pattern totals, not per voter
• Demographics. If the funder needs need broken out by population, that comes from running a session per population and keeping the exports separate, which is why this guide is structured the way it is

For a council or funder report, the CSV pattern sheet is the appendix and the group's own theme names are the section headings. The AI draft column is worth including rather than hiding: a reviewer who can see that the group renamed a theme can see that the group, not the software, decided what it was called.

The sentence the report needs. Any assessment going to a funder has to state its own boundary, and it is better coming from you than from a reviewer. Use this or something close to it:

Participants were self-selected attendees rather than a random sample. The themes in this report are the themes these groups raised, and the number of people who raised each one describes the people in the room. It is not an estimate of how common that need is across the community.

What the group leaves with

The themes they named, what was most widely shared, the comments about what is missing, and the contributions that fit no theme kept visible rather than discarded. The organization receives the same material plus the export. Nobody receives a record of who said what, because it does not exist.

The failure mode

The assessment confirms what the organization already believed, because the same people who always come, came. This failure looks like a success. The session runs smoothly, the themes are coherent, the report is easy to write, and it is a description of the organization's existing audience presented as a description of the community.

The prevention is entirely in recruitment, which is why this guide has a recruitment section and the others do not. Decide the priority populations before the first session is booked, run a session for each, and record who did not come. If you reach the compilation and one population never got a room, say so in the report rather than writing around it. A named gap is a finding a funder can work with. An unnamed gap is a claim that will not hold up.