ICARE Programme - MIS
Role & duration: MIS Specialist (sole consultant). December 2025-present. (ICARE: Integrated Corporation of Agricultural Resource Empowerment / Agriculture Value Chain Development Project, World Bank loan project, Ministry of Agriculture Indonesia.)
TL;DR
- Problem: A 3-year-old World Bank-funded agriculture programme had zero MIS infrastructure to track and report its KPIs.
- Solution: Built an end-to-end MIS from scratch in 7 months as a solo consultant.
- Impact: Reduced financial reporting from 1 week to minutes, backfilled 11,000+ historical transactions, and delivered a KPI dashboard validated by the World Bank.
- Tech Stack: Laravel, Alpine.js, MySQL, GitHub Actions.
Context & Problem
Three years into the ICARE programme, no MIS existed. The only digital presence was a vendor-built profile website for announcements.
- Who had the problem. The ICARE programme management, provincial offices (10 provinces + 1 HQ), and the World Bank needed a system to record, track, and report programme KPIs. But none existed. Farmer data, beneficiary records, cooperative data, and financial realization were all unstructured.
- Why it mattered. Without a functioning MIS, there was no credible way to measure or report programme achievement against World Bank project development objectives. This made it nearly impossible to prove impact at review.
- Condition before. No MIS architecture. No beneficiary database. No financial consolidation system. No KPI dashboard. Field offices across 10 provinces had no standardized way to submit or track data. Everything was done manually, on an ad hoc basis.
Constraint
- Zero foundation to build on. Unlike a legacy system with existing data, there was nothing: no database schema, no data collection process, no defined indicators. Everything had to be designed from scratch.
- Solo consultant. I was the sole MIS Specialist. Decisions on architecture, data model, feature prioritization, and deployment were all mine to make and own.
- Time pressure against programme lifecycle. I joined in December 2025, three years after the programme started. There was urgency to produce auditable KPI data quickly to support ongoing World Bank review cycles.
- Distributed user base. The system needed to serve 200+ users across 10 provincial offices and 1 headquarters. Each had different roles, data responsibilities, and varying levels of technical familiarity.
- World Bank reporting standards. Financial reports had to align with the Annual Work Plan and Budget (AWPB) framework. This is a specific structure tied to World Bank disbursement requirements, not a generic format.
Decision & Trade-off
Build for the programme’s actual KPIs, not generic data collection. The temptation in an MIS with no prior foundation is to collect everything and figure out what matters later. I resisted that and started by mapping the programme’s project development objectives and the indicators the World Bank would actually assess. Then I worked backward to define what data needed to be collected, by whom, and at what frequency. This meant some features were deliberately excluded even if stakeholders asked for them, because the data wouldn’t contribute to any measurable outcome.
Prioritize financial reporting integration early. The finance team was spending a week on every reporting cycle, manually reconciling disbursement data against the AWPB. I recognized early that the World Bank’s financial reporting structure follows a predictable pattern. Once I mapped programme expenses to AWPB line items inside the system, consolidation became a matter of minutes. Beyond the current cycle, I also used this as an opportunity to backfill all historical transactions back to 2022, giving the programme a complete, auditable financial record for its entire lifetime.
Design for voluntary adoption, not compliance. Getting 200+ users across 10 provinces to actually enter data is a different problem from building the system itself. My approach was to give field offices something back for their effort. Rather than just collecting data upward to HQ, I built provincial dashboards that showed each office their own KPI progress. Data entry came with an immediate, visible benefit for the person doing it. This shifted the dynamic from “we’re being monitored” to “we can see how we’re doing.”
Survey-based approach for PDO indicators that can’t be fully enumerated. Some project development objective metrics (like income change and behaviour adoption) can’t be captured through routine data entry alone. Rather than leaving these unmeasured or estimating them, I designed a purposive sampling survey across 2,000+ respondents. The methodology and results were reviewed and accepted by the World Bank as valid programme achievement data.
Implementation
Stack: PHP (Laravel), Alpine.js, MySQL, Spatie Activity Log, GitHub Actions (CI/CD).
System architecture from scratch. Designed the full database schema, deployment infrastructure, job scheduling, and data flow before writing a single feature. Starting from zero meant architecture decisions would compound, getting this wrong early would be expensive to undo.
Beneficiary & farmer registry. Built the core data collection layer: farmer profiles, programme beneficiaries, cooperative records, and field-level impact data. 30+ features across 10 provincial offices and 1 HQ, supporting 200+ users with role-based access.
Financial consolidation module. Mapped the programme’s financial structure to the World Bank’s Annual Work Plan and Budget (AWPB) format. What previously took the finance team one week per reporting cycle now runs in minutes. Within the 7-month period I also backfilled ~11,000 financial transactions dating back to the programme’s start in 2022, producing a complete lifetime financial record for the project. This gave both programme management and the World Bank a full, auditable view of disbursements from day one, not just from when the MIS was built.
KPI achievement dashboard. Built a project achievement and financial realization dashboard. The World Bank team acknowledged it directly, notable given it was delivered within months of joining a three-year-old programme with no MIS baseline.
PDO survey system. Designed and implemented a purposive sampling survey for project development objective indicators that couldn’t be captured through routine data entry alone. Collected responses from 2,000+ participants; results validated and accepted by the World Bank as official programme achievement.
Provincial dashboards. Each of the 10 provincial offices received their own view of KPI progress, giving field staff visibility into their own data. This deliberate design choice aimed to incentivize voluntary and accurate data entry rather than relying on top-down mandates.
Business Impact
| Metric | Before | After |
|---|---|---|
| MIS existence | None (profile website only) | Full system: 30+ features, 200+ users |
| Financial report consolidation | ~1 week (manual) | Minutes (automated) |
| Financial transaction coverage | Fragmented / unstructured | ~11,000 transactions backfilled from 2022, full project lifetime record |
| PDO indicator measurement | Unmeasured | Validated by World Bank via 2,000+ survey |
| KPI dashboard | None | Live, acknowledged by World Bank team |
| Provincial data visibility | Zero | Each office tracks own KPI progress |
- Built the entire MIS infrastructure from zero in approximately 7 months, covering all 10 provincial offices and HQ.
- Financial reporting module eliminated a week-long manual process per reporting cycle.
- KPI and realization dashboard received direct appreciation from the World Bank project team.
- Survey-based PDO measurement accepted by the World Bank as valid official achievement data.
Lesson Learned
Understand the programme context before writing a single line of code. Getting the wrong mental model of what a programme is trying to achieve is the most expensive mistake you can make. Features get built, data gets collected, and none of it maps to what the lender will assess at review. The fix is to go to the source early: the lender documentation, the programme logframe, the management team. A week spent understanding context is worth more than a month of building the wrong thing.
Initiative has to come from the consultant, no one will hand you a requirements document. People who have worked around a problem for years stop seeing it as a problem. Generic questions (“is there anything you’d like to improve?”) produce generic answers. The approach that worked for me was to observe how teams actually worked (like watching a reporting cycle or sitting in on a field coordination call) and then come back with a specific proposal: “this process looks like it takes three days; I think we can get it to thirty minutes with X, want to try?” That’s when people engage. Concrete, specific, with a visible payoff.
Empathy is what makes a system used voluntarily. Field staff entering data into a central system are doing work that primarily benefits someone else (HQ, the lender, management). If there’s no visible return for them, data quality suffers and participation is grudging at best. The solution isn’t more enforcement; it’s closing the feedback loop. When provincial offices could see their own progress in the dashboard, their own KPI realization, their own survey completion rate, data entry stopped being a burden and started being useful to the people doing it.