I led the end-to-end modernization of a fragmented marketing-analytics and MarTech estate — standing up the program charter, governance, and agile delivery, then steering it through architecture, UAT, cutover, and benefits realization. This is the case study where the program-management operating system is the story.
Representative composite. Company name (“Nexora”) is fictional and all figures are illustrative — this page shows how I run a program of this shape, not confidential client data.
Marketing ran on a patchwork of disconnected tools and hand-built spreadsheets. Campaign, web, and CRM data never reconciled, reporting was late and contested, and no one owned a single source of truth. The gap wasn't a missing dashboard — it was the absence of a program to fix it properly.
I framed it as a governed program: a charter and steering model, a phased roadmap delivered in agile sprints on Jira, a modernized data-and-MarTech architecture, RAID-driven risk control, staged UAT, a controlled cutover with hypercare, and a benefits-realization plan that outlived go-live.
Program at a glance
| My role | Technical Program Manager — end-to-end owner, charter to benefits |
| Program shape | 13 lifecycle workstreams: initiation, governance, requirements, planning, architecture, agile delivery, data engineering, MarTech, BI, testing/UAT, risk & change, cutover, closure & benefits |
| Delivery model | Agile / Scrum, sprint cadence tracked in Jira, stage-gated at each phase |
| Domain | Marketing analytics + MarTech + BI modernization |
| Governance | Executive steering committee → program lead → workstream leads, weekly RAID |
| Outcome frame | Trusted single source of truth for marketing performance, adopted and owned by the business |
I've deliberately left hard KPIs off this table. On a modernization like this, the credible number is the one the business can defend six months later — so those get filled in from measured benefits, not launch-day estimates. What follows is the operating system I used to get there.
Governance & stakeholders
Modernizations don't fail on technology — they fail on unclear ownership and decisions that never get made. So the first artifact wasn't an architecture diagram; it was the governance model: who decides, who's consulted, and at what cadence.
Without a named decision forum, a program defaults to whoever escalates loudest. A steering committee with a standing agenda is what let me protect executive time, keep workstreams unblocked, and make trade-off calls in days instead of weeks.
| Tier | Who | Owns | Cadence |
|---|---|---|---|
| Steering committee | Exec sponsor + function heads | Scope, budget, go/no-go, cross-function trade-offs | Bi-weekly, escalation on demand |
| Program lead (me) | TPM | Roadmap, dependencies, RAID, delivery cadence, reporting | Daily standups + weekly RAID |
| Workstream leads | Data, MarTech, BI, QA, business readiness | Sprint delivery inside their workstream | Sprint (2-week) + joint planning |
| Business owners | Marketing ops & regional leads | Requirements sign-off, UAT, adoption | Sprint reviews + mandatory UAT gates |
The pattern: match the forum to the decision. Reversible calls stayed with workstream leads; anything touching scope, budget, or sequence went to steering with a one-page recommendation, not an open question.
Roadmap & agile delivery
The roadmap gave stakeholders the shape of the journey; the sprint plan made it real. Phases were stage-gated — nothing moved forward until the previous gate's exit criteria were signed off.
Every workstream fed one Jira backlog under program epics mapped to the roadmap phases. Two-week sprints, a shared definition of done that included documentation and test evidence, and a dependency board I reviewed daily so a blocker in data engineering never silently stalled BI.
Architecture
The target state wasn't just "a warehouse." It was a clean line from raw marketing sources, through a modeled single source of truth, out to both BI reporting and MarTech activation — so the same trusted numbers drove the dashboard and the campaign.
My job here was less about writing the transforms and more about the decisions around them: what became the source of truth, how conformed dimensions were governed, and where the boundary sat between the engineering team's build and the business's definitions. I owned the sequencing and the sign-offs; the engineering workstream owned the pipelines and models.
Risk, change & quality
Two disciplines ran the whole way through: a live RAID log scored by probability × impact and reviewed weekly, and a staged UAT that treated business sign-off as a gate, not a formality.
| Severity | Trigger | My response |
|---|---|---|
| High | Threatens scope, date, or data trust | Named owner, weekly steering visibility, mitigation tracked to close |
| Medium | Recoverable if caught early | Reviewed weekly in RAID, contingency identified |
| Low | Contained; monitoring sufficient | Logged, bi-weekly spot check |
Change control
Scope changes went through a lightweight change log with an impact assessment — so "just one more field" was a visible trade-off against the date, not a silent scope creep.
Staged UAT
Business owners tested against real scenarios and signed off per workstream. Reconciliation against the legacy numbers had to pass before anything was called done.
Incident readiness
A defined severity scale and response path meant that when something broke in build or hypercare, the question was "who and by when," not "what do we do now."
Cutover & benefits
Go-live is the risky moment and the anticlimactic one: if the program was run well, cutover is boring. Then the real test begins — does the business actually adopt and trust the new source of truth?
The program didn't close at go-live. I set up benefits tracking against the original charter goals — adoption of the new reporting, retirement of the shadow spreadsheets, and cycle-time on marketing reporting — so value was measured, not assumed. These are the figures that belong on the scoreboard, once they're real.
The throughline: this was a program-management case, not a tooling one. The tools mattered, but what made it work was the operating system around them — governance, cadence, risk discipline, and a benefits mindset that treated go-live as the middle, not the end.
← Back to portfolio