For most of a decade, Kenyan public benefit organisations planned around a statute that was not in force. That period is over. The Public Benefit Organizations Act, 2013 commenced in May 2024, and the regulations that operationalise it are now live: the Public Benefit Organizations Regulations, 2026, published as Legal Notice 43 and gazetted on 18 March 2026. The transition window for existing organisations closed on 13 May 2026. If your organisation has been treating PBO compliance as a forthcoming matter, it is not. This piece covers what the annual return obligation now looks like in practice. The reporting deadline is derived, not fixed The single most useful thing to understand about the annual return is that there is no common national filing date. The obligation is expressed relative to your own financial year:Annual returns are due within six months of the end of the organisation's financial year.So the deadline moves with your accounting calendar:Financial year ends Annual return due30 June 31 December31 December 30 June31 March 30 September30 September 31 MarchThis matters operationally, because it means the return is not a task that arrives with a national reminder. It is a date you have to hold yourself, and it sits six months after a year end that is already busy with audit. What goes into the filing The return is not a form on its own. It is a form supported by a set of documents that have to exist, be current, and be consistent with one another:Audited accounts. Which means an audit has to be commissioned, scheduled and completed inside the six-month window — realistically inside the first three or four months of it. Financial statements. An annual activity report — the narrative account of what the organisation did during the year. An asset register.The asset register is the item that most often does not exist in the form required. Many organisations track assets across procurement records, a fixed asset note in the accounts, and a partial inventory spreadsheet, none of which is a maintained register. Building one retrospectively, in the same window as the audit, is unpleasant and avoidable. The failure mode is the calendar, not the paperwork Six months sounds generous. It is not, once you work backwards from the deadline through what has to happen:The audit cannot start until the accounts are closed. The accounts cannot close until year-end reconciliations are complete. The activity report needs programme data from across the year, from people who have moved on to the next year's work. The asset register needs a physical verification if it has not been maintained.An organisation that starts at month four is filing late or filing thin. An organisation that treats the activity report as a year-round accumulation rather than a year-end write-up files on time without drama. The practical recommendation is simple and it is the only one in this piece we would insist on: put three dates in the calendar the moment your financial year ends — audit commissioned by month two, draft activity report by month four, filing by month six. The obligation stops being a crisis at that point. The activity report is where M&E pays for itself The annual activity report asks what the organisation did and what it achieved during the year. Organisations that run a functioning monitoring system produce it from existing records. Organisations that do not spend three weeks reconstructing the year from emails, event photographs and people's memories. If you run a logframe with indicators carrying baselines, targets and period actuals, the activity report is largely an assembly job: this is what we planned, this is what we delivered, this is where we fell short and why. If your indicator values live in a spreadsheet that four people edit, it is a research project — and one conducted in the same weeks as the audit. There is a second-order benefit worth naming. The same evidence base serves the annual return, the donor reports, and the next funding application. Organisations that maintain it once and use it three times have a real advantage over those that assemble it three times from scratch. Governance obligations run alongside The annual return is one obligation among several. The statutory framework also carries expectations around governance and record-keeping — board composition and meetings, member records, conflict of interest, and the ordinary requirement that the organisation's records reflect what actually happened. The pattern in the enforcement of comparable regimes elsewhere is that returns are filed and governance records are not maintained, and the gap becomes visible at the worst moment — during a due diligence exercise by a prospective funder, rather than during a regulatory review. Treating minute books, member registers and the asset register as live records rather than year-end artefacts is cheap insurance. What we are deliberately not stating Some specifics circulate in secondary commentary that we are not going to repeat, because we have not been able to confirm them to a standard that would justify putting them in a compliance planning document:Specific form numbers and titles for the annual return filing. Penalty amounts for late or non-filing. The precise mechanics of the closed transition window — what an organisation that did not act before 13 May 2026 must now do to regularise its standing.For all three, the authoritative source is the Public Benefit Organizations Regulatory Authority and the gazetted text of Legal Notice 43 itself. If any of them affects a decision you are making, confirm directly with the Authority rather than relying on a summary — including this one. A regulatory framework in its first year of operation is exactly the period in which secondary sources are least reliable. The short versionThe regulations are in force; the transition window closed on 13 May 2026. Your annual return is due six months after your financial year end — a date only you are tracking. The filing needs audited accounts, financial statements, an annual activity report and an asset register. The audit is the long pole. Commission it early. The activity report is easy if your M&E system is real and expensive if it is not. Confirm form numbers, penalties and transition mechanics with the Authority, not with an article.Monival holds programme results — indicators with baselines, targets and period actuals, against a logframe structure — so that the annual activity report is assembled from records rather than reconstructed. Monival does not generate the statutory return itself, and we would not describe a report builder as a filing tool.

Sibasi M&E Team

Monival Editorial

05 Aug, 2026

Every offline data collection tool markets the same promise: collect without a connection, sync when you have one. The promise is real and largely solved. What is not solved, and what actually costs programmes their data quality, is what happens in the seconds after the device reconnects. Three failure modes account for most of it. They are worth understanding as an M&E manager even if you never touch the technical settings, because the mitigations are partly procedural and those are yours to own. Failure one: the sync that never completes The naive design uploads submissions when the app is open and connectivity is present. In the field this fails for reasons that have nothing to do with signal: the enumerator closes the app, the device sleeps, the operating system kills the background process to save battery, the connection appears for forty seconds in a matatu and disappears. What a robust design does instead:Queue locally and treat the device as authoritative. A submission is saved to local storage the moment it is completed and is never held in memory waiting for a network. Sync in a background worker, not only when the app is in the foreground, so the OS can run it opportunistically. Retry with exponential backoff. A failed upload retried immediately, repeatedly, drains the battery and hammers a server that is probably already struggling. Backing off — waiting progressively longer between attempts — is what makes retries survivable on both ends. Cap the retries and surface the failure. After a bounded number of attempts the submission should be flagged for human attention rather than retried forever in silence. A queue that retries invisibly for three weeks is worse than one that fails loudly on day one.The procedural half, which is yours. Sync at a scheduled point each day when enumerators are somewhere with reliable connectivity, rather than relying on opportunistic sync in the field. And monitor the pending queue by enumerator, by day — a queue that is growing for one person is the single earliest signal you will get that something is wrong, and it usually appears days before the data gap does. Failure two: duplicates Duplicates are more damaging than missing data, because missing data announces itself and duplicates do not. A household counted twice inflates every indicator built on it, and reconciliation after the fact is slow, manual and never quite complete. They arise from ordinary field behaviour: the enumerator taps submit twice because the first tap gave no feedback; the app is reopened and a sync fires again for records it already sent; a device is restored from backup and re-uploads its queue. The only reliable defence is a client-generated identifier. The device assigns each submission a unique ID at the moment of creation, before any network is involved. The server enforces uniqueness on that ID, so a submission arriving twice is recognised as the same record rather than accepted as two. Two details separate a correct implementation from a superficial one: The uniqueness constraint must be enforced at the database level, not in application code. A check-then-insert in application logic has a race condition: two sync requests carrying the same ID can both pass the check before either writes. Under a flaky connection — exactly when re-sends happen — this is not a theoretical concern. The right behaviour is a database uniqueness constraint plus explicit handling of the collision, so that the request which loses the race returns the record that won rather than an error. The constraint must be scoped to the organisation. Client IDs are generated on devices, and a system serving many organisations must not let one organisation's identifier collide with another's. Getting this wrong is not a duplicate problem; it is a data isolation problem, and a much more serious one. Media attachments need the same treatment. A photo uploaded twice for the same question on the same submission should be recognised as one file, which means deduplicating on the pairing of submission identifier and field. Failure three: version conflicts The one that is least discussed and most often discovered at analysis. Forms change during a round. A question is reworded after the pilot, a choice option is added, a section is dropped. Meanwhile there are twelve devices in the field carrying whichever version they last downloaded, and their queued submissions may have been collected on a version that no longer exists in the current form. If submissions do not record which version they were collected against, you end up with one dataset containing answers to two different questions in the same column — and nothing marking where one ends and the other begins. That is not correctable after the fact. The mitigation is straightforward: stamp every submission with the form version it was collected on. With the version recorded, you can segment your analysis by version, identify exactly which submissions predate a change, and make an informed decision about whether they are comparable. What that does not do is decide for you. A stamp is a fact, not a judgement. Whether pre-change and post-change submissions can be pooled is an analytical call that depends on what changed, and no system should make it silently. The useful middle ground is a system that detects the conflict and then stops, rather than resolving it on your behalf. When a device submits against a form version older than the one currently published, that submission should be marked as conflicted and routed to a person — who accepts it, rejects it, or records why the two versions are comparable. The decision stays human; what the system contributes is that the decision gets made at all, on the record, instead of the discrepancy passing through unnoticed. The procedural mitigations matter more here than the technical one. Freeze the form before the round starts. If a change is genuinely unavoidable mid-round, make it deliberately: document what changed and when, push it to all devices at once rather than letting them update ad hoc, and note in the analysis plan how the two versions will be handled. A mid-round change made informally, device by device, produces a dataset whose version boundaries nobody can reconstruct. The metadata that makes all three tractable Whichever tool you use, check that a submission carries:Its client-generated identifier. The form version it was collected on. Timestamps for both collection and receipt — they differ under offline sync, and the difference is diagnostic. The enumerator identity. GPS, where the protocol calls for it. Its sync source, so mobile, web and offline-queued submissions are distinguishable.Together these turn all three failure modes from mysteries into queries. Without them, an anomaly in the dataset is something you argue about. The one-page checklistLocal queue, device authoritative, background sync worker. Exponential backoff with a retry cap and a visible failure state. Client-generated IDs, unique at the database level, scoped to the organisation. Media attachments deduplicated by submission and field. Form version stamped on every submission. Form frozen before the round; mid-round changes documented and pushed at once. Pending queue monitored per enumerator, per day. Scheduled daily sync point, not opportunistic sync.Items one to five are the tool's job. Items six to eight are yours, and they are the ones that most often go undone.Monival's mobile app queues locally with a background sync worker, exponential backoff and a bounded retry count. Client IDs are enforced unique at the database level, scoped per organisation, with the race condition handled explicitly rather than surfacing as an error; media attachments deduplicate on submission and field. Every submission is stamped with its form version — and when that version is older than the one currently published, the submission is marked as conflicted and held in a review queue, where a reviewer accepts or rejects it with a note and the resolution is recorded against the submission. For form design and sync strategy, see the complete guide to offline data collection.

Sibasi M&E Team

Monival Editorial

08 Jul, 2026

Field data collection is hard. Add unreliable connectivity to the mix and it becomes a logistical challenge that derails even well-funded programmes. This guide covers what actually works. Why offline-first matters Most data collection tools treat offline as an edge case — a fallback when the connection drops. The result: enumerators wait for signal, skip GPS captures, or lose submissions entirely. An offline-first approach flips this. The device is the source of truth. Everything is stored locally and synced when connectivity returns. Enumerators never wait, never lose data, and never need to worry about bars on their phone. Designing forms for the field Before your enumerators leave the office, get the form right:Keep it short. Every extra question increases collection time and dropout risk. If a question isn't in your analysis plan, cut it. Use skip logic. Don't show irrelevant questions. A well-configured skip tree can halve the time on a long form. Add GPS capture early. Put the GPS field at the start so the device acquires a fix while the enumerator fills other questions. Pilot on the actual device. A form that looks clean on a laptop can be unusable on a budget Android with a cracked screen.The sync window problem Offline sync creates a data integrity challenge: what happens when two enumerators submit answers to the same household using different form versions? Monival handles this with version-conflict detection. Every submission carries the form version it was collected on. If that version is older than the current published version, the submission is flagged for review rather than silently accepted or rejected. This lets your M&E team make a judgment call on each conflict rather than losing data. Geofencing: keeping data spatially valid One of the most common data quality issues in field surveys is submissions collected at the wrong location — either because the enumerator was at the office entering data they collected earlier, or because they simply went to the wrong community. A geofence draws a boundary around your project area. Enumerators outside it see a warning before submitting. You can configure it as:Soft warning — they can proceed after confirming Hard block — submissions outside the boundary are rejectedFor most programmes, a soft warning is the right call. You want to catch mistakes, not prevent legitimate edge cases. Practical sync strategySync at the end of each day — schedule a time when enumerators are near WiFi or a strong signal. Don't rely on opportunistic sync in the field. Use client IDs — assign each submission a unique ID on the device before it reaches the server. This prevents duplicates if an enumerator taps "submit" twice or a sync fires twice. Monitor the pending queue — your dashboard should show how many submissions are waiting to sync per enumerator, per day. A growing queue is an early warning sign.Getting data out Once submissions are in, the work of analysis begins. Export to XLSX for the team, connect Power BI via the OData feed for donor dashboards, or push to your own pipeline via webhooks. The best programmes build their output pipeline before the survey starts — not after 10,000 submissions have landed.Ready to run your next field survey on Monival? Get started free — no credit card required.

Monival Team

Monival Editorial

15 Jun, 2026

Kenya's County Integrated Monitoring and Evaluation System (CIMES) is the county-level component of the national M&E architecture — the structure through which a county is meant to track implementation of its County Integrated Development Plan and report upward to the national Monitoring and Evaluation Directorate (MED). It is well specified on paper and unevenly implemented in practice. KIPPRA found in January 2024 that only 17% of counties were fully compliant with CIMES requirements. That figure is worth sitting with, because it means the majority of counties are producing something other than what the system asks for — and organisations working with county government are frequently expected to plug into a system their counterpart is not fully running. This piece sets out what CIMES actually requires, so that NGOs, implementing partners and county M&E officers are working from the same picture. The committee structure CIMES is built on committees, not on a database. The anchor at county level is the County Monitoring and Evaluation Committee (CoMEC), which is the body responsible for coordinating M&E across county departments, reviewing performance data, and signing off the county's reports before they go anywhere. Below CoMEC the system extends downward through the county's administrative tiers, with M&E structures at sub-county and ward level, and data originating at village level. The design intent is a chain of custody for performance data: information is generated where implementation happens and is consolidated as it moves up. The practical implication for anyone supporting a county: the CoMEC is the entry point. Data that has not gone through it does not become county performance data, however good it is. Programmes that build a parallel reporting line to a single department and never engage the CoMEC produce information the county cannot use in its own reporting. The aggregation chain The reporting flow runs upward through four tiers: Village → Ward → Sub-county → County Each tier consolidates what it receives from the tier below and passes it up. This is the part of CIMES that most often breaks in practice, for an unglamorous reason: the lower tiers frequently have no systematic way to capture and transmit data, so consolidation happens by whatever means are available — paper, phone, a WhatsApp group, a spreadsheet emailed to a sub-county officer. Where a partner programme can add genuine value, it is usually here, at the ward and sub-county consolidation step, rather than at the county dashboard everyone wants to build. The report family CIMES defines a family of reports, and the acronyms are a common source of confusion — the naming varies somewhat between guideline editions and between counties, so confirm the current usage with your county before assuming. The reports you will encounter:CAMER / C-APR — the county annual monitoring and evaluation report, also referred to as the County Annual Progress Report. This is the principal annual product: the county's account of implementation progress against its plan. CoMER — the county monitoring and evaluation report produced through the CoMEC structure. CAPER — the county annual performance evaluation report.The distinction that matters in practice is between monitoring reports, which track implementation progress against planned targets, and evaluation reports, which assess performance and results. Counties commonly produce the monitoring product and thin out the evaluation one, which is one of the compliance gaps KIPPRA's assessment picks up. The calendar Two dates govern the annual cycle, and both are frequently missed:County annual progress report finalised by 31 July. Submitted to the national Monitoring and Evaluation Directorate by 30 August.Working backwards from 31 July is the whole game. Ward and sub-county consolidation has to be complete well before it — a county that begins collecting in July is producing a report from whatever happens to be available rather than from a year of monitoring. If you are a partner whose programme data feeds a county report, your own reporting cycle needs to land data with the county in time to be consolidated, not in time to meet your own deadline. That is usually a quarter earlier than partners assume. The planning artefact CIMES guidance ships a logical framework template as Annex A10. This matters more than it sounds. It means that in Kenya the logframe is not only a donor artefact. It is the expected planning and monitoring instrument for county programmes, including domestically funded ones. An NGO working with a county that presents its programme in logframe terms — result levels, indicators, means of verification, assumptions — is presenting it in the county's own format. It also means the indicator discipline applies. A county indicator without a fixed definition, a baseline and a stated means of verification has the same problems as a donor one, and the aggregation chain makes it worse: an indicator defined loosely at county level will be operationalised four different ways by four sub-counties, and the consolidated figure will be uninterpretable. What partners get wrong Building a county dashboard first. Dashboards are the visible end of the system and the least useful part to fix. If ward-level data is arriving by phone call, a dashboard displays a well-formatted version of an unreliable number. Ignoring the CoMEC. Covered above, and the most common structural mistake. Reporting on a partner calendar. If your data lands in August it cannot be in the 31 July report, regardless of quality. Assuming full compliance. With roughly one in six counties fully compliant as at KIPPRA's January 2024 assessment, the responsible starting assumption is that the structures exist on paper and are partially operational — and that finding out which parts work in your county is the first piece of work, not something to skip. Introducing indicators the county cannot sustain. An indicator that requires a data source only your programme funds will stop being reported the month your programme closes. If the aim is to strengthen the county system, indicators have to be collectible by the county. A note on what we are not asserting We have deliberately not cited a specific edition year for the CIMES guidelines, or the weightings applied to M&E within county performance contracting. Both circulate in secondary sources in versions that do not agree, and getting them wrong in a planning document is worse than omitting them. Confirm both with your county planning department or with MED directly before building either into a workplan.Monival's results module holds result nodes at impact, outcome, output and activity level with their indicators, means of verification and assumptions, displayed as a grouped logframe matrix — the same structure as the CIMES Annex A10 template. Data can be collected offline at ward level and consolidated centrally, which is the tier where county aggregation most often breaks.

Sibasi M&E Team

Monival Editorial

20 May, 2026

Let us start with the part nobody in this market should be coy about: KoboToolbox is very good, it is free, and if it is working for your data collection you should keep using it. We say this as people who build a competing form builder. Kobo is the default field collection tool across humanitarian and development work for sound reasons — mature offline support, the XLSForm standard, a large practitioner community, no licence cost. Displacing it on collection alone is not a serious proposition, and vendors who pitch you a "better Kobo" are selling you a migration you do not need. The interesting question is different: what happens to the data after Kobo? The gap, described precisely Kobo answers: what did we collect, from whom, where and when. It gives you submissions, basic summaries and exports. It does not answer:What is our current value for indicator 2.1.3, against its target for this quarter? Which submissions across which four forms contribute to that indicator, and how are they aggregated? Where does this indicator sit in our results framework, and which output does it evidence? What is the disaggregated picture by sex, ward and disability status, for the six indicators the funder asks about? What do we send the donor in their template, on the fifteenth of next month?These are results management questions, not collection questions, and there is no reason to expect a collection tool to answer them. What happens instead is universal. Someone exports to Excel. A workbook grows, one tab per form, one tab per indicator, a summary tab with formulas pointing at the others. It works for one funder and one year. Then a second funder needs a different cut, a colleague leaves, a column shifts by one, and by year three nobody is entirely sure which tab produced the figure in last quarter's report. That workbook is not a failure of discipline. It is the correct improvisation in the absence of a layer that should exist. What the missing layer has to do Five things. The list is short and the order matters. 1. Define indicators independently of forms. An indicator is an organisational object with a definition, a unit, a baseline, a target, a collection frequency, a data source and a means of verification. It outlives any individual form and is usually fed by several. Defining indicators inside forms is what makes them un-aggregatable later. 2. Link collection to indicators explicitly. A question on a form should be attachable to an indicator with a stated aggregation — a count of submissions, a sum of a numeric answer, or a distinct count of a value. Once that link exists, the indicator updates as data arrives rather than through a monthly re-export. 3. Carry the framework. Indicators attach to results, and results sit at levels — impact, outcome, output, activity — with narratives and assumptions. This is what turns a list of numbers into a logframe you can submit. 4. Track targets against actuals by period. Not a single end-of-project target. Period targets, period actuals, and the variance visible when it is still actionable. 5. Report without re-keying. The reporting layer should read from the same indicator records everyone else uses. Every manual transcription step is a place where two documents start disagreeing. Three routes, honestly compared Stay on Kobo and formalise the spreadsheet. Viable for a small organisation with one or two funders. Make it survivable: one workbook, version-controlled, one owner, indicator definitions written down in the workbook itself. Cost: staff time and key-person risk. Do not let anyone tell you this is unacceptable — for a five-person organisation it often is the right answer. Keep Kobo, add a results layer above it. Collection stays where your enumerators are trained; a results system holds indicators, framework and reporting, fed from Kobo via export or API. Advantage: no retraining and no migration. Disadvantage: two systems, and the join between them is real work that somebody owns. Consolidate collection and results in one system. One place for forms, submissions, indicators, framework and reporting. Advantage: the join disappears, and indicator values update as submissions arrive. Disadvantage: you migrate your forms and retrain field teams, and you should not do that lightly. There is no universally correct answer. The wrong move is to make no decision and let the workbook decide for you. If you do consolidate, migrate properly Two things we have learned doing this repeatedly. XLSForm gets you most of the way, not all of it. The XLSForm standard means your question text, types and choice lists are portable, and importing them is minutes of work rather than days of retyping. What generally does not survive an import between tools is the conditional logic — the relevant expressions — and repeat groups. Budget for rebuilding those and testing them, and pilot the rebuilt form on the actual device your enumerators use before anyone goes to the field. Do not migrate mid-round. Finish the survey round on the system you started it on. Splitting one round across two systems creates a reconciliation problem that outlasts whatever you were trying to gain. The honest summary Kobo is not the problem, and replacing it is not automatically the solution. The gap is the layer above collection, and most organisations are filling it with a spreadsheet that works until it does not. Whether you fill it by adding a system above Kobo or by consolidating into one, decide it deliberately — before the workbook has three years of institutional memory in it and nobody left who knows which tab is authoritative.Monival imports XLSForm files from ODK and KoboToolbox — questions and choice lists come across; repeat groups and conditional logic need rebuilding. Indicators are defined at organisation level and can be fed from form questions as counts, sums or distinct counts against a target, with disaggregation. The results framework explainer covers how the layer above collection is meant to work.

Sibasi M&E Team

Monival Editorial

22 Apr, 2026

An indicator fails an audit long before the auditor arrives. It fails at the moment somebody writes "number of beneficiaries reached" into a logframe and moves on. Six months later, the field team counts anyone who attended a session. The partner counts households, not people. The last quarter's figure counted the same person at three sessions; this quarter's deduplicated. Nobody did anything dishonest. The number is simply not one number, and when a data quality assessment asks how it was constructed, there is no answer that holds for the whole reporting period. This is the most common finding in donor data quality assessments across the programmes we have supported, and it is entirely preventable. Fix the definition before you collect anything The instrument for this in USAID practice is the Performance Indicator Reference Sheet (PIRS) — one page per indicator that fixes, before collection starts:The precise definition, including what counts and what explicitly does not. The unit of measure, and whether it counts people, events, households or something else. The disaggregation required, named in advance. The data source and the collection method. The frequency of collection and of reporting. Known data limitations — stated up front rather than discovered at audit. The baseline and the targets by period. Who is responsible for the number.The name does not matter. FCDO partners call it an indicator methodology note; some organisations call it an indicator protocol. The discipline is what matters: one authoritative definition per indicator, written before collection, and changed only through a documented process. If you take one thing from this piece: an indicator without a written definition is not an indicator. It is a phrase that different people will operationalise differently, and the divergence will be invisible until someone compares two reporting periods. Baselines: measure them, or say you did not Three failure modes, in descending order of how often we see them. No baseline at all, with a target expressed as a percentage change. This is unassessable. If you do not know the starting value, "a 30% increase" is not a target. Baseline set to zero because the project had not started. Legitimate for indicators counting project deliverables. Wrong for outcome indicators, which measure a condition in the population that existed before you arrived and will not have been zero. Baseline collected on a different instrument from the follow-up. A baseline survey with a differently worded question, a different sampling frame or a different recall period does not baseline the indicator you are now reporting. This is the one that most often destroys an endline comparison, and it is discovered too late to fix. Where a baseline genuinely cannot be measured, say so explicitly in the indicator definition and state what will be used instead. A documented limitation is an acceptable audit finding. An undocumented one is not. Disaggregation is a design decision, not a reporting one You can only disaggregate by something you captured. This sounds obvious and is routinely ignored: teams report a total, are later asked for a sex or disability breakdown, and discover the field was never on the form. Decide the disaggregation dimensions at design and put them in the indicator definition. The standard set — sex, age band, location, disability status — should be the default question, and any decision to omit one should be a decision rather than an oversight. There is a second reason beyond compliance. The OECD-DAC effectiveness criterion explicitly includes differential results across groups, and the equity E in a value for money assessment cannot be evidenced at all without disaggregated data. An aggregate number that hit its target while excluding a group is not a success, and without the breakdown nobody can tell the difference. Be careful with age bands. Bands that do not match the funder's reporting categories cannot be re-cut afterwards — you cannot split a 15–24 band into 15–19 and 20–24 once collection is done. Capture date of birth or exact age where you can, and band at analysis. Means of verification must be a source you actually have The means of verification column asks where the evidence comes from. Two tests it must pass: Does the source exist, in the form you need? Naming a national health information system as the MoV for an indicator that system does not disaggregate the way your funder requires is a design failure that surfaces at the first report. Can you afford it, at the stated frequency? A quarterly household survey named as the MoV for six indicators is a budget line, not a checkbox. If the budget does not carry it, the indicator will be reported from something else, undocumented — which is precisely the divergence an audit finds. What a data quality assessment actually tests The standard dimensions, and what each one means in practice:Validity — does the indicator measure what it claims to? Attendance is not learning. Reliability — would the same method produce the same result if repeated? This is what a stable written definition protects. Timeliness — is the data available in time to inform decisions, or only in time to report? Precision — is the margin of error small enough for the use? A number derived from a small purposive sample should not be presented as a population estimate. Integrity — is the data protected against manipulation, deliberate or otherwise? Who can change a submitted value, and is that change recorded?Integrity is where paper-and-spreadsheet systems fail hardest. If the reported figure lives in a spreadsheet that six people can edit and no version history exists, there is no answer to "who changed this and when", and the auditor will write that down. The practical checklist Before collection starts on any indicator:A written definition exists, naming what counts and what does not. Unit of measure is stated. Disaggregation dimensions are named and the corresponding questions are on the form. The data source is named and access to it is confirmed. Collection frequency is stated and budgeted. A baseline value exists, or its absence is documented with the reason. Targets are set by period, not only at end of project. One named person is responsible for the number. Known limitations are written down before anyone asks.Nine lines per indicator. It is a morning's work for a typical logframe, and it is the difference between an audit that confirms your reporting and one that qualifies it.Monival holds indicators as organisation-level records — baseline, target, collection frequency, data source and means of verification on the indicator itself, with actuals recorded by period. Indicators can be fed directly from form questions as a count, sum or distinct count, disaggregated by other questions on the same form, so the breakdown is a property of the design rather than something reconstructed later.

Sibasi M&E Team

Monival Editorial

18 Mar, 2026

The question comes up in almost every design workshop we run, and it is usually framed as a choice: should we do a logframe or a theory of change? Behind it sits a real anxiety — someone has been told logframes are outdated and linear, someone else has been told theories of change are unaccountable diagrams, and the proposal is due on Friday. The framing is wrong. They answer different questions, and in most organisations the honest answer is that you need both, built in a specific order. What each one is actually for A theory of change explains how and why change is expected to happen. It is built backwards from the long-term outcome through the preconditions that must be in place, with the assumptions on each link written down and open to challenge. Its job is explanatory. It is the document you argue about. A logframe summarises what you will deliver, how it will be verified, and what must hold true, in a four-column matrix. Its job is contractual. It is the document you are held to. One is a model. The other is a commitment. Asking which to use is like asking whether to have a design or a contract. The order matters more than the choice Build the theory of change first. Derive the logframe from it. Done in that order, the logframe's assumptions column writes itself, because the assumption elicitation already happened. The outcome row is defensible, because the pathway showed which precondition the intervention can realistically own. The indicators sit at the right level, because the pathway distinguishes what you deliver from what changes as a result. Done in the reverse order — logframe first, theory of change added later because a funder asked for one — you get what the sector produces in volume: a diagram of the logframe with arrows drawn between the boxes. Every box is something the project does. No box represents anything another actor must do or anything about the world that must be true. That is a workplan in a nicer layout, and any assessor who reads theories of change for a living will recognise it in about ten seconds. In fifteen years of running M&E across East Africa, the most common single cause of a programme quietly losing its way in year two is that nobody ever wrote down the assumptions. The activities happened. The outputs were delivered. The outcome did not move, and by the time anyone asked why, the belief that connected the two had never been recorded, so there was nothing to check. Which one the funder wants The pattern is fairly consistent. Institutional grant compliance wants the logframe. European Commission applications through EuropeAid and DG INTPA generally require one as an annex. GIZ, UN agencies, the African Development Bank and IFAD all work with them. In Kenya, the national M&E guidance under CIMES ships a logframe template as Annex A10, which makes it the expected artefact for county programme planning too. Foundations and bilateral strategy processes want the theory of change. FCDO business cases include one and assess its quality. The Gates Foundation, Comic Relief, Ford, Hewlett and Global Affairs Canada all use theory of change as a core instrument. Most organisations of any size are applying into both worlds in the same year. Maintaining one coherent theory of change per programme, from which project logframes are cut, is much less work than maintaining a parallel set of unrelated documents — and it is the only way the two stay consistent when a reviewer reads them side by side. When one of them genuinely does not apply Two honest exceptions. Skip the elaborate theory of change for a small, well-understood, single-strand intervention where the causal claim is not in dispute. If you are rehabilitating a borehole, a theory of change adds ceremony, not clarity. Write the logframe, write the assumptions properly, and get on with it. Skip the logframe where results genuinely cannot be specified in advance — advocacy, coalition-building, systems change, work whose success depends on a policy window nobody controls. There the right instrument is a theory of change to frame the intent and outcome harvesting to find out what actually changed. But be clear-eyed: this has to be agreed with the funder at contracting. You cannot accept a target-based contract and then explain at evaluation that results were unforeseeable. A note on the third document If you work at portfolio or strategy level, there is a third artefact that gets confused with both: the results framework. It is hierarchical like a theory of change and results-focused like a logframe, but it is a strategy artefact — goal, development objectives, intermediate results — covering many interventions over a strategy period, and it deliberately excludes activities. The clean arrangement in an organisation running several programmes: one results framework for the strategy, one theory of change per programme, one logframe per funded project, with each project's logframe mapping upward into an intermediate result. When that mapping cannot be drawn, you have learned something useful about your portfolio. What to do on Friday If the proposal is due and you have neither: spend half a day on the backwards mapping with the people who know the context, write the assumptions down, then cut the logframe from it. Half a day of pathway work produces a materially better logframe than two days of filling in the matrix directly, and it produces a document you can defend at inception rather than one you have to quietly rewrite.Monival's results module holds result nodes at impact, outcome, output and activity level with their assumptions and indicators, displayed as a grouped logframe matrix. Theory of change facilitation is delivered by Sibasi as consulting rather than in the product — see the explainer for exactly what that means.

Sibasi M&E Team

Monival Editorial

19 Feb, 2026