Twelve Months to Spend It, Ten Weeks to Do It

A grant has two clocks. The money clock runs on somebody's fiscal year and the delivery clock runs on the rain, and in this region they are not in phase. The quarterly report asks you to put both numbers on one page, and the temptation is to make them agree.

Projects & Job Costing AWRA OpsHub Team Operations Insights August 6, 2026 11 min read

The quarterly report is due on Friday and it has two figures on the front page. Thirty-one per cent of the budget is gone. Nine per cent of the workplan is done. Both numbers are correct, both came out of the same system, and the programme is not in trouble — the boreholes are drilled in the dry months and it has been raining since March. Everyone in the room knows this. Nobody knows how to put it on the page without it reading like an excuse.

This is the recurring problem of grant-funded delivery in East Africa, and it is not a reporting-format problem. It is that a grant carries two independent clocks. One is administrative: a budget, a period, a fiscal year that somebody in another country chose. The other is physical: a delivery window set by the roads, the rain, the school terms and the harvest. The first clock is negotiable. The second is not, and no amount of underspend buys you back a week of it.

The two clocks, and why only one of them is a choice

Take a water programme with a twelve-month grant beginning in October. The money is available from day one and the reporting is quarterly. The drilling rig can work from roughly December to March, and again — if the short rains are light — for a few weeks either side. That is the delivery window. It is about fourteen weeks inside a fifty-two week grant, and it does not move because a report is due.

Now run the arithmetic that a quarterly report invites. At the end of quarter one you have spent on mobilisation, survey and procurement, and drilled nothing. At the end of quarter two you have drilled almost everything. At the end of quarter three you have spent very little and delivered nothing, because the long rains closed the sites. A straight-line reading of that programme flags it as failing twice and succeeding once, and all three readings are wrong. The programme delivered exactly on plan, in a shape that a straight line cannot describe.

Clocks the system computes independently: task completion and budget consumption. They share no inputs

Sources that make up actual cost: logged labour, purchase orders, booked expenses and stock issued from your own store

Amount fields on a milestone. It is a date and a status, deliberately — a schedule marker, not a billing event

The delivery window is a regional fact, not a programme excuse

What makes this an East African post rather than a general one is that the window is unusually strong here and unusually variable across a short distance. Much of the region has two rainy seasons rather than one, which produces two delivery windows a year instead of a single long one — and a programme designed against the wrong pattern loses half its year to a season that its plan says should be open.

Area	Broad rainfall shape	What it does to a delivery plan
Much of Kenya, Uganda, northern Tanzania	Bimodal — long rains around March to May, short rains around October to December	Two working windows a year, each roughly a quarter long. Anything requiring dry ground gets two attempts, not one
Ethiopian highlands	Kiremt main rains around June to September; belg rains around February to May	The main window sits where much of the region is dry, so a multi-country programme cannot share one calendar
Rwanda, Burundi	Two wet seasons, broadly February to May and September to December	Short dry gaps between them. Field work is planned in weeks, not quarters
South Sudan and much of the far interior	One long wet season, roughly April to November	Large parts of the road network become impassable. This is a logistics constraint before it is an agricultural one
Southern Tanzania and areas south of it	Unimodal — a single wet season roughly November to April	One window a year. A missed season is a missed year, and no-cost extensions become the normal remedy rather than the exceptional one

Layer the non-climatic windows on top and it tightens further. School-based programmes work to a three-term year and cannot train teachers in week two of term one. Agricultural programmes are pinned to planting and harvest, which are themselves pinned to the rain. Health campaigns compete for the same district staff as the national immunisation rounds. None of these are in the grant agreement, and all of them are in the delivery plan.

The budget year was agreed in a meeting. The delivery window was not agreed by anybody. When they disagree, the meeting loses.

What the system actually computes, and what it refuses to

A project in the system carries both readings, and it is worth being exact about where each one comes from, because the shape of the two calculations is the argument.

Reading	How it is computed	What it is blind to
Progress	Tasks marked done, divided by tasks not cancelled. Rounded to a whole percent	Size. Every task weighs the same — a borehole drilled and a meeting minuted each move the figure by one task
Budget consumed	Actual cost divided by the project's budget amount	Delivery. Money spent on mobilisation reads identically to money spent on the deliverable
Effort	Hours logged against the project's budgeted hours	Both of the above. It is a third clock, and it agrees with neither

The equal weighting of tasks is the one that surprises people, so it is worth sitting with. If your workplan is thirty tasks and twenty of them are preparatory, the progress figure will run ahead of reality early and stall later, because you did the cheap tasks first. If it is thirty tasks and one of them is "drill twelve boreholes", the figure will sit at three per cent through the entire drilling season. Neither is a defect. Both are the direct consequence of counting tasks, which is the only thing a task count can do.

The practical response is to write the workplan into tasks at roughly even size, and to break the big deliverable into the units you actually report on. Twelve boreholes is twelve tasks, not one. That single decision does more for the honesty of your progress figure than any reporting feature.

Actual cost is four things, and three of them wait for approval

The money clock is better built than the delivery clock, and the reason matters for grant work: it distinguishes committed spend from requested spend at every source.

Logged labour — hours booked against the project's tasks, valued at the cost rate stamped on each entry, falling back to the project default. This is the burn that no procurement process sees.
Purchase orders attributed to the project, counted only at approved or completed status. A raised or pending order is a plan, not a cost.
Booked expenses against the project — the field costs that never go near procurement. Counted only when they are neither pending approval nor rejected. A claim awaiting sign-off is not spend, and a refused one never was.
Stock issued from your own store to the job, valued at the unit cost stamped on the issue line at the moment it left, not at today's weighted average. A later purchase that moves your average cannot retroactively change what a job that closed in March cost.

That last one is the difference between a project cost you can defend in an audit and one you cannot. Grant audits happen after the fact, sometimes long after, and the question is always what this activity cost at the time. A system that revalues historic issues at current cost gives a different answer every time you ask, and every answer is defensible on its own terms and none of them are reproducible.

One water programme, four quarters, one delivery window

Grant, twelve months from October 100%

Q1 — mobilisation, survey, procurement. Boreholes: 0 of 12 18% spent

Q2 — drilling season. Boreholes: 9 of 12 61% spent

Q3 — long rains, sites closed. Boreholes: 9 of 12 68% spent

Q4 — second window, completion, handover. Boreholes: 12 of 12 94% spent

Two quarters out of four look like failure on a straight-line read, and the programme delivered in full On plan

Illustrative, and the shape is the point rather than the figures. Notice Q3: three points of spend and no delivery at all, which is the quarter that generates the most anxious questions and represents the least risk in the whole programme. Notice also that the underspend at the end of Q1 is not a warning sign — it is a rig that has not started, and no reporting threshold distinguishes that from a rig that never will.

What we do and do not do

Measured against the code, August 2026

What AWRA OpsHub does today

A project holds a task list, milestones with due dates, sprints with start and end dates, an owner, a budget amount and budgeted hours.
Progress is derived from task completion and never stored, so it cannot go stale or be edited to look better.
Actual cost sums four real sources — logged labour, approved purchase orders, committed expenses and stock issued from your own store.
Every non-labour source filters for committed spend. A pending expense claim, a rejected one and an unapproved purchase order are all excluded from actual cost.
Issued stock is valued at the unit cost recorded when it was issued, and lines with no recorded unit cost are skipped rather than estimated.
Billable time carries an invoice link, so you can see exactly which logged hours have been billed and which have not.
Milestones have three states — open, met, missed — so a slipped date is recorded as slipped rather than quietly moved.

What it does not do

There is no per-line project budget. A project has one budget amount. A donor budget with fourteen lines and virement rules between them cannot be expressed on the project.
The budget module that does have lines is departmental — it is keyed on department, category and a date range, and has no project link at all. You cannot point it at a grant.
A milestone carries no amount, no document and no weight. It cannot trigger an invoice, cannot represent a tranche, and does not affect the progress figure.
Every task counts equally toward progress. Nothing weights a task by effort, value or size.
Nothing in the system knows about seasons. There is no delivery window, no blackout period, and no way to tell a report that Q3 was always going to look like that.
Expense categories are free text. You can type your donor's budget line names into them, and nothing validates them, groups them or budgets against them.
Project billing is time-and-materials only — billable hours against an invoice. There is no milestone-triggered or tranche-based billing.
A donor is not a modelled entity. A project links to a customer or to nothing; a funder that is neither is carried in your naming convention.

The honest summary: this is a competent delivery and job-costing system that is being asked to do grant management, and the gap between those two is budget structure. If your donor reporting is line-by-line against a fixed budget with virement rules, the project record is not where that reconciliation happens and pretending otherwise will cost you a quarter. What the project record is genuinely good at — and what most grant tracking is genuinely bad at — is knowing what an activity actually cost, from four sources, at the price it cost on the day.

This is scope, not a ceiling

What is not built for Uganda today can still be built for you

Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in Uganda. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If EFRIS fiscalisation, a bank or mobile money feed, a statutory return format, a rule your own operation needs that the standard one does not have, or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.

EFRIS fiscalisation

Invoice submission against URA's published interface, with the parts vendors gloss over — retries, a failure queue, and a daily report of sales carrying no fiscal reference.

MTN, Airtel and bank feeds

Mobile money and bank statement feeds pulled into the Payments Register, so collections match invoices without anyone re-keying a statement at month end.

The operational work, which is what most commissions actually are

An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.

Payroll and statutory returns

PAYE and NSSF schedules produced in the layout your filing body expects, generated from live payroll records rather than rebuilt in a spreadsheet each month.

Systems you already run

The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.

How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.

Tell us what you need integrated

Setting it up so the shape survives the report

Write the workplan as tasks of roughly even size

This is the highest-value decision and it costs nothing. Break the big deliverable into the units you report on — twelve boreholes, forty training sessions, six county rollouts. A progress figure built on evenly sized tasks is roughly honest; one built on a mix of "hold inception meeting" and "deliver the programme" is noise.
Use milestones for dates you will be judged on, not for everything

A milestone is a schedule marker with three states. Its whole value is that a missed one stays missed. Put the donor-facing dates on it — reporting deadlines, tranche conditions, handover — and let the tasks carry the work. Twenty milestones is a second task list and it will be neither maintained nor believed.
Model the reporting period as a sprint

A sprint carries a start and an end date and nothing else claims to be a reporting quarter. Use it as one. It gives you a time box you can point at when the question is "what moved between January and March", which is the only form the question ever actually takes.
Decide where the budget lines live, and write it down

They are not on the project. So either the donor budget lives in a spreadsheet that is reconciled to the project figure at each report, or you mirror the lines as expense categories and accept that nothing enforces them. Both are legitimate. Choosing neither, and discovering at the first report that you assumed the other, is the failure mode.
Attribute purchases and stock issues to the project from day one

Three of the four cost sources need a project link on the transaction — the purchase order, the expense and the stock adjustment. Attribution is nearly free at entry and effectively impossible to reconstruct at quarter end, when the person who raised the order has moved to another programme.
Record the delivery window somewhere a human will read

The system will not hold it. Put it in the project description, in plain language, with the reason: "field work December to March and again briefly in September; sites inaccessible in the long rains." Every future variance conversation starts from that sentence, including the ones you are not in the room for.