Internship · BI & reporting · Worldtech Electronic Co., Ltd. · Remote · 2026
Tracking a contract portfolio: what’s active, what’s expiring, and what it’s worth
My 13-week internship project was the reporting layer of a contract-intelligence system: a two-page Power BI report on Microsoft Fabric. One page is a log for looking up contracts; the other is the portfolio view, with contracted revenue, room nights, top markets and an expiry pipeline. I also worked on the DAX measures and expiry logic the data model was missing.
01 Overview
The brief
Worldtech’s contract-intelligence project moves contract files through Azure storage into tables in Microsoft Fabric. My part was the reporting layer on top: a Power BI report that shows the state of the contract portfolio at a glance, flags contracts that are about to expire, and summarises where the contracted value sits.
02 Problem & users
Contract data isn’t ready for reporting
The report had to support contract monitoring: seeing how many contracts are active, spotting upcoming expiries early, and giving a clear view of the portfolio by market. The data made that harder than it sounds.
- Inconsistent records. Fields, formatting and completeness varied from contract to contract, so the data needed interpreting before it could be shown.
- No ready-made measures. The Fabric model had the tables but not the calculations a dashboard needs.
- Missing columns. Some visuals I planned needed fields that weren’t in the model yet.
- A design guide to follow. The report had to match house style for headers, naming, fonts, spacing and filters.
03 My role
What I was responsible for
- Both report pages: the Contract Log and the Contract Analytics page, from first draft to final layout.
- Measures and logic: DAX calculations for the report, including the expiry logic behind the expiring-contract figures and the expiry pipeline.
- Model and platform review: how the contract details and contract rates tables relate, and how files move through the Azure storage containers.
- Reporting progress: regular meetings with my supervisor to show work, raise blockers and agree changes, plus a diary and evidence log of the build.
04 Approach
Decisions that shaped the report
- 01Azure StorageContract files in raw, processed and archive containers
- 02Fabric data modelContract details table related to contract rates table
- 03DAX measuresTotals, active and expiring contracts, average duration, expiry logic
- 04Power BI reportContract Log and Contract Analytics pages
Understand the model before designing visuals
I started from the relationship between the contract details table and the contract rates table, and from the Azure storage flow (raw, processed and archive containers). Knowing which fields existed, and how they joined, told me which outputs were possible before I spent time on layout.
Write the measures the model didn’t have
The model had no ready-made measures, so the KPI figures needed DAX calculations, and some needed columns that weren’t there yet. The expiry logic took the most care, because expiring-contract figures and the expiry pipeline are only useful if they are exactly right.
Separate looking up from understanding
The Contract Log is for day-to-day lookup: KPI cards, filters and the full contract table. The Contract Analytics page is for the portfolio view: top markets, recent contracts, the expiry pipeline, contracted revenue, room nights and average net rate.
Diagnose before fixing
Problems were often connected: one wrong figure could involve the data, the model and the layout at once. So when something looked off, I checked in order whether the cause was missing source data, a model limitation, the measure logic or the layout, which kept me on root causes rather than surface fixes.
05 The redesign
From a working draft to a report people can use
In weeks 4–5, my first version worked technically but wasn’t accepted: the layout, spacing, naming and overall presentation weren’t at the level expected. I studied Power BI design, explored Fabric and Power BI features, and rebuilt the report step by step using my supervisor’s feedback.
| Area | First draft | Final version |
|---|---|---|
| Structure | One page: KPI cards, a contract table and basic filters | Two pages: a Contract Log for lookup and a Contract Analytics page for the portfolio view |
| Header | Not yet to the design guide | Corrected and named to the design guide |
| KPIs | Cards with inconsistent fonts and spacing | A reworked KPI layout with consistent fonts and spacing |
| Filters | Basic filtering options | A reorganised filter section |
| Table | Raw field names | Cleaned field names and a restructured table |
In weeks 9–10 a second crunch hit: more advanced features needed DAX measures that didn’t exist yet and columns that were missing, under deadline pressure. Supervisor feedback helped me decide what to fix first; I worked through the measure logic, tested different approaches and adjusted the visuals. The final report was well received.
06 Results
What I delivered
- KPI cards: contract counts by status and average duration on the log; portfolio size, contracted revenue, room nights and average net rate on the analytics page
- 9
- analysis views: top markets, recent contracts and the expiry pipeline
- 3
- A contract log with filters and the full contract table, for looking up any contract quickly.
- Expiry logic that surfaces contracts nearing their end date, so upcoming expiries are visible early.
07 Limitations & learning
What I’d do differently
- Check measures and columns in week one. Both crunches came from finding gaps late. A list of every KPI, the measure it needs and the columns behind it would have surfaced them much earlier.
- Agree the design before building it. Reviewing the design expectations, gathering examples and testing a few layouts before presenting would have avoided much of the redesign.
- Working isn’t the same as ready. A report can be technically correct and still not be usable. Layout, naming and hierarchy are part of the job, not polish.