AI Workforce Optimization Platform

Overview

By 2021, skilled labor had become one of the scarcest resources in infrastructure. The U.S. construction industry needed to attract an estimated 430,000 workers in 2021 on top of the workers it normally hires each year, and the gap was projected to grow to nearly 650,000 in 2022. Hyperscale data center projects compete for the same limited pool of electricians and mechanical trades. When a project can't secure the right crews at the right time, schedules slip, labor costs climb, and new compute capacity comes online late. For a hyperscaler, every week a data center is delayed costs roughly $1 million.

Infrastructure delivery teams at Meta were planning labor with fragmented data and manual estimates. Forecasts were often wrong, which left projects short of the crews they needed and running late. The AI Workforce Optimization Platform centralized that data and used machine learning to forecast labor demand across infrastructure projects, accounting for labor shortages and changing project variables, so teams could secure and allocate workers before the gap became a delay.

AI Hypothesis

The bet the product was built to test:

If machine learning accurately forecasts labor demand across all active projects early enough to see the peaks coming, then delivery teams can secure skilled trades ahead of time and spread crews across projects instead of competing for them at the same moment, which lowers peak labor, cuts labor costs, and keeps data centers on schedule.

Customer Research

Before building a model, I wanted to understand how labor was actually planned on a data center project, and where the plan broke down. I interviewed the people who build the schedule, staff the site, track the cost, and supply the crews.

Each conversation walked through a recent project from start to finish: how labor needs were estimated, where the data came from, when crews were requested, and what happened when the estimate was wrong.

Interviews

15

Timeframe

3 weeks

What kept coming up

• No single view of labor. Schedules, cost reports, and crew counts lived in separate spreadsheets and systems, and nobody could see labor demand across every project at once.
• Forecasts built on gut feel. Labor plans were estimated by hand from past experience, so two construction managers could forecast the same project very differently.
• Projects competing for the same crews. Each project planned on its own, so several hit their labor peak at the same time and bid against each other for the same electricians.
• Paying to keep talent from rival hyperscalers. Other hyperscalers were building near our projects and drawing from the same local labor pool, so we relied on Labor Attractive Retention Plans (LARPs), incentive pay to attract and keep skilled trades. Without an early view of demand, those costs kept climbing.
• Trade partners found out too late. Crew requests arrived weeks before they were needed, when skilled workers were already committed to other jobs.
• Plans fell behind the schedule. When the schedule slipped or the scope changed, the labor plan wasn't updated, and superintendents found the gap on site.

Schedulers

Build and maintain the project schedule

Construction managers

Own delivery across one or more projects

Superintendents

Run the site and staff the crews day to day

Cost analysts

Track labor spend against budget

Skilled labor trade partners

Supply the electricians and mechanical crews

Persona & Customer Journey

The interviews covered five roles, each touching labor planning from a different side:

• Superintendents, who run the site day to day, request the crews, and are the construction manager's eyes in the field.
• Construction managers, who own delivery and sign off on the labor plan.
• Schedulers, who build the schedule the labor plan depends on.
• Cost analysts, who track labor spend, including retention incentives, against budget.
• Skilled labor trade partners, who supply the crews and need notice to commit them.

We built the MVP for the superintendent. They're the ones who actually request crews, and they see a shortage first, on site, when it's already too late to fix cheaply. If the forecast gives them enough lead time to request crews before the peak, the construction manager sees a project that stays on schedule, the cost analyst sees lower labor spend, and trade partners get the notice they need. That makes the superintendent the fastest path to proving the hypothesis.

Primary persona · composite of superintendent interviews

Ray, the site superintendent

Role

Site superintendent

Project

Hyperscale data center

Reports to

Construction manager

Background

Came up through the trades

A day in his life

Ray is on site before the crews arrive. He walks the work, checks progress against the schedule, solves whatever broke overnight, and reports back to the construction manager. Somewhere in there he has to figure out how many electricians and mechanical workers he'll need next month, using a spreadsheet, the latest schedule, and his own experience.

Goals

• Have the right crews on site when the work is ready for them
• Request labor early enough that trade partners can commit
• Keep the project on schedule without paying premiums to fill gaps
• Give the construction manager a labor plan he can stand behind

Frustrations

• Labor estimates built by hand from scattered data
• Finding out about a shortage on site, when it's already a delay
• Losing crews to other hyperscalers building nearby
• Schedule changes that leave the labor plan out of date

Customer journey

How Ray plans labor across a project, and what the tool changes at each step.

AI Models Overview

One supervised machine learning model did the work. We trained it on past data center projects where the outcome was already known, so it could learn how a project's plans and estimates translated into the labor it actually took.

AI Input & AI Output

Data Pipeline

I led the development of the data pipeline, working with data engineers to clean the data and build the pipelines. Data moves through four stages, from project files scattered across teams to a forecast on a superintendent's dashboard.

1. Collect

   • Quantities are extracted from each project's 3D models, drawings, and blueprints.
   • Each project's live schedule is pulled directly from Primavera P6.
   • Original labor and cost estimates are gathered by trade.
   • Available labor is gathered by trade and location.
   • Actual labor hours, cost, and schedules from completed projects form the training and validation set, split 80/20.

2. Prepare

   • Data from different teams and formats is cleaned and combined into one consistent record per project.
   • Trades, systems, and units are standardized so projects can be compared with each other.
   • P6 activities are mapped to trades and weeks, so the schedule lines up with the quantities.
   • The gap between each past project's estimate and its actuals is calculated as a feature.

3. Forecast

   • The gradient boosted model forecasts labor hours by trade, per week, for each active project, with a likely range.
   • Forecasts are rolled up across every active project to show where peaks overlap.
   • The inputs that drove each forecast are recorded alongside it.
   • When the schedule in P6 changes, the forecast updates to match.
   • Each forecast is compared with available labor to find gaps, which trigger shortage and overstaffing alerts.

4. Deliver & learn

   • Forecasts appear on a dashboard, filtered by project, trade, location, and time horizon, alongside the labor gap, alerts, and LARP scenarios.
   • Superintendents use it to see upcoming peaks and request crews with lead time; construction managers use it to plan across projects and to model LARP options before committing to them.
   • As projects finish, their actual labor is added to the training data, so the model keeps learning from every new build.

System Architecture

How data moves from project files and schedules to a crew decision: sources on the left, the pipeline and model in the middle, the dashboard on the right, and a retraining loop that keeps the model learning from every finished project.

• Data and forecast path
• Live schedule from P6
• Retraining loop

Product Opportunities & Prioritization

Once discovery was done, the question was how much the tool should take on. A labor forecasting tool was the core, but research surfaced three adjacent problems the same teams wanted solved, and each one competed for the same build time.

Why labor forecasting came first

The costliest problem was not knowing how many workers a project would need, and when. That's what drove projects into retention incentives to compete with nearby hyperscalers, and into delays that cost roughly $1 million a week. Takeoffs, cost estimation, and QA/QC tracking each had tools and teams already handling them, imperfectly but well enough. Accurate manpower forecasting had nothing. A forecast is also only useful if teams trust it, so accuracy was part of the MVP from day one: the proof of concept had to beat the hand built estimates before anything shipped. The adjacent options were weighed and set aside; a tool that tried to do all four at once risked doing none of them well.

Impact vs. effort

The core forecast and the three adjacent options, scored on their impact on getting the right crews in place and on the effort to build them well.

Cost estimation, QA/QC tracking, and automated takeoffs were scored but never built; the team stayed focused on the forecast.

Product Roadmap

I owned product discovery, strategy, and the roadmap, working with the infrastructure delivery teams who would use the tool. The roadmap followed the prioritization: build an accurate, fully automated labor forecast first, then prove it in the field by piloting it on live jobsites against the schedulers' plans and the actual labor, and let the model learn from every finished project before rolling it out. Cost estimation and QA/QC tracking stayed on the list but were never built.

User Stories & Acceptance Criteria

The stories center on the superintendent, the primary persona, with the construction manager, scheduler, and cost analyst where the forecast shaped their planning: securing crews, preparing retention incentives and recruitment, and projecting actual labor spend. Each one ties back to a pain point from the interviews, and each acceptance criterion is something the team could test before calling the feature done.

Risks & Mitigation

A forecasting tool has two ways to fail: it gives the wrong number, or it gives the right number and nobody acts on it. Each risk below was rated on how much damage it would do and how likely it was, and each mitigation was built into the phase that introduced the risk.

Business Model / Lean Canvas

This was an internal tool, so it had no price or sales channel. The canvas below adapts the format: channels become how the tool reached its users, and revenue becomes the value it returned to Meta.

AI Product Scalability

Meta's data center build program kept growing, and every new project added more labor demand to plan for. The tool was designed so that each new project made it more accurate and more useful, instead of adding more manual work.

MVP

I developed the MVP of the AI based labor forecasting model and the dashboard teams used to act on it. The MVP did one job: give superintendents and construction managers an accurate, week by week forecast of the crews each trade would need, across every active project, early enough to plan around the peak.

• Labor forecast by trade, per week, for each project, with a likely range
• Portfolio view that stacks every active project, so overlapping peaks are visible weeks ahead
• Live schedule pulled automatically from Primavera P6 through the automated pipeline
• Labor gap between the forecast and available workers, by trade and location
• Alerts and insights for labor shortages, overstaffing, and cost overruns
• LARP scenario planning to estimate and compare the cost of retention bonuses, referral bonuses, and overtime
• Power BI dashboard built for the superintendent first, then the construction manager

Results

I developed the MVP of the AI based labor forecasting model. We piloted it on multiple jobsites, checking its forecasts against the schedulers' plans and against the actual labor used over each project's lifecycle. Workforce planning time dropped dramatically, and the tool made decisions faster and more reliable:

Better allocation also cut workforce inefficiencies by 25%, which reduced labor related costs by 12%.