The short answer
A monitoring and evaluation (M&E) system is a programme's results framework, meaning its goal, outcomes, outputs, indicators, baselines, targets and means of verification, plus the tools and routines that collect data against those indicators, check it and report it to the donor or ministry. The framework comes first: software cannot fix an indicator nobody agreed or nobody can verify in the field.
For a single-site project with one person collecting data, a well-built spreadsheet can be the whole system. Once there are several field staff, rural sites or a funder that wants verifiable, timestamped data, it needs phone-based collection and a proper database. Below: a filled indicator sheet, a table for deciding which tool you need, and what to send us for a first meeting.
The six parts of an M&E system
| Part | What it does | Who uses it |
|---|---|---|
| Results framework | Defines the goal, outcomes and outputs, and the theory of change linking them | Programme managers and the donor at design stage |
| Indicators | Turns each outcome into something measurable, with a baseline and a target | The M&E officer, and the donor at reporting time |
| Data collection | Captures indicator data in the field, usually on phones | Field staff and enumerators |
| Verification | Confirms the data is real, through spot checks and cross-checks against other records | Supervisors and, on larger programmes, an independent verifier |
| Dashboard | Turns raw data into a live view of progress against target | Programme managers, for day-to-day decisions |
| Donor reporting | Packages the same data into the donor's own report template | Programme leadership and the donor |
Worked example: one indicator, fully specified
The indicator reference sheet, the one-page definition behind each indicator, is where a framework is really tested. Here is one filled in for a SACCO lending programme, such as a Parish Development Model or donor-funded credit project. The definitions come from the Tier 4 SACCO Regulations and standard microfinance practice. The baseline and target are left as the programme would set them, because a system builder should never invent them.
| Field | Filled example |
|---|---|
| Indicator | Share of the loan book more than 30 days overdue (PAR 30) |
| Definition | Outstanding balance of every loan with a payment more than 30 days overdue, divided by the gross loan portfolio, at month end |
| Unit and breakdown | Percent; by parish or SACCO, and by sex of borrower (women are over 53 percent of PDM beneficiaries) |
| Baseline | The value in the first month after the grace period ended, taken from each SACCO's loan ledger |
| Target | Set by the funder or ministry with the programme, not by the system builder |
| Data source | Each SACCO's loan ledger, aged into watch, substandard, doubtful and loss |
| Frequency | Monthly, in step with the monthly returns licensed SACCOs already file within 15 days of month end |
| Means of verification | Ledger reconciled to the bank and mobile money statements; a sample of loan files checked against the ledger each quarter |
| Who collects | The SACCO treasurer, entered on a phone or taken from the SACCO system |
| Who checks | The district or programme M&E officer, before the figure goes into any report |
Write every indicator to this standard before software is discussed. If a row cannot be filled, for example nobody can say who checks the figure, the indicator is not ready, and building an app around it only makes the gap harder to see. Baselines from the field are collected the same way as any survey; see how we run field data collection.
Spreadsheet, phone forms or a built system: which you need
| Your programme | What is usually enough | Why |
|---|---|---|
| One site, one person collecting, quarterly reporting | A spreadsheet with locked formulas and one named owner | The framework matters more than the tool, and a build would cost more than it saves |
| Several field staff, rural sites, a weak network | Phone forms that work offline and sync to one database | Each record is timestamped and tied to the person who collected it |
| Several partners or districts, a funder that audits the data, or data that feeds a government report | A built system with user roles, an audit trail and the donor's report template | The trail from each reported figure back to the raw record is what the funder needs to trust |
| A programme that ends and is handed over | Whatever the client owns outright, code and data included | The next implementer can run it without the original developer |
We will tell you which row you are in before we quote. If it is the first, you do not need us to build anything.
What must exist before any software is built
- A theory of change, written down: how the activities are meant to lead to the outcomes.
- An indicator reference sheet for every indicator, filled to the standard above.
- A baseline plan: who collects it, when, and from how many sites.
- A data flow: who enters each figure, who checks it, and where it goes next.
- A verification plan: spot checks, cross-checks against bank or registry records, and an independent verifier where the donor requires one.
- A reporting calendar that works back from each donor or ministry deadline to the date field data must be in.
Building before this exists is an expensive mistake: a well-built app collecting data against indicators nobody agreed or nobody can check.
How we build it, and what we will not do
We build the framework and the software together where a programme needs both, or plug software into a framework already agreed with the donor. Field collection runs on phones, offline where needed, into a dashboard built around the agreed indicators, and we train the programme's own team to run it, because a system only its developer can operate is not one a donor should fund. Where a custom system is needed, builds start ; framework work is quoted after we see the programme. Every quote is fixed in writing before work starts, paid 50 percent to begin, 25 percent at the review of the working system and 25 percent at handover, and the client owns the source code and the data outright.
We do not carry out an independent evaluation where the donor needs one done by a party unconnected to the system builder. We never promise that a donor will approve a framework, a report or funding, and on legal questions in a grant agreement we work alongside the client's advocate. We are building this consultancy practice now and have no past M&E clients, donor engagements or outcomes to claim. Our proof is 37 live website and app builds, our own live products, Growth Informer Business, Moyo Pay and the loan and SACCO system, and our registration with URA as a tax agent.
What to send us, and what happens in the first meeting
Send on WhatsApp: the programme document or logframe; the donor's or ministry's reporting template; the indicator list with any definitions you have; the number of sites, field staff and partners; the reporting calendar; and whatever tool you use now, even if it is a spreadsheet.
In the first meeting we go through the indicators with you one by one and mark each as ready, fixable, or not collectible as written. We tell you which row of the tool table you are in, and so whether you need software at all. If framework work or a build makes sense, the fixed quote follows in writing.
Who this is for
NGOs running donor-funded projects; ministries, agencies and local governments aligning their plans and results frameworks with the Fourth National Development Plan (NDP IV, FY2025/26 to FY2029/30); implementers on World Bank financed programmes such as the USD 200 million Uganda Digital Acceleration Project (UDAP-GovNet), run by NITA-U, or the USD 217 million GROW project for women's enterprises, delivered through PSFU; and district and parish structures running the Parish Development Model. The wider donor picture is in donor-funded projects in Uganda, and the PDM version of this system is the district PDM funds system.
Where the reporting sits inside a bigger digital change, such as the national Digital Transformation Roadmap set by the Ministry of ICT and National Guidance, see digital transformation in Uganda and our IT consultancy. Where no ready-made tool fits the workflow, see custom software development.
Frequently asked questions
What is the difference between an M&E framework and an M&E system?
The framework is the results logic: indicators, targets and verification methods. The system is the tools and routines that capture data against that framework and report it out. A framework can exist on paper; a system cannot exist without one.
What tools are used for monitoring and evaluation?
Phone forms that work offline for field collection, a database or dashboard that shows progress against target, and a reporting layer that fills the donor's own template. For a small single-site project, a well-kept spreadsheet can do all three.
What is a results framework?
A structured statement of a programme's goal, outcomes and outputs, and the logic linking them, agreed with the donor before implementation starts. It is the reference point every indicator and every report traces back to.
What is an indicator reference sheet?
The one-page definition behind each indicator: what it measures, how it is calculated, its baseline and target, the data source, frequency, means of verification, and who collects and checks it. If any of those cannot be filled in, the indicator is not ready for software.
Do NGOs in Uganda need a digital M&E system, or can a spreadsheet work?
A spreadsheet can work for a small, single-site project with one person maintaining it. Once there are several field staff, several sites, or a donor that wants verifiable, timestamped data, the spreadsheet becomes the weak point and phone collection with a proper database is worth its cost.
How much does an M&E system cost?
Where a custom system is needed, builds start . Framework work is quoted after we see the programme, and every quote is fixed in writing before work starts.