Making a 40+ application transformation visible.
Programme reporting, data integration and status standardisation for a Finance eInvoicing transformation spanning more than 40 impacted applications.
Large transformations fail quietly when status means different things to different teams.
The eInvoicing programme affects a broad application landscape. My role sits on the visibility layer: combine programme data, define consistent status logic and help Finance and technology stakeholders understand where testing and integration actually stand.
Forty applications can create forty versions of “on track”.
Different applications, testing phases and source systems naturally produce inconsistent status definitions. Reporting becomes useful only when the underlying terms, dates and counts mean the same thing across the programme.
The data problem is not just collecting status. It is defining what status means.
Standardise the language before polishing the dashboard.
Integrate
Bring together test and delivery information from QMetry, Jira, SharePoint and other enterprise sources.
Define
Standardise KPI definitions, testing phases, dates and status methodology so reporting is comparable.
Investigate
Trace reporting inconsistencies and data-quality issues back to their source rather than masking them in presentation logic.
Communicate
Turn the resulting data into decision-ready programme visibility for Finance and technology stakeholders.
What “status” looks like before and after a shared definition.
Not project data. It maps three invented tools, each with its own words, onto one set of states. The numbers below are computed at build time from invented data made with a fixed random seed. They show how the idea works, not what happened on the project.
| Shared state | Applications |
|---|---|
| Not started | 4 |
| In progress | 7 |
| Blocked | 3 |
| Complete | 14 |
| Out of scope | 5 |
| Unclassified | 7 |
Red, amber, green and “TBC” say how worried someone is, or that nobody knows. They do not say what the status is. So they stay unclassified until an owner states one. A dashboard that turned them into “in progress” would look tidier and say less.
How this was computed
Labels are trimmed and lower-cased, then looked up in one table per source. A label with no entry is counted and listed, never guessed (0 in this run). Applications whose shared state differs from the state the generator started with, not counting unclassified ones: 0.
| Source | Label (after trimming, lower case) | Shared state |
|---|---|---|
| Test tool | not run | Not started |
| Test tool | passed | Complete |
| Test tool | failed | In progress |
| Test tool | blocked | Blocked |
| Test tool | n/a | Out of scope |
| Issue tracker | to do | Not started |
| Issue tracker | in progress | In progress |
| Issue tracker | in review | In progress |
| Issue tracker | done | Complete |
| Issue tracker | won't do | Out of scope |
| Hand-kept spreadsheet | done | Complete |
| Hand-kept spreadsheet | n/a | Out of scope |
| Hand-kept spreadsheet | green | Unclassified |
| Hand-kept spreadsheet | amber | Unclassified |
| Hand-kept spreadsheet | red | Unclassified |
| Hand-kept spreadsheet | tbc | Unclassified |
Code: src/lib/artifacts/status-mapping.mjs. The three vocabularies are generic examples, not any real system's settings.
What I can say — and what I deliberately do not.
Publicly safe
My role, the 40+ application scale, reporting/data-integration focus, SIT/UAT/integration monitoring, and the enterprise tools used for programme visibility.
Not represented here
Internal architecture, vendor decisions, application-level implementation details, tax positions, delivery decisions, or whether Emirates is part of the UAE government's formal pilot cohort.
The national programme entered pilot phase in July 2026.
The UAE Ministry of Finance states that Electronic Invoicing commenced with a pilot programme on 1 July 2026, followed by phased mandatory implementation. My work is presented as enterprise readiness and transformation reporting in that national context.
This case is intentionally lighter than the completed cases because the programme is current and much of the implementation detail is not appropriate for a public portfolio.
Transformation reporting is a product when people use it to decide where to intervene.
The useful part is not a colourful status page. It is the shared logic underneath it: definitions, data lineage and enough consistency that a programme lead can trust what “red”, “complete” or “ready” actually means.