Process analysis

The Global Fund generates an enormous amount of operational data. Much of the grant lifecycle is managed in Salesforce, and every stage leaves a timestamped trail. What makes that data harder to read than it first appears is that the path through the lifecycle is not uniform. The steps that apply to a given grant depend on how its portfolio is classified, and on whether the grant runs on-cycle (the standard grant cycle, typically January to December three years later) or off-cycle, which shifts the timing of everything downstream.

So before you can ask where time is being lost, you first have to reconstruct which process each grant actually followed.

The question I was looking at centred on the Principal Recipient reporting cycle, and it is a long one. A Principal Recipient submits its progress and financial reporting. The Local Fund Agent, an independent assurance provider that acts as the Global Fund’s eyes and ears on the ground, reviews it. The Country Team then reviews it in turn, with the Finance Specialist, the Public Health and Monitoring & Evaluation Specialist, and the Program Officer and Fund Portfolio Manager each examining their part.

Reports can go back to the Principal Recipient or the Local Fund Agent for corrections, be re-validated by the relevant stakeholders, and only then reach final validation, at which point a performance letter is issued to the Principal Recipient with a rating on both financial and programmatic elements.

Every one of those hand-offs is recorded. The difficulty was never access to the data; it was the sheer volume of it, and the fact that no single view showed where a report actually spent its time.

The first step was to rebuild the process from the data itself. That meant pulling the step-level timestamps out of Salesforce, standardising them into a single table with one row per reporting run, and cleaning them (handling the runs with missing steps and the inevitable outliers) before measuring anything at all.

None of this is exotic. It is careful data preparation followed by a few well-chosen visualisations. The figures below are generated from a synthetic dataset that mirrors the shape of the real thing, using the same code; I also rebuilt the full walkthrough as an interactive piece you can step through yourself.

The output was a granular, per-stakeholder view of the reporting cycle: for each step, and for each actor in it, how long things actually took against the target, and where duration concentrated. A Gantt-style overlay of actual versus target durations turned a vague sense that “reporting takes too long” into specific, locatable delay.

Breaking the same picture down by category separates systemic delay from localised bottlenecks. In the deviation heatmap, a row that is uniformly warm points to a group that runs late everywhere; a single warm cell in an otherwise neutral row points to one specific step that stalls, a very different problem to solve.

Seen that way, a handful of bottlenecks were clear enough to act on. Two are worth describing because they show how mundane the fixes often are.

The first was automating data validation at the Principal Recipient stage, so that common errors were caught at submission rather than discovered several reviews later and bounced back through the chain. The second was allowing Principal Recipients and Local Fund Agents to submit the financial and programmatic sections separately, so that review at the Local Fund Agent and Global Fund stages could begin on whatever was ready instead of waiting for the complete package.

Neither is a modelling breakthrough. Both came directly from seeing, in the data, where the process actually stalled.