KENYA · GUIDE 0630 · EDITION 4.2
Coding clubs in Kenya: Operations and Quality Checks
Deliver the agreed result consistently
Run coding clubs around age-appropriate projects, available devices, learner starting points, safeguarding arrangements, and a clear balance between guided work and independent problem solving.
The operating sequence for this offer is:
- Choose an age-appropriate coding tool and a small original project that demonstrates one concept within the available session time.
- Guide learners through writing and testing their own changes, using approved online access and avoiding uncontrolled contact with strangers.
- Ask each participant to explain a code change and demonstrate its effect, then record the next concept to practise.
Put acceptance into the job record
Participants can describe and modify the code; do not promise employment or advanced competence.
Ask learners to explain and change their own project, checking what happens when an input changes rather than accepting a copied working program as learning evidence.
Inspect at the point where a correction is still possible, then again at handover. Record rejected or incomplete output separately from accepted output. A completed task is not automatically an accepted task, and an invoice does not establish that the customer received the right result.
Measure real capacity
Time preparation, the main operation, transport, cleaning, approvals and correction as applicable. The slowest stage determines how much you can promise. Where two orders need the same person, space or equipment at the same time, resolve the conflict before confirming both deadlines. An additional enquiry should not erase a commitment already made.
| Operating checkpoint | Evidence for this business |
|---|---|
| Before starting | Run coding clubs around age-appropriate projects, available devices, learner starting points, safeguarding arrangements, and a clear balance between guided work and independent problem solving. |
| During delivery | Guide learners through writing and testing their own changes, using approved online access and avoiding uncontrolled contact with strangers. |
| At acceptance | Ask learners to explain and change their own project, checking what happens when an input changes rather than accepting a copied working program as learning evidence. |
| At the pilot review | Keep project intentions, learner explanations, debugging attempts, prompts, collaboration observations, account barriers, and independent changes that indicate what the next club activity should reinforce. |
Keep a correction and escalation rule
When inputs, access, specifications or customer instructions change, pause the affected work and confirm the effect on time and cost. Do not quietly lower the acceptance standard to avoid a delayed delivery. Keep rework caused by your error distinct from a customer-requested change of scope and agree the remedy clearly.
A club looks productive but teaches little when every child reproduces the same demonstration and cannot explain why their program behaves differently after a small change.
Retain the minimum records needed to investigate a complaint without disclosing unrelated personal information. Use measured delivery and actual acceptance as the basis for expanding capacity, rather than the maximum theoretical output of a tool or production line.
Operating control points for this exact offer
| Sequence | Work method | Release checkpoint |
|---|---|---|
| 1 | Use approved offline/local setup or school-controlled arrangement. | No child account creation or public publishing without authorised process. |
| 2 | Add green-flag block, set score to zero and move star. | Restart clears previous score. |
| 3 | On star click change score by one then reposition. | One deliberate click produces one increment. |
| 4 | Change backdrop or drawn sprite while preserving reset logic. | Original choices are welcomed; no copied commercial artwork. |
| 5 | Open saved project and run three clicks then reset. | Expected score three then zero; keep files private. |
Do not substitute a tick for an observation: record the count, measurement, approved sample or evidence reference used at each checkpoint. Mark unresolved work as held and identify who can approve the recheck.
Diagnose a failure before repeating it
| Observed symptom to investigate | Check the cause | Proposed response |
|---|---|---|
| Score never resets | Inspect green-flag stack. | Place set score zero in startup. |
| One click adds many | Check duplicate scripts/forever loop. | Keep one click event increment. |
| Project lost | Check saved file path. | Reopen local copy before departure. |
These are diagnostic prompts, not proof of the cause in a real incident. Separate suspect output, record any correction and repeat the relevant acceptance check. Link rejected units, rework time, replacement materials, customer credits and collection delays to the actual job result.