KENYA · GUIDE 0629 · EDITION 4.7
Spreadsheet lessons in Kenya: Risks and Launch Plan
Set the conditions for a safe commercial test
- Real customer data in class
- Unsupported software claims
Training fails when learners produce an attractive table but extend formulas incorrectly or treat calculated results as trustworthy without checking the source data and logic.
A risk list is useful only when it changes a decision. For each risk, write the observable warning, who checks it and the response before the next commitment. Do not treat a reserve of money as permission to continue unsafe or unauthorized work.
Use a small, measurable pilot
Use a sample sales table and one lesson covering entries, totals and a useful filter.
The pilot scope is: Teach spreadsheets through a defined learner task, covering data structure, formulas, references, checking, and saving, with examples relevant to the learner's work or studies.
| Gate | Evidence before continuing |
|---|---|
| Scope agreed | Teach spreadsheets through a defined learner task, covering data structure, formulas, references, checking, and saving, with examples relevant to the learner's work or studies. |
| Output acceptable | Ask learners to modify the example independently and detect a deliberately incorrect formula, checking understanding of references rather than the ability to reproduce a demonstration. |
| Costs recorded | Include task design, practice datasets, instruction, individual troubleshooting, feedback, and reusable notes, allowing extra support where basic computer skills constrain spreadsheet progress during the session. |
| Buyer response recorded | Record learner tasks, formula choices, reference errors, validation attempts, independently corrected mistakes, and follow-up topics that will make the spreadsheet useful in actual daily work. |
Stage the launch around prerequisites
First confirm the buyer specification and activity requirements. Then compare suppliers, establish suitable facilities and prepare the operating record. Run the bounded trial when those prerequisites are in place. Review actual costs, quality failures and cash collected before increasing the commitment.
This sequence is not a promise that the complete business cycle fits into 30 days. Growing periods, qualifications, approvals, seasonal access and customer buying cycles can require longer. Revise the schedule when a prerequisite changes rather than skipping it to meet a launch date.
Choose continue, revise, pause or stop
Continue only when the scoped result is accepted and direct costs and payment timing are workable. Revise one part of the offer if the problem is identifiable and affordable to test again. Pause when required information, permission, skills or resources are missing. Stop the affected work when safety, consent or lawful authority is uncertain.
Keep a maximum test loss and unpaid-balance limit suited to your actual funds. A successful single delivery is useful evidence, but it does not establish year-round demand or justify committing every available resource.
Tie launch milestones to observable checks
| Risk signal | Evidence to inspect | Response to test |
|---|---|---|
| Total stays unchanged | Check calculation mode/formulas. | Restore automatic calculation where appropriate. |
| All rows show same total | Inspect absolute references. | Use correct relative row references. |
| SUM misses row | Check selected range. | Include D2 through D5 and retest. |
Outstanding go / hold conditions
- No live accounts or software version tested.
Assign an owner, evidence reference and review date to each unresolved condition. Do not give every milestone a fixed calendar date when it depends on a crop, production, approval or competence cycle. Run only a suitable limited trial, reconcile accepted output and actual cash, and record whether the evidence supports holding, revising, proceeding within the limit or stopping.