GOVERNMENT WASH MANAGEMENT · GUIDE 02
How to choose a WASH MIS
A requirements checklist for governments.
To choose a WASH management information system, define the government’s essential workflows and test whether each option supports them under real working conditions. Assess data management, offline use, permissions, interoperability, administration, support, and long-term costs.
A useful evaluation shows how the system will work for the people responsible for maintaining it. Can a field officer update an existing water point without connectivity? Can a district manager review the submission? Can a national team use the approved information without manually combining spreadsheets?
This guide provides a checklist and a practical way to compare the answers.
1. Start with the work government needs to do
Write down three to five tasks the MIS must support from beginning to end. For example:
• Update a water point’s condition following a field visit.
• Review and correct district reporting before national aggregation.
• Track a reported fault through assignment, repair, and verification.
• Compare service indicators across administrative areas.
• Import partner data and connect it to existing infrastructure records.
Describe the users, data, expected outcome, and working conditions for each task. Use the same scenarios to evaluate every system.
Distinguish essential requirements from desirable features. An essential requirement should be necessary to operate the system or meet an applicable obligation. Agree on these requirements before demonstrations begin.
2. Use the requirements checklist
For every requirement below, record its priority, demonstrated evidence, limitations, and the cost of meeting it. Ask technical and governance teams to confirm requirements for hosting, data handling, and institutional policies.
A · Data and field operations
□ Persistent infrastructure records
ASK: Can repeated inspections, faults, and repairs be linked to the same asset?
TEST: Update an existing water point and retrieve its earlier observations.
□ Offline fieldwork
ASK: What can staff access and update without a connection? What must be prepared beforehand?
TEST: Complete a field task offline on a typical device, synchronize, and verify the result.
□ Data quality
ASK: Can the system validate entries, identify incomplete records, and support review and correction?
TEST: Submit an invalid or incomplete report and demonstrate how it is resolved.
□ Indicators and reporting
ASK: Can teams maintain shared definitions and examine the records behind a result?
TEST: Reproduce an agreed indicator from sample data. Explain its denominator and treatment of missing data.
B · Government control and interoperability
□ Administrative structure
ASK: Can the system represent national, regional, and district responsibilities?
TEST: Demonstrate separate field, district, and national user roles.
□ Access controls
ASK: Can government control who views, edits, approves, shares, and exports information?
TEST: Try both permitted and prohibited actions using accounts with different roles.
□ Data ownership and portability
ASK: What can government retrieve, in which formats, and under what conditions?
TEST: Export representative records and attachments. Check that identifiers and relationships remain usable.
□ Integration
ASK: Can the MIS exchange information with systems government already uses?
TEST: Demonstrate a representative import or connection and document its maintenance requirements.
□ History and accountability
ASK: Can authorized staff establish who changed a record and what changed?
TEST: Inspect the history of a corrected record and explain available recovery options.
C · Sustainable operation
□ Security and continuity
ASK: What protections, backup arrangements, and recovery processes apply?
EVIDENCE: Obtain current documentation and clarify government and provider responsibilities.
□ Routine administration
ASK: Can trained government staff manage users, forms, and reports?
TEST: Ask a government administrator to complete common tasks after introductory training.
□ Usability and language
ASK: Can intended users complete their work on available devices and in the required languages?
TEST: Observe representative staff completing the evaluation scenarios.
□ Scale and performance
ASK: Will the system remain usable with the expected records, attachments, and users?
TEST: Use representative data volumes and agree on acceptable performance.
□ Support and costs
ASK: What is included, what costs extra, and who responds when something fails?
EVIDENCE: Request an itemized cost proposal and written support arrangements.
3. Ask providers to demonstrate your scenarios
Give each provider the same representative sample data and tasks. Use anonymized or synthetic records where appropriate.
A PRACTICAL WATER POINT TEST
1 → Import an existing inventory while preserving identifiers.
2 → Prepare the required records for fieldwork.
3 → Record a functionality update offline.
4 → Synchronize and review the submission.
5 → Correct an error while retaining a trace of the change.
6 → Update a district report.
7 → Export the resulting records.
Include exceptions. What happens when two people update the same asset? When a record is assigned to the wrong district? When a field officer changes jobs?
These tests reveal the practical implications of claims such as “offline-capable,” “configurable,” or “supports government reporting.”
Document which capabilities are available now, which require configuration, and which depend on new development. Record the cost, timeline, and responsibility for additional work.
4. Compare the full operating cost
Use the same planning period and assumptions for every option—for example, five years if that fits the government’s planning cycle.
INCLUDE IN YOUR BUDGET
• Initial configuration and implementation.
• Data cleaning and migration.
• Integrations and their maintenance.
• Devices, connectivity, and fieldwork.
• Training, refresher sessions, and staff onboarding.
• Government administration and technical staff time.
• Hosting, licenses, support, and storage where applicable.
• Changes to forms, indicators, and reporting requirements.
• Data extraction and transition assistance if government changes systems.
State assumptions about user numbers, data growth, and geographic expansion. Ask how costs change if those assumptions change.
The mWater platform is free to use, including unlimited users, data collection, storage, visualization, and export. Optional implementation and support services are paid. Governments should still budget for staff, fieldwork, equipment, training, and ongoing administration.
5. Score evidence consistently
Agree on weights before reviewing results. Record evidence and limitations next to each score so the reasoning remains visible.
0 · Does not meet the requirement.
1 · Major gaps or substantial additional work required.
2 · Partially meets the requirement, with material limitations.
3 · Meets the requirement and has been demonstrated.
4 · Meets the requirement and offers a demonstrated, relevant operational advantage.
ESSENTIAL REQUIREMENTS COME FIRST
Assess mandatory requirements separately. A high overall score should not conceal failure to meet an essential requirement. Keep promised capabilities distinct from those the evaluation team has verified.
For requirements needing development, specify how and when acceptance will be tested.
6. Pilot with the people who will operate it
Before wider rollout, ask field staff, district managers, and government administrators to use the shortlisted system under representative conditions.
Choose settings that expose meaningful differences in connectivity, workload, devices, staff experience, and existing data quality.
Agree on acceptance criteria in advance: successful completion of core workflows, reliable offline synchronization, correct permissions, reproducible indicators, and independent completion of routine administrative tasks.
Record the assistance users require. The pilot should establish the training and support needed for wider adoption.
7. Carry the selection into implementation
The evaluation should produce a clear record of the chosen system’s scope, demonstrated capabilities, limitations, costs, and responsibilities.
Carry tested workflows and acceptance criteria into the implementation plan. This gives government and its implementation partner a shared understanding of successful delivery.
YOUR EVALUATION RECORD
For each requirement, capture: priority · weight · score · evidence · limitations · additional cost · responsible person · acceptance date.
Keep one record per provider, using identical requirements and scoring rules.
Explore mWater
Governments evaluating mWater can test its data collection, infrastructure records, dashboards, organizational controls, imports, and API against their own requirements.
mWater · Government WASH management series