Back to Case Studies

From Spreadsheets to Workforce Planning Intelligence

Enterprise — Workforce Planning and Delivery Operations | Confidential enterprise client

Challenge

Workforce plans and Jira actuals lived in separate exports, making consistent comparisons dependent on repeated data preparation and employee matching.

Approach

Built an Azure-based processing and reporting foundation that brings planning files and Jira exports into a shared SQL model for Power BI.

Outcome

Implemented repeatable imports, duplicate and period checks, and structured planned-versus-actual reporting data.

Engagement snapshot

Engineering across the upload experience, Azure Function processing, SQL reporting model, Power BI reporting, infrastructure definitions, deployment workflows, and handover documentation.

Import controls
Content-based duplicate detection and reporting-period checks

The Jira import service checks file hashes and rejects mismatches between the selected reporting period and imported work dates.

Reporting foundation
Separate planned and actual facts with shared identity and calendar mappings

SQL artifacts prepare workforce and worklog data for consistent analysis across employees, weeks, and sprints.

Processing traceability
Tracked import batches and superseded snapshots

Import processing records batch state and marks older batches as superseded for the same period. These are implementation results, not measured time savings.

Challenge

Workforce planning and delivery reporting depended on two different views of the same work: planned capacity in spreadsheets and actual effort in Jira exports.

Bringing those views together required more than combining files. Employee identities needed to match across sources. Work dates had to align with the selected reporting period. Calendar weeks and delivery sprints needed a consistent relationship. Repeated uploads and replacement exports also had to be distinguished from new information.

Without a shared processing model, each reporting cycle carried the same preparation burden before managers could compare allocation, capacity, and recorded effort.

Approach

The solution separates file submission, business processing, data storage, and reporting. A Vue upload experience provides the entry point. Azure Functions process the files and apply server-side checks. Azure SQL holds the import history, mapping data, and reporting model. Power BI consumes the prepared data.

Three engineering decisions shape the solution:

Make imports repeatable. Content hashes identify files that have already been processed. Reporting-period checks catch mismatches between the period selected by the user and dates in the Jira export. Batch tracking records processing state, while superseding older snapshots distinguishes replacement data from a new reporting period.

Resolve differences between the sources explicitly. Employee identity mappings connect planning records with Jira users, including cases where a username is missing. Shared calendar and sprint mappings give planned and actual facts a consistent basis for comparison.

Keep source records separate from reporting data. Raw imports, reference mappings, curated facts, and reporting views have distinct responsibilities. This preserves the source context while preparing a model that reports can reuse.

Infrastructure definitions, deployment workflows, and operating documentation accompany the application so that environment setup and support are part of the delivery.

Solution Architecture

Planning spreadsheets       Jira exports
          \                    /
           Vue upload experience
                    |
              Azure Functions
       Parsing, duplicate and period checks
                    |
                Azure SQL
       Import history and source records
       Employee and calendar mappings
       Planned and actual reporting facts
                    |
                 Power BI
       Capacity and effort comparison

Bicep defines Azure infrastructure, and Azure DevOps supports infrastructure and Function delivery. Managed Identity provides the Function-to-SQL authentication path.

The reporting model separates the question a manager wants to answer from the structure of the original export. Reports can consume prepared facts and mappings instead of repeating file-specific transformations.

Outcome

The implemented foundation brings workforce plans and Jira actuals into a common reporting model with explicit import controls and processing history.

  • Repeatable intake: content-based duplicate detection and period checks address specific errors before data is used downstream.
  • Consistent reporting inputs: employee, week, and sprint mappings support planned-versus-actual comparisons.
  • Traceable processing: batch states and superseded snapshots distinguish processing attempts and replacement imports.
  • A maintainable delivery foundation: application code, database objects, infrastructure definitions, and handover documentation capture how the solution works.

These results describe implemented capabilities. Full worklog reconciliation and end-to-end deployment validation remain areas for completion; reductions in reporting effort and improvements in utilization have not yet been quantified.

The pattern is applicable wherever recurring operational reports combine spreadsheet plans with exports from a delivery system: establish reliable inputs, resolve shared identities and periods, and build reporting on the prepared model.

Technologies

  • Vue for file submission and user interaction
  • C# / .NET and Azure Functions for processing
  • Azure SQL for import history, mappings, and reporting facts
  • Power BI for analysis and reporting
  • Bicep and Azure DevOps for infrastructure and Function delivery
  • Managed Identity for service-to-database authentication

From proof to your next decision

See the capability demonstrated in this engagement and the thinking behind the approach.

Discuss a similar challenge with the team behind our data & integrations work.

Start a conversation