Module: M&E Fundamentals — Module 5 Focus: Who does what in an M&E system — from the point of data collection at the facility to the point of decision-making in the boardroom — and how ambiguity in roles becomes a data quality failure. Target: Entry-Level M&E Officers, Data Managers, Program Coordinators & Facility Focal Persons Delivery: Facilitator-led instructional tabs with applied HIV/TB, agriculture, and multi-sector activities
Before we ask who runs the M&E system, let’s consolidate the key ideas from Module 4: M&E Data Sources — because roles only make sense once you know what pipeline those roles are managing.
1. Source Selection Is Not Neutral Every data source — primary or secondary, routine or nonroutine — carries a cost, a bias risk, and an ethical burden on whoever collects it. Choosing a source is choosing who does the work.
2. The Seven Quality Dimensions Validity, reliability, completeness, timeliness, accessibility, coverage, and freedom from bias. Each of these dimensions can fail silently if no one is specifically responsible for checking it.
3. Method Must Match the Question Quantitative methods answer “how many/what percentage.” Qualitative methods answer “why.” Choosing the tool is a technical decision, but someone has to be trained and mandated to apply it correctly.
4. Tool Design Is a Discipline Metadata fields, standardized codes, pre-testing, and consent steps are not optional extras — they are what makes a record traceable back to a person and a moment. Traceability is meaningless, however, unless there is a defined person to trace it to.
5. The Data Collection Plan (DCP) The DCP’s fifth and final question — “Who is responsible for collection, entry, and verification?” — is the direct bridge into this module. Module 4 taught you to write that column. Module 5 teaches you what belongs in it.
A perfectly designed indicator, sourced from a perfectly appropriate data source, using a perfectly validated tool, still fails if no one is clearly and formally responsible for collecting it, entering it, checking it, analysing it, and acting on it.
Most data quality failures in real HIV/TB and public health programmes are not technical failures — they are accountability failures. A field is left blank because no one was told it was their job to fill it in. A validation rule is ignored because the person who built it left the organisation and took the only login with them. A report reaches the donor with an unexplained spike because it passed through three people, and none of them believed checking it was their responsibility. Module 5 is about closing that gap.
An M&E system does not fail because nobody knows what to measure. It fails because nobody knows whose job it is to measure it correctly, check it, and use it. Role clarity is not an administrative nicety sitting outside the M&E system — it is a quality control mechanism, on par with a valid indicator definition or a well-designed tool.
💡 Expert note — Accountability is a data quality dimension, not just a management concept: Global Fund and USAID Data Quality Assessment (DQA) frameworks explicitly assess “management systems” — including whether roles and responsibilities for data collection, entry, and verification are formally documented — as one of the core dimensions of data quality, alongside accuracy, reliability, and timeliness. A programme can score well on every technical dimension and still fail a DQA because no one can produce a document showing who was supposed to check the register against the DHIS2 entry.
Think of your M&E system as a factory production line, not a single event. Raw material (a client encounter, a lab result, a household visit) enters at one end. A finished product (a validated indicator value in a donor report) exits at the other. Between the two, the data passes through multiple workstations, and at each workstation, someone is responsible for doing something specific to it — and, critically, someone is responsible for checking it before it moves to the next station.
🏭 The Factory Floor Analogy
No functioning factory allows raw material to move from station to station without a named person responsible for each step and a quality control checkpoint before the product ships. If a car left the factory with no one accountable for checking the brakes, that would not be treated as a paperwork gap — it would be treated as a catastrophic management failure.
Yet in many M&E systems, a client’s HIV status moves from a paper register, to a DHIS2 tally sheet, to an aggregate report, to a donor submission — and at no single one of those handoffs is there a named, accountable “quality checkpoint.” The data equivalent of an unchecked brake system is a viral load suppression rate that is wrong by 15 percentage points and discovered only when a donor auditor asks an uncomfortable question.
⚠️ Gap flag: Programmes frequently document what each M&E form or system does, but not who is accountable for the quality checkpoint between each stage. A results framework alone does not answer “who checks this before it moves on?” — that is what this module builds toward.
Every M&E system — regardless of sector — relies on a similar chain of actors, moving from the point of service to the point of strategic decision-making. Each actor group has a distinct mandate, and conflating them is one of the most common structural weaknesses in field-level M&E systems.
Nurses, clinicians, community health workers, and facility data clerks who generate the original record — a register entry, an intake form, a lab slip. Responsible for accuracy and completeness at the point of service, and for basic first-line verification (e.g., does this record match the client in front of me).
Own the information system itself — user accounts, data element configuration, validation rules, and org unit hierarchies. Run Routine Data Quality Assessments (RDQA), reconcile source documents against system entries, and are the first line of defence against system-level errors.
Move beyond entry and verification into analysis — trend checks, disaggregation, cross-indicator consistency, and flagging anomalies for investigation. Translate raw validated data into the indicators, dashboards, and narrative reports that management actually uses.
Consume M&E outputs to make operational decisions — reallocating outreach teams, adjusting targets, addressing underperforming sites. Responsible for acting on data, not generating or verifying it.
Use validated, aggregated indicators for donor reporting, board updates, and external advocacy. Accountable for the final reported figure, even though they are several steps removed from the original data entry — which is exactly why the checkpoints beneath them matter.
Sit outside the programme’s management chain entirely. Conduct independent assessments, mid-term and endline evaluations, and third-party DQAs. Their value depends specifically on not reporting to the programme they are evaluating.
💡 Expert note — “M&E Officer” is not a synonym for “everyone who touches data”: In practice, field teams often use the title “M&E Officer” loosely to describe anyone near the data — including people who are functionally data clerks or system administrators. WHO and USAID guidance distinguish these roles by the level of judgement exercised: data collectors and data managers largely follow defined procedures; M&E officers exercise analytical judgement (is this trend plausible, does this disaggregation reveal an equity gap); programme and senior management exercise strategic judgement (what should we do about it). Blurring these levels is a common cause of both role overload and accountability gaps.
| Role | Primary Location | Core Responsibility | Typical Failure if Role is Vacant/Unclear |
|---|---|---|---|
| Data Collector / Facility Staff | Facility / field level | Accurate, complete, timely recording at point of service; first-line verification. | Missing, illegible, or fabricated records at the source. |
| Data Manager / DHIS2 Focal Person | Facility, district, or national level | System administration, RDQA, validation rules, reconciling source documents to system. | Undetected data entry errors; uncontrolled system access. |
| M&E Officer | District or national level | Advanced analysis, disaggregation, anomaly detection, report and dashboard production. | Errors and trends go unnoticed until they reach senior management. |
| Program Manager | Programme / national level | Operational decision-making using validated indicators; resource reallocation. | Valid data collected but never used to change programme decisions. |
| Senior Management | National / organisational level | Strategic use for advocacy, donor reporting, and organisational accountability. | Donor/board reporting based on unverified or stale figures. |
| External Evaluator | Independent (outside programme structure) | Independent, objective assessment of programme performance and data credibility. | No independent check on whether the programme’s own data can be trusted. |
Verbal understanding of “who does what” degrades quickly — especially with staff turnover, a chronic feature of field-level HIV/TB and public health programmes. Three tools formalise role clarity so it survives staff changes.
Maps every M&E task against every role using four codes: Responsible (does the work), Accountable (owns the outcome, signs off — exactly one per task), Consulted (gives input beforehand), Informed (told after the fact). Section 6 builds one in full.
Step-by-step written procedures for recurring M&E processes — e.g., “Monthly DHIS2 Data Entry and Validation SOP.” An SOP answers not just who is responsible, but the exact sequence, deadline, and escalation path if something goes wrong.
Formal, individual-level documents defining a specific role’s mandate, reporting line, and deliverables — used for staff positions, DQA assessors, and external evaluators alike. A ToR is what an SOP looks like when it is written for a person rather than a process.
💡 Expert note — A RACI matrix with two “Accountable” people on one row is not a RACI matrix: The single most common design error when teams first build a RACI matrix is assigning “A” to more than one role for the same task, on the reasoning that “we’re a small team, we all own this together.” In practice, shared accountability functions as no accountability — when something goes wrong, each person assumes the other one caught it. USAID’s guidance on data management roles is explicit: each task must have exactly one Accountable role, even in a two-person team.
1. Role Ambiguity — No one is formally told, in writing, that a given task is theirs. The task gets done inconsistently, by whoever happens to notice it needs doing that month — or not at all.
2. Single Points of Failure — A common and specific version of this in DHIS2-based systems: one person holds the only administrator password, or is the only person who knows how a validation rule was configured. When that person is on leave, transferred, or leaves the organisation, the entire reporting cycle stalls or proceeds unchecked.
3. Facility-Level Capacity Gaps (“Garbage In, Garbage Out”) — Frontline staff are frequently the least trained in data handling, yet sit at the most critical point in the chain: the original record. No amount of sophisticated analysis downstream can correct for a facility register that was filled in incorrectly at the source. Investment in facility-level data literacy is not a “nice to have” — it is where most preventable data quality failures actually originate.
4. Accountability Drift Over Time — Roles that were clear at project start-up quietly erode as staff change, without anyone updating the RACI matrix, SOP, or ToR to reflect the new reality. Six months later, the documented system and the actual system no longer match.
💡 Expert note — “Password hoarding” is a management failure, not an IT failure: When a single DHIS2 super-user account is shared informally or controlled by one irreplaceable staff member, this is frequently treated as a technical/IT issue. It is actually a role design failure: it reflects the absence of a documented, role-based access policy specifying which position — not which individual — holds administrator rights, with a formal handover procedure built in from day one.
The diagram below traces an Orphans and Vulnerable Children (OVC)/HIV programme record from intake through to national reporting, organised into horizontal swimlanes by administrative level. Note the downward feedback arrows — a functioning M&E system does not just push data upward; it pushes corrections and results back down to the field officers who originated the record.
Reading the diagram: Solid arrows represent the upward flow of raw and aggregated data. Dashed purple arrows represent the downward feedback loop — validated results and data-quality corrections returning to the field officers who originated the record. A data flow diagram that only shows upward arrows is incomplete: it models reporting, not learning.
💡 Expert note — Why the lines converge only at the top: Notice that the implementation line (Field Officers → Program Manager) and the evaluation line (Data Collectors → Data Manager → M&E Officer) run in parallel and meet only at senior management. This is deliberate: it preserves the separation discussed in Section 3 between the people delivering the activity and the people verifying and analysing the record of it. The dashed lines show the External Evaluator sitting entirely outside both chains, reporting directly to the Director/Board — the structural feature that makes an evaluation “independent.”
| M&E Task | Field Officer | Data Clerk | M&E Officer | Project Manager | Director |
|---|---|---|---|---|---|
| Tool Design | C | I | R | A | I |
| Data Collection | R | I | A | I | I |
| Data Entry | I | R | A | I | I |
| Data Cleaning | I | R | A | I | I |
| Analysis | I | I | R | A | I |
| Donor Reporting | I | I | R | A | C |
How to read this matrix: Every row has exactly one gold “A” cell — one Accountable role per task, per the rule flagged in Section 4. Notice that the Field Officer is Responsible (R) for Data Collection but only Informed (I) of Donor Reporting — they generate the raw material but are not expected to know the final reported figure. Conversely, the Director is Consulted (C), not Accountable, for Donor Reporting in some organisations — adjust this matrix to reflect your own governance structure; the tool works only when it reflects reality, not aspiration.
Activity 1: The Broken Chain (Case Study — HIV/TB Programme)
A district DHIS2 report shows a 300% unexplained spike in malaria co-infection cases among TB clients for the current reporting month, compared to the prior three-month average. The programme’s existing SOP for monthly reporting states only: “Facility data is compiled and submitted to the district by the 5th of each month.” It does not name who compiles it, who checks it before submission, or what to do if a figure looks abnormal.
Task: Working in groups, map the data’s actual journey backward from the DHIS2 report to the original facility register, using the SOP as your only guide. At each step, identify: (a) who probably touched the data, based on typical facility staffing, and (b) where the SOP’s ambiguity would have allowed an error — a transcription mistake, a double-entry, or a misapplied indicator definition — to pass through unchecked.
Debrief: Rewrite the single-sentence SOP into a short, role-explicit procedure (3–5 steps) that would have caught this spike before it reached the district report. Which RACI code was effectively missing from the original SOP?
Activity 2: Build the RACI (Case Study — MEH Project)
The MEH project runs two core data instruments: Participant Tracking Forms (completed at every client visit) and Monthly Surveys (aggregated satisfaction and outcome data submitted to the donor). Your facilitator will distribute a blank RACI matrix with the following tasks as rows — Design the Tracking Form, Train Staff on the Form, Collect Participant Data, Enter Data into the System, Clean and Validate Monthly Data, Compile the Monthly Survey Report, Submit the Report to the Donor — and three roles as columns: M&E Team, Project Manager, Director.
Task: As a group, assign exactly one R, A, C, or I to every cell, following the rule that each task must have exactly one Accountable (A). Where your group disagrees on who should hold the “A,” discuss why — disagreement here usually reveals a real ambiguity in how the project is currently run, not just a training exercise artefact.
Debrief: Compare your completed matrix with a neighbouring group’s. Where do they differ? What does that difference suggest about how each group assumes authority and accountability should be distributed on a small project team?
Activity 3: Map Your Own Data Flow
Using sticky notes (or a shared digital whiteboard for remote cohorts), each participant maps the actual data flow for one indicator they work with in their own organisation — from the point where the raw data is first recorded to the point where it appears in a report someone outside the organisation sees.
Task: Write each step of the journey on a separate sticky note (e.g., “client visit,” “paper register,” “DHIS2 entry,” “monthly report,” “donor submission”). Arrange the notes in sequence on a wall or table. For each node, add a second sticky note in a different colour naming the person or role Accountable at that step. If you cannot name one, leave it visibly blank.
Debrief: As a class, look for blank accountability notes across the room. These blanks are not a facilitation failure — they are a live diagnostic of exactly the role-ambiguity problem this module has been building toward. Discuss, as a group, what the smallest realistic fix would be for the two or three blanks that came up most often.
Question 1 In a RACI matrix, what is the correct number of “Accountable” roles assigned to a single task?
Question 2 Which of the following best distinguishes Data Quality Assessment (DQA) from routine monitoring?
Question 3 A facility’s DHIS2 reporting stalls for three weeks because the only staff member who knew the administrator password went on leave. This is best described as:
Question 4 Why should the person who delivers a service (e.g., enrols a client) generally not be the sole verifier of their own record of that activity?
Question 5 What distinguishes an External Evaluator’s role from an internal M&E Officer’s role?
| Question | Correct Choice | Technical Trainer Rationale |
|---|---|---|
| 1 | B | Shared accountability functions as no accountability in practice — when a task has two “A”s, each party tends to assume the other is covering it. Exactly one Accountable role per task is a hard rule of correct RACI design. |
| 2 | B | Routine monitoring is continuous and performed as part of normal duties; DQA is a periodic, structured audit — ideally involving assessors with some independence from the routine reporting chain for that indicator — that specifically tests whether reported figures can be traced back to source documents. |
| 3 | B | This is a textbook single point of failure. The fix is not simply “give two people the password” — it is a role-based access policy tied to a position, with a documented handover procedure, so system access does not depend on one irreplaceable individual. |
| 4 | B | This directly parallels the subjective measurement bias covered in Module 4: when the person being evaluated also controls the verification of their own performance data, the incentive structure — even with good intentions — tends to distort the record. |
| 5 | B | Independence is structural, not a matter of title or skill. An External Evaluator’s findings carry weight specifically because they do not report through the programme’s own management line and have no stake in a favourable result. |
| Resource | Relevance to Module 5 | Access |
|---|---|---|
| USAID — ADS Chapter 201: Program Cycle Operational Policy | Defines management systems and accountability expectations within programme data systems. | usaid.gov |
| USAID — Data Quality Assessment (DQA) Guidance and Checklist | Standard checklist and procedures for conducting a formal DQA, including roles of assessors. | usaid.gov |
| UNDP — Handbook on Planning, Monitoring & Evaluating for Development Results | Guidance on Results-Based Management, including institutional roles in the M&E cycle. | undp.org |
| The Global Fund — M&E Framework and Data Quality Assurance Guidelines | Data quality assurance requirements and role expectations for grant-funded programmes. | theglobalfund.org |
| WHO — Data Quality Review: A Toolkit for Facility Data Quality Assessment | Practical toolkit for facility-level data quality assessment, including staff roles. | who.int |
| MEASURE Evaluation — Routine Health Information Systems (RHIS) Curriculum | Curriculum covering routine data system governance, including DHIS2-specific role design. | measureevaluation.org |