Lifecycle Assessment Tracker — Turning fragmented campus maintenance into a trusted financial decision system
Product
An ML-driven platform helping a Pacific Northwest university manage 60–80+ buildings across three campuses. LAT shipped as a modular API layer alongside their legacy CMMS/ERP, turning fragmented data into financial intelligence without a system replacement.
My role. I owned product vision, workflows, and the design system, aligning field technicians, managers, accountants, and executives — translating institutional needs into requirements and pushing for field research when stakeholders wanted to skip it.
Timeline was 8 months
Discovery to data consolidation to ML framework to pilot to beta to release. The platform continued beyond my tenure.
Team
1 PM, 1 designer (me), 2 external engineers, plus client-side CAPEX, data science, accounting, and property management teams
Pilot adoption
95% of property managers (vs. 70% benchmark)
Usage tracking during pilot — most rigorously measured
Data accuracy
70% → 95%
Audit of asset records pre/post canonical ID + sync validation
Reporting time per ticket
~20 min → ~8 min
Observed field timing, pre/post offline-first workflow
Budget revisions
↓ 36%
Planning-cycle comparison vs. prior year
Emergency repair incidents
↓ 12%
Work-order classification during pilot period
Unexpected maintenance costs
↓ 25% projected
Lifecycle model forecast validated against pilot repair data
Adoption, data accuracy, and reporting time are the numbers I'm most confident in because they were directly observed. The cost figures came from the platform's own forecasting layer, so I hold them more loosely and say so when asked.
Universities manage billions in infrastructure with fragmented tools: a technician underground can't access repair history, a project manager stitches together spreadsheets and invoices before planning meetings, leadership decides on partial data.
Without a unified system, everyone operates in their own flow with no common path:
"I do the physical work in 30 minutes, but reporting takes another 20."
"Each year I'm choosing between urgent-now and smart-long-term with partial data."
CMMS platforms handle tickets and leases but don't model asset lifespan or CapEx tradeoffs. Preventive maintenance ran on time, not risk, causing over-maintenance and surprise failures. Field tools assumed stable connectivity, so slow digital reporting killed adoption. And replacing the legacy stack wasn't viable — it was wired into procurement and budgeting. They didn't need another silo; they needed a layer that worked with what existed.

We thought we were customizing a product. Research showed we were redesigning a system of coordination.
The breakthrough wasn't the AI — it was recognizing that fragmented data was forcing humans to do system work. Everyone had access to data; what they lacked was context, prioritization, and trust.
That reframed everything. Instead of one dashboard for everyone, we built role-based surfaces over a shared foundation, surfacing only what was actionable.

Every feature mapped to one of three drivers: cost reduction, planning accuracy, or adoption velocity. If it didn't serve one, it didn't ship.
Automatically link Work Orders ↔ Asset DNA ↔ Cost-to-Date. The conversation shifted from "we'll fix it again" to "this unit cost $42K in three years; replacing now saves $18K."
Multiple graphs looked impressive; managers scanned without acting. We replaced it with a ranked priority queue — action first, analysis second.
Turn predictive signals into ranked alerts. Early alerts said "Boiler failure risk: 68%" — managers hesitated. We shifted to consequence framing: "High vibration + 9 years in service → delaying replacement may cost $18K." Humans act on consequences, not probabilities.
Month 2: the engine flagged a $180K boiler replacement as Critical. Inspection showed duplicated repair entries had inflated the risk. Three guardrails contained it — manager review gate, visible drivers, no auto-procurement. We added a "Needs Verification" state and multi-signal validation. Adoption held at 95%.
In-house scenario comparison with side-by-side cost/timeline deltas. Before LAT, feasibility questions meant commissioning external studies; after, teams ran three scenarios instantly and exported board-ready outputs. Decision velocity over spectacle.
Operational. Linking work orders to lifecycle cost made repair history visible in real time — managers began reviewing repair frequency before approving repeat fixes. Reporting per ticket: 20min → 8min. Emergency incidents: ↓12%. Projected cost reduction: 25%.
Decision-making. Teams stopped entering meetings to reconcile facts and started entering them to decide. Budget revisions: ↓36%. Planning time: ↓60%. Pilot adoption: 95% (vs. 70% benchmark).
Strategic. Scenario simulation moved feasibility analysis in-house (↓4% consultant spend) and drew expansion interest from other universities — a path from consulting project to scalable platform.
What I got wrong. I thought predictive accuracy would drive adoption — it didn't. Data integrity and clarity mattered more; strong predictions failed when the underlying data was messy or hard to act on. Next time: audit data before any predictive expansion, and lead with consequence framing from day one.
What mattered more than expected. The lifecycle linkage, not the AI. Once work orders, asset history, and cost-over-time were reliably connected, decisions improved before the predictive layer even matured — users didn't want more data, they wanted less to think about.
What I learned about AI in enterprise. Adoption depends less on model sophistication than on trust architecture — visible reasoning, human control, confidence-aware outputs, failure containment built in from the start. One wrong high-visibility alert can undo months of adoption. Design for the failure, not the demo.