01 · What breaks
Design for the failure modes, not only the happy path.
Implementation plans fail in predictable places: the scope that tries to fix everything at once, the test that only follows the easy path, and the handover that happens before anyone has used the system through a reporting crunch.
A big-bang scope
A plan that replaces the CRM, MIS, HR system and dashboards in one year collapses when March utilisation reports eat the team's time. Pick one decision, one workflow and one team, run it through a full season, then widen. Phase each release so it is still useful if the next grant never arrives.
Testing only happy paths
Most defects found in user testing are design defects: a missing dropdown value, a role that cannot see a tab, a total that does not reconcile, a backdated entry the rules forbid. Write test cases for transfers, dropouts, re-enrolments and late entries, not only for a clean new registration.
Training delivered too early
Training in week two, for a system that goes live in week eight, is forgotten by go-live day. Train by role in the last week before go-live, on the live configuration, and give each role a short guide for the three tasks it does most often.
Project closure before adoption stabilises
Closing the project on go-live day hides the real questions, which arrive in the first month. Budget 30 to 45 days of hypercare: watch weekly use by role and by form against expected volume, fix within scope, and log everything else for the next phase.
02 · Minimum viable model
Plan around signed artefacts, not calendar dates.
Each record below is something a person signs. If an artefact is missing, the stage is not finished, however many weeks have passed. The method is described in full on the ImpactOS page.
| Phase | Stage | Signed artefact | Typical timing, small or medium build |
|---|---|---|---|
| Convert | Discovery and proposal | Call brief, gaps list and a fixed-outcome first phase | Proposal within a day of the discovery call |
| Deliver | Kickoff and pre-work | Inputs pack: forms, current sheets, users and roles, reports wanted, Theory of Change | Week 0 |
| Deliver | Model | Data model signed off by the nonprofit | Week 1 |
| Deliver | Align | Role matrix, workflows, report specs and mockup: the scope contract | Week 2 |
| Deliver | Build and internal QA | Working sandbox app, QA and security check passed | Weeks 3 to 6 |
| Deliver | User acceptance testing | UAT log and change log | Week 7 |
| Deliver | Go-live and handover | Migrated data, role-wise training, user and admin guides | Week 8 |
| Adopt and learn | Hypercare, close and next phase | Weekly adoption notes, then a phase two proposal built from the change log | 30 days after go-live |
They describe one data system for a small or medium programme. Multi-programme or multi-state systems usually need two to four weeks of discovery and six to twelve weeks of build in sprints, with the same gates.
03 · Implementation sequence
Move through reviewable gates.
The six moves below compress the stages into the work your own team will feel. Each ends when someone signs, not when a meeting happens.
Diagnose and prioritise one journey
Ask the people who move the programme, the money and the evidence to show you where the work stalls. Choose the one journey whose failure costs the most, such as attendance that never reaches the monthly report, and collect its real sheets and forms before the first workshop.
Architect records and roles
Agree entities, IDs, duplicate rules, mandatory fields and derived fields in a data dictionary, then a role-by-form permission matrix. Default every date rule to the April to March financial year. Missing fields and wrong mandatory rules get caught here, or get paid for in testing.
Prototype with real users
Put a realistic mockup in front of a field worker, a programme manager and the MEL lead. Watch them complete one real case. Their sign-off turns the mockup into the scope contract; anything new after that is logged as a change, not absorbed into the build.
Migrate and test representative cases
Clean and map legacy spreadsheets locally, outside any AI tool, then import and spot-check about one record in ten against the source. Test with representative cases, including the awkward ones: a child who transferred mid-year, a participant enrolled in two projects.
Launch with support and ownership
Choose a go-live window away from the March utilisation rush and the May donor-certificate season. Name an internal administrator and a project lead with protected time, and hand over the user guide, admin guide and training deck on the day the old sheets are frozen.
Review use, quality and next release
Review weekly use by role, failed workflows and the support queue for a month. Sort every request with one rule: if it is in the signed design and broken, it is a bug; everything else is a change for the next release. The change log becomes the next phase's scope.
04 · Evidence
Measure whether the work became clearer.
A roadmap works if the system is in daily use a month after go-live and the next phase is scoped from evidence rather than from a wish list.
05 · Responsible automation
Let systems prepare. Keep consequence with people.
Systems can support
- Tracking every stage, owner and date in one project plan
- Generating test cases from the signed design
- Spot-checking imported records against the source
- Reporting weekly use by role and by form
People should decide
- Scope and release sign-off
- Risk acceptance
- Data cut-over
- Prioritising the next module
06 · Common questions
Practical questions teams ask.
What sponsors and project leads usually ask before they commit a team to an MIS implementation.
What are the stages of a nonprofit MIS implementation?
EdZola groups them into three phases. Convert covers discovery and a fixed-outcome proposal. Deliver covers pre-work, a signed data model, a signed design and mockup, build, user acceptance testing and go-live. Adopt and learn covers about a month of supported use, then a review that turns the change log into the next phase.
How long does it take to implement an MIS for an NGO?
For one data system serving a small or medium programme, about eight weeks from kickoff to go-live is typical in our projects, followed by around 30 days of hypercare. Systems spanning several programmes, states or integrations take longer, mainly in discovery and build. Delays usually come from late inputs or unsigned designs, not from development.
Who needs to be involved in an MIS implementation, and how much of their time?
You need an executive sponsor who can make scope decisions, a project lead who can give roughly a third to half of their time during delivery, the MEL lead for indicator definitions, and a few field staff to test forms. An internal administrator should be named early so they can be trained before handover.
When is the worst time of year for an NGO to go live with a new system?
March and May are usually the worst. March is consumed by year-end utilisation reports and audit preparation, and May is when donors wait for their tax certificates. Pick a quieter month, and ideally run the new system through one full reporting cycle before relying on it for a funder report.
What should happen after an MIS goes live?
Plan for 30 to 45 days of hypercare. Monitor weekly use by role and by form, failed workflows and sync errors, and fix issues that fall inside the signed scope. Keep a running list of new requests; at the end of hypercare, review it with the team and decide what goes into the next phase.