7 Ways to Scale a Community ProgrammeWithout Losing What Made It Work

A programme works beautifully in one community.

Participants trust the team.

The facilitator knows everyone.

The local partner solves problems before they grow.

The activities make sense.

The funder sees good results.

Then someone asks the obvious question:

How do we scale it?

That question can be exciting.

It can also be dangerous.

A community programme often succeeds because of relationships, local knowledge, experienced people and small operational decisions that were never written down.

If scale means copying the visible programme while losing the invisible conditions behind it, the organisation can reproduce the format and lose the quality.

A recent South African report on scaling social impact makes an important distinction between organisational growth and true impact scale. Growth is not automatically scale, and replication is only one possible route. Source: Next Generation

For me, responsible scale begins with a different question:

What made this work, and which parts must survive expansion?

What does it mean to scale a community programme?

Scaling a community programme means increasing its reach or influence without losing the core conditions that create value. That can involve replication, partnerships, government adoption, facilitator networks, licensing, digital delivery or systems change. Scaling does not always mean making the organisation itself larger.

South African impact research published in 2026 highlights several different scale pathways, including replication, social franchising, government adoption, policy influence and systems change. Source: Next Generation

That wider view is useful because it removes the assumption that every successful programme must become a larger version of itself.

Sometimes the better question is:

How can the impact travel?

1. Define what must remain consistent

Before scaling, identify the programme’s non-negotiables.

These might include:

• a core learning outcome
• a participant-support principle
• facilitator standards
• a safeguarding requirement
• a recruitment approach
• a quality threshold
• a specific sequence
• a feedback process
• a relationship to opportunity

If the team cannot explain what must remain consistent, every new site will make its own interpretation.

That may create innovation.

It may also create drift.

The goal is not rigid standardisation.

It is clarity.

In my own programme work, I have seen how useful playbooks and central resource repositories can become when a programme needs to travel beyond the people who originally built it.

A programme should not depend entirely on memory.

2. Separate principles from local adaptations

This is where many scaling efforts become too rigid.

A programme identifies what worked in one community and then assumes every visible detail caused the result.

But some elements are principles.

Others are context.

For example:

Principle: participants need realistic opportunity pathways.

Local adaptation: which employers, institutions or markets make up those pathways.

Principle: facilitators need preparation.

Local adaptation: the examples and language they use.

Principle: the programme needs participant feedback.

Local adaptation: the method used to gather it.

Scaling works better when the organisation can distinguish between the things that define programme integrity and the things that should change locally.

That is why programme localisation and scale belong together.

3. Document the invisible work

This is one of the most important steps.

What does the experienced programme manager know that is not written down?

What does the facilitator do before the session?

Who calls participants when attendance drops?

How are stakeholder problems handled?

What happens when the venue fails?

How does the team decide whether someone needs additional support?

What makes onboarding work?

These operational details can hold a programme together.

When expansion happens, they become gaps.

A good playbook should therefore capture more than the official curriculum.

It can include:

• roles
• processes
• decision points
• templates
• facilitator guidance
• communication flows
• escalation routes
• quality standards
• common problems
• lessons learned

Documentation should support judgement, not remove it.

The aim is to make important knowledge transferable.

4. Build facilitator capability before adding sites

A programme can scale faster than its facilitator capability.

That creates a predictable problem.

New cohorts begin.

New regions launch.

The curriculum is distributed.

Facilitators receive a briefing.

Everyone assumes the model will reproduce itself.

But delivery quality is carried by people.

Facilitators need to understand:

• programme purpose
• participant context
• learning outcomes
• session flow
• activity logic
• resources
• common delivery problems
• feedback expectations

This is why Train-the-Trainer should happen before scale, not after quality problems appear.

The programme should not only ask:

How many facilitators do we have?

It should ask:

How ready are they to carry the programme?

5. Protect feedback loops

A small programme often learns quickly because the programme leader hears problems directly.

Scale increases distance.

Participants become numbers in a dashboard.

Facilitator feedback moves through layers.

The central team becomes slower to see what is happening locally.

That can create the illusion of consistency.

Every site uses the same materials.

Every site submits the same report.

But participant experience may be diverging underneath.

Protect feedback deliberately.

Useful mechanisms can include:

• facilitator debriefs
• participant feedback
• site learning reviews
• regular community input
• implementation notes
• issue logs
• cross-site learning sessions

The purpose is not more reporting.

It is protecting the programme’s ability to learn.

6. Strengthen partnerships instead of centralising everything

Scale does not require one organisation to own every function.

Community programmes often work because local organisations bring trust, relationships, language and practical knowledge.

South African community-development policy has long recognised the value of partnerships, community linkages and local participation. Source: Western Cape Government

A scaling organisation should therefore ask:

• What should remain central?
• What should be owned locally?
• Where does partnership create stronger delivery?
• What capability already exists in the community?

Centralisation can create consistency.

Too much centralisation can remove local intelligence.

Responsible scale finds the balance.

7. Scale evidence, not enthusiasm

A pilot can feel successful.

Participants may enjoy it.

The team may be proud.

The funder may be excited.

That is not yet enough evidence for expansion.

Before scaling, ask:

• What changed?
• For whom?
• Under what conditions?
• Which components appear important?
• What did not work?
• What resources did the programme really require?
• Can those conditions be reproduced?
• What will cost more at scale?
• What new risks appear?

The 2026 South African scaling report warns that scale can create unintended consequences and that organisations need to assess readiness, funding, operational capacity and measurement before expansion. Source: Next Generation

That is a healthier starting point than:

The pilot was popular, so let us double it.

A simple readiness test

Before scaling a community programme, I would want clear answers to seven questions:

1. What evidence tells us the programme is working?
2. What are the non-negotiable elements?
3. What can adapt locally?
4. Is the delivery model documented?
5. Are facilitators ready?
6. Can the programme still learn at scale?
7. Is the opportunity pathway strong enough to support more participants?

If those answers are unclear, expansion may be premature.

Scale should increase value.

It should not simply increase volume.

The most responsible programmes do not protect their format at all costs.

They protect the conditions that make the programme useful.

Related support

Explore Programme Implementation Consulting, Programme Design Consulting, Train-the-Trainer and Programme Localisation.

See RLabs Connect for an example of programme knowledge being converted into a playbook and resource repository.

Related reading: 9 programme localisation mistakes in South Africa and 9 signs a skills programme is measuring reach instead of impact.