Selected work
Four projects, four different kinds of hard.
Each one is written the way I'd brief a steering committee: what the situation was, what I owned,
what actually shipped. Client-confidential details are described, not disclosed.
HSBC Seguros México
Jul 2021 — Apr 2024
IFRS 17 implementation — a regulatory program across three time zones
Actuary, internal implementation team · reporting to the Manager Actuary
Situation
IFRS 17 replaced the accounting standard the insurer's entire liability model was built on.
It touched actuarial, IT and finance simultaneously, ran for years, and had a hard regulatory deadline —
with the standard's interpretation owned by group teams in London and Hong Kong, not in Mexico.
What I owned
- The data pipeline feeding the calculation engine: ETL in SAS, SQL and Python into the FIS actuarial engine.
- Assumption governance — the Basis Review cycle, and QA on model outputs before they reached reported figures.
- The Solvency II ↔ IFRS 17 comparison that let finance explain the two frameworks to each other.
- Alignment sessions in English with the London and Hong Kong teams, translating local data reality into group requirements.
Outcome
500K+ policy records reconciled and validated. Monthly close cut from 5 days to 3 (−35%) by
automating the extraction and reconciliation steps. During QA I found and corrected a double-count of claims
before it propagated into reported liabilities — the kind of defect that is cheap to fix in a model and very expensive to fix in a disclosure.
IFRS 17Solvency IISASSQLPythonFISModel governanceCross-border stakeholders
Why this matters for PM: most of the work wasn't computation — it was getting three functions and two
regional offices to accept one definition of the same number, and keeping that definition stable release after release.
Heavy-civil construction contractor · Veracruz, MX
Aug 2026 — present
Fleet telemetry & fuel accountability — turning a one-line question into a program
Data analyst / program owner · reporting to the operations director, deliverables read by the owner
Situation
Leadership asked a simple question: "how many kilometres does the fleet run?" Nobody could answer it.
Assets were split across two unrelated GPS platforms with different accounts per job site, diesel was
purchased per site with no machine-level attribution, and the physical inventory used different names than either system.
What I owned
- Scoping. I reframed the ask — the real question was what the fleet costs, not how far it moves.
- Data acquisition. Mapped both telematics vendors, built a reproducible extraction routine, and documented the retention limit (~90 days) as a standing risk.
- One asset registry. A single unique code per machine that reconciled three previously disconnected sources: GPS platform, physical inventory, and fuel logs across 16 job sites.
- Delivery. A password-protected web dashboard (Next.js on Vercel) for leadership, plus recurring executive reports and an automated daily idle-time report.
Outcome
The company's first defensible fleet baseline: 5,017 km, 43% idle time, and the finding that
3 of 5 trackers were offline — meaning measured activity was roughly half of reality, which changed how every
prior number was read. The first machine-level cross of 18,836 L of diesel against 1,071 engine-hours produced
consumption rates from 2.4 to 23.9 L/h, separating instrumentation failures from genuine loss and giving management a ranked,
verifiable list of what to fix first.
Telematics / IoT dataPythonNext.jsVercelData reconciliationExecutive reportingCost control
The scoping call I'm proudest of: I deliberately shipped release one as operations only and held the
fuel analysis back. The diesel numbers were explosive and partly explained by broken trackers — publishing them unverified would
have started an argument instead of a project. Release two landed once each figure could survive a challenge.
AxM · client engagement
2026 · fixed 6-week scope
Digital platform rebuild & LMS migration, delivered on a fixed scope
Delivery lead · client-facing owner of scope, schedule and handover
Situation
An education and consulting group running three web properties — main site, academy, and consulting arm —
needed the whole estate rebuilt and its learning platform migrated: 50 courses, e-commerce, memberships and certificates,
on a fixed price and a fixed six-week window.
What I owned
- Audit first. A full audit of all three sites before committing to a plan.
- A scope matrix mapping every requested item against the signed quote, with extras explicitly marked as delivered at no additional cost — so scope creep was visible to both sides instead of silently absorbed.
- The handover. A 19-page operating manual and a separate credentials document, so the client's team could run the platform without me.
- Production of instructor-facing assets to the client's existing brand format.
Outcome
Delivered inside the six-week window with the 50-course catalogue, storefront, memberships and certificates live.
The deliverable I consider the real one is the SOP: the client operates the platform independently,
which is the only honest test of whether a delivery project finished.
Scope managementLMS migrationWordPress / WooCommerceSOP & handoverFixed-price delivery
AxM · client engagement
2026 — ongoing
Weekly growth reporting — and the KPI that was wrong by 9×
Analytics & reporting lead · weekly readout to the client's leadership
Situation
The client was spending on paid acquisition but couldn't see where the funnel leaked. I built a repeatable weekly
pipeline pulling ad performance from the Meta API and conversation data from the CRM,
reported in one document with week-over-week movement.
The finding
- The obvious metric — the CRM's "unread" count — said 1,112 unanswered leads. It was wrong by roughly 9×: it counted threads dead for 90+ days and messages that were already-handled acknowledgements.
- I rebuilt the measure: filter by channel and recency, then read the closing message of each thread and classify it as genuinely open, already handled, or noise.
- The real number was ~10 open leads. The actual bottleneck was ownership — 74% of conversations were unassigned and load was concentrated on a single closer.
Outcome
The recommendation changed completely: not "hire more closers to clear a backlog" — the backlog didn't exist — but
round-robin auto-assignment to fix ownership. A project scoped off the original KPI would have spent
real money solving a problem that wasn't there.
Meta Marketing APICRM dataPythonKPI designSales opsStakeholder reporting
Why this matters for PM: the most expensive project failures start before kickoff, in a metric nobody
interrogated. Validating the baseline is part of scoping, not part of analysis.