DATA ANALYSIS & AI USE CASES

My role: Program Director. One accountable point across ten use cases and seven departments, from an open mandate through the authority’s own governance gates to systems in use.

The problem I was given

A national electricity-sector regulator with a broad mandate to build analytical capability, and no decomposition of what that meant.

The hard part was never model selection. It was deciding which use cases deserved to exist. Inside a regulator, a use case is not a technical idea. It is a claim that some department’s decision will change, that a specific data owner will release the data to change it, and that a named beneficiary will act on the result. Most candidate use cases fail at least one of those tests, and the ones that fail quietly are the expensive ones.

So the program was built around a discipline: every use case had to name its strategic objective, its operational objective, the indicators it moved, the data owner, the end beneficiary, and the decision that would be made differently because it existed. If a use case could not fill those fields, it did not enter the program.

Ten did.

How the program was structured

Ten use cases running in parallel across seven departments, deliberately spanning the full analytical ladder rather than clustering at the level that is easiest to build.

Running ten in parallel rather than in sequence meant absorbing higher coordination and dependency load, in exchange for the regulator seeing capability across its whole mandate within one program cycle rather than waiting for systems to arrive one at a time.

The ten use cases

Governor’s Office

Administrative correspondence automation. Dashboards tracking correspondence status from the top level down, replacing manual reporting with an automated view. The operational goal was eliminating hand-built reports; the strategic one was making correspondence decisions from data rather than from whoever remembered the file. Measured on completion time and the share of transactions closed within the window.

Quality, Safety and Crisis Management

Investigations tracking automation. Investigation records moved out of separate files and manual logs into a structured intake, then connected through to dashboards and reporting, so investigations could be followed as a pipeline rather than reconstructed after the fact.

Crisis Management

Crisis procedure simulation. A tool that analyses the actions and roles required when a crisis occurs, simulates the scenario, and tests whether crisis staff know the right procedure for the right situation. Built for a specific difficulty: during an incident, people cannot always identify the correct action for their role. The return is measured in reduced human, material, and reputational harm from taking the right action at the right time.

Outage prediction from report patterns. A predictive model estimating the likelihood of a power interruption in a given administrative region, learned from historical report data: timing, report type, geography, and classification. It turns crew allocation from a reaction into a forecast.

Complaints Management

Complaint closure-time prediction. A model forecasting how long each complaint will take to close from its characteristics, the handling office, and the channel it arrived through, with recommendations for improving closure time. The problem it addresses is variance: closure speed differed widely between offices and channels, with no early way to identify which complaints were heading for delay.

Consumer Satisfaction

Consumer satisfaction explanatory model. Satisfaction survey results and consumer behaviour analysed against service quality, provider type, and interaction timing, to produce recommendations that can actually be executed rather than a score that can only be reported.

Awareness gap analysis. Complaint data and satisfaction measurement linked together and read against the authority’s own official references, the guaranteed standards and the service delivery guide, to locate where dissatisfaction comes from a gap in consumer understanding rather than a failure of service.

This produced the finding that changed the shape of the response. A large share of complaints traced not to service faults but to gaps in awareness, and those gaps could be separated by type: billing, consumer rights, guaranteed standards, procedures, or the authority’s own role. What the organisation had been treating as an operations problem was substantially a communications problem, and for the first time it was targetable by segment, department, region, and period.

Electricity Planning

Load and weather pattern forecasting. Historical load data analysed against temperature to establish the relationship between them, then used to build demand forecasts driven by expected weather conditions.

Data Office

Data office indicator analysis. Analysis of the data office’s own indicators, closing the loop so that the function measuring everyone else could see itself.

Economic Affairs and Licensing

Intelligent financial document processing. Financial documents uploaded, with text and tables extracted, reviewed, and exported to structured form. It replaces manual entry of complex financial tables, which costs hours per report and introduces errors a regulator cannot afford.

How the work was built

Predictive models in Python using gradient boosting, random forests, and time-series methods including Prophet and ARIMA, chosen per use case rather than by default. Delivery through Power BI over SQL Server, with SharePoint as the intake layer where the workflow needed a form rather than a model. Document work through OCR combined with vision-language extraction for mixed Arabic and English tables.

The technology was chosen last, not first. Each use case named the decision it served before anything was selected to serve it.

What made it hard

Data quality. Several use cases opened against source data described plainly in the assessment as weak. Part of the program’s real work was establishing what could honestly be built on what existed, rather than promising outcomes the data could not support.

Seven departments, seven vocabularies. The Governor’s Office, crisis management, complaints, consumer satisfaction, planning, the data office, and economic affairs each described their problem in their own terms. Program direction here meant translating between them and holding one structure that all seven could recognise.

Governance gates. Every use case moved through the authority’s own approval process, with documented objectives, data ownership, and beneficiary sign-off. The structure was not overhead. It was the thing that stopped ten parallel workstreams from drifting.

Method

The program ran on the same decomposition method I use everywhere: the unit of scope is defined before anything is estimated, scope is set by subtracting what is out rather than adding to an empty list, and work is derived from structure rather than invented in meetings.

Ten use cases in parallel is exactly the situation where that discipline earns its keep. Without a shared structure, ten workstreams across seven departments become ten separate projects competing for the same data owners.

Status

Delivered. Feb 2024 to 2026.