The problem
Performance reporting across the organisation was manual and fragmented. Every month, teams emailed spreadsheets around the organisation for people to type figures into, then re-collated the results by hand. Several parallel frameworks each had their own format and cadence:
- Corporate Performance Framework — 37 indicators reported monthly to senior leadership assurance.
- Departmental frameworks — different indicators and formats, reported monthly or quarterly.
- Strategy-based reporting — outcomes tracked against strategies (e.g. climate, housing).
- Corporate Plan — indicators mapped to plan outcomes, reported annually.
This created duplicated effort, inconsistent standards, and no single source of truth. Whenever a team wanted a new performance framework (for example, for a climate-change strategy), the BI team had to build something bespoke — which didn't scale.
The solution
A single Power App that lets staff create and manage KPIs, assemble them into reusable frameworks, and then automates the monthly collection of figures and commentary — with governance built in so the data stays trustworthy. Analysis and trends live in Power BI dashboards rather than the app, keeping the app focused on capture and automation.
What was built
- KPI / indicator authoring — a guided form capturing rich metadata: definition, category, reporting frequency, targets and target rationale, benchmarking availability, data-due dates, and named data/commentary leads (with delegates).
- Approval workflows — new KPIs and new frameworks are signed off by the BI management team to prevent duplication and enforce quality before they go live.
- Reusable indicator bank + framework builder — users assemble frameworks (corporate, departmental, policy, strategy) by selecting from existing indicators, so KPIs are defined once and reused across many frameworks. Frameworks act as filters and row-level-security boundaries in reporting.
- Automated data collection — scheduled Power Automate flows detect which indicators are due and request figures from data leads, with email reminders when submissions are late (e.g. chasing after 5 days).
- Automated commentary capture — for red/amber (RAG) indicators, the system requests commentary and supports a threaded, dialogue-style Q&A on each indicator, notifying leads when questions are posted.
- Target-change approvals — targets can only be changed through an approval process, protecting the integrity of reporting baselines.
- Performance Improvement Plans (PIPs) — for underperforming indicators, standardised improvement plans capture the issue, contributing factors, and SMART actions (owner, deadline, status, updates) tracked through to sign-off.
- Benchmarking fields — optional London/England ranks, quartiles and averages surfaced where benchmarking data exists.
- Power BI reporting layer — dashboards with RAG status (configurable ~5% tolerance), trend graphs, framework filtering, row-level security, and export to PowerPoint for board packs.
Key technical decisions
Dataverse vs SharePoint (data architecture)
Led the analysis of whether the app needed Microsoft Dataverse or could run on SharePoint lists. Framed the decision around concrete engineering criteria rather than defaults: the requirement for row-level security (departments seeing only their own data), calculated/formula columns, integrity of lookup relationships, and delegation limits on large volumes of submission records that grow every reporting period.
Weighed these against licensing and Dataverse capacity costs, and drove the recommendation to Dataverse once row-level security was confirmed as a hard requirement — while keeping the door open to SharePoint for lower-security scenarios.
Cost-efficient data submission via Teams Adaptive Cards
Rather than requiring ~100 occasional contributors to each hold premium licences, designed the data-entry path around Teams adaptive cards driven by service-account flows. Contributors submit their monthly figures directly in Teams — cards can be stacked so one person with many indicators gets a single message, not one per indicator — with the flow writing back to Dataverse. This kept the solution affordable at scale while still centralising data in a secure store.
Governance-driven delivery
Ran the project through the organisation's formal Power Platform governance process — long-list → as-is scoping → to-be & technical scoping → initial development → continuous development with stakeholders → live — producing the To-Be and Technical Scoping documents and requesting the Dataverse environments early, since provisioning has long lead times.
Requirements elicitation
Gathered and shaped requirements across three groups: the project sponsor/stakeholder, a senior developer (for architecture and licensing guidance), and a tester/BI group to pressure-test the workflow, notification load, and edge cases such as "single version of the truth" concerns and daily-digest vs per-indicator notifications.
Scope & scale
- Consolidates the 37-indicator monthly corporate framework plus departmental and strategy frameworks.
- Targeted at ~100 users across BI and departmental data owners.
- Designed to scale toward 450–500 indicators organisation-wide as adoption grows.
- Delivered in phases, starting with the corporate and departmental management frameworks.
Impact
- Replaces manual spreadsheet collection with an automated, auditable workflow.
- Removes the need to build bespoke apps for each new strategy or framework — teams self-serve by assembling frameworks from a shared indicator bank.
- Establishes a single source of truth with enforced standards, approvals, and consistent RAG/benchmarking treatment.
- Keeps licensing costs low by routing occasional contributors through Teams rather than the app.
Skills demonstrated
- Low-code architecture
- Dataverse data modelling
- Workflow & approval design
- Power BI with row-level security
- Cost / licensing analysis
- Requirements elicitation
- Stakeholder management
- Data governance
- Enterprise IT governance