MelvinGibson.

The platform was live and generating reliable data — but a large portion of the organization had no licenses, including finance and senior executives. They were still manually reconciling portfolio data from multiple sources, a process that took up to 2 days and carried consistent risk of error. Funding decisions were being made on information that was already outdated the moment it was compiled.

When leadership asked for better reporting access, I proposed something bigger: rebuilding the full enterprise data model in Microsoft Fabric rather than layering exports on top of flat files. The goal was a governed, always-current source of truth that anyone in the organization could access — no platform license required.

I architected the Lakehouse starting with a full API load to establish the baseline, followed by automated delta pulls that only retrieve updated fields on each run — preventing large repeated requests from impacting the source system. Once curated, the data became accessible org-wide. I then built 10+ Power BI dashboards connecting directly to the Lakehouse, with no manual refresh required.

The R&D portfolio used a single burden rate for everything: pricing projects during planning, and pricing those same projects again once hours were actually logged against them. That worked for planning, where an assumed rate is the only option before the work happens. But for actuals, it meant reported project cost was still just hours × an assumed rate — not a number tied to what the cost center actually spent. Every period, the actual cost rolling up from projects didn't reconcile to the cost center's real P&L spend, and there was no way to close that gap without constantly updating the rate itself, which broke every time there was a raise, RIF, or backfill.

Leadership needed project actuals that would reconcile to Finance's own P&L every period, not just approximate it. I already had what that required sitting in the data: what each cost center actually spent per period, and how many hours were submitted against projects from that cost center. The question was whether dividing those two real numbers — instead of applying the burden rate — would produce an actual cost that ties out by construction, every time.

I built an actual-cost allocation model that replaces the burden rate on the actuals side only: each period, divide the cost center's real P&L spend by the real project hours submitted against it, then allocate that number across every project in proportion to the hours it pulled from that cost center. Because both inputs come directly from the P&L and the submitted hours, the result reconciles to the cost center's real spend by definition — there's no assumption left to drift. I ran the calculation on a monthly cycle so a mid-year raise or RIF shows up immediately instead of smoothing across the year, and defined the hours denominator as project hours only — so the cost of PTO, training and admin time is absorbed into the rate charged to project work, which is what lets project cost alone tie to the P&L with no reconciling items. The burden rate still prices planning, where no actual spend exists yet to divide — but actuals now run entirely on this method.