This is the most common mistake, and the easiest to make, because activities are easy to count. Number of people trained, meetings held, materials distributed.  These are tidy, available, and satisfying to report. But they tell you what was done, not what changed. A project can post a flawless set of activity numbers and still have achieved nothing of substance.

For example: a nutrition project can train 500 mothers (an activity) and still see no change in how children are actually fed (the outcome). The training count looks excellent in a report and tells the donor nothing about whether the project worked.

The opposite instinct, and just as damaging: when unsure, add another indicator. The result is indicator bloat, forms that take forever to complete, data nobody ever analyses, and a reporting burden that crowds out actual thinking. More indicators feel more rigorous. Usually they just dilute attention and degrade the quality of everything collected.

For example: a small grant tracking 60 indicators will collect most of them badly. The same project tracking the 15 that matter will collect them well  and a donor trusts 15 clean numbers far more than 60 shaky ones.

Without a credible baseline, you cannot answer the questions every evaluation will eventually ask: what changed, by how much, and can the change be attributed to the project? A weak or missing baseline weakens everything downstream, because the endline has nothing solid to compare against.

For example: a project that launches first and "does the baseline later" ends up measuring people already exposed to the intervention and can never cleanly demonstrate the change it actually caused.

Even the best-designed dashboard is worthless if the data feeding it is wrong. Duplicate records, missing values, calculation errors, inconsistent definitions ; these creep in silently and quietly corrupt every conclusion drawn from them. Decision-makers who can't trust the data can't trust the results, and they're right not to.

For example: if two field teams define "household" differently, your headcount is meaningless and no amount of clever analysis fixes it after the data is in. Quality has to be built at collection, not patched at the end.

This is the quietest failure and one of the most serious. Data comes in, reports go out, dashboards update and no decision is ever made differently because of any of it. The system runs, but it doesn't steer. Monitoring becomes a compliance ritual instead of a management tool, and the project flies blind through the very moments the data was meant to guide.

For example: a monthly dashboard that's dutifully updated but never opened in a management meeting is pure cost. The remedy isn't a prettier dashboard, it's a standing agenda item where the data is actually discussed and acted on.

Communities are too often treated as recipients of services rather than partners with a voice. When there's no feedback channel, when complaints are ignored, or when there's no mechanism to respond and close the loop, the project loses both the trust of the people it serves and one of its most valuable sources of course-correction.

For example: a food distribution with no feedback channel won't hear that the collection point is unsafe for women to reach until attendance quietly drops and no one can explain why.

Many organisations ask only one question of their data: "did we hit the target?" Far fewer ask the questions that actually improve programming;  why did it happen, what didn't work, and what should we do differently next time? Without a learning culture, mistakes repeat across cycles, opportunities are missed, and programmes stagnate. Reporting looks backward; learning is what moves a project forward.

For example: two project cycles that repeat the same targeting error, because no one paused between them to ask why uptake was low, is a failure of learning not a failure of data. The numbers were there; nobody acted on them.