KENYA · GUIDE 0628 · EDITION 4.2
Computer basics lessons in Kenya: Risks and Launch Plan
Set the conditions for a safe commercial test
- Credential exposure
- Too many learners per device
Lessons fail when learners can follow clicks while the instructor watches but cannot find their saved work or distinguish a local file from an online document.
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
Run one session on creating, saving and locating a document using sample data.
The pilot scope is: Teach computer basics using the devices and everyday tasks learners will actually use, agreeing starting skills, account access, accessibility needs, and safe practice materials.
| Gate | Evidence before continuing |
|---|---|
| Scope agreed | Teach computer basics using the devices and everyday tasks learners will actually use, agreeing starting skills, account access, accessibility needs, and safe practice materials. |
| Output acceptable | Ask learners to create, save, reopen, and share a practice document independently, checking file location and basic error recovery rather than copied mouse movements alone. |
| Costs recorded | Include device preparation, practice files, teaching, learner assistance, venue or connectivity, and concise reference materials, allowing time for different levels of keyboard and pointer confidence. |
| Buyer response recorded | Track starting skills, independently completed tasks, navigation mistakes, saved-file retrieval, access barriers, and learner questions that should change the pacing of future computer lessons. |
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 |
|---|---|---|
| File missing | Check save location and extension. | Search only approved practice folder. |
| Wrong file opens | Compare filename/path. | Rename practice examples clearly. |
| Login blocks lesson | Ask owner to sign in privately. | Do not request password or bypass access. |
Outstanding go / hold conditions
- Actual device/version and learner needs unverified.
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.