CDP transformation · Amgen · Current

Connecting programs through a unified CDP.

I lead delivery across Amgen's CDP transformation—a build, operate and transfer engagement that has to stand a customer data platform up, run it in the open, and hand it to the enterprise without dropping momentum at either seam.

BOTEngagement model
FiveParallel workstreams
E2EReadiness view
Build, operate and transfer Four phases across the engagement, with five workstreams running in parallel and ownership shifting from provider to enterprise. ALIGN BUILD OPERATE TRANSFER PROVIDER-LED ENTERPRISE-OWNED

A transformation is a network.

Build, operate and transfer means doing three jobs at once—and the hard part is that they pull in opposite directions.

Building rewards momentum. Operating rewards stability. Transferring rewards documentation and restraint. A platform being stood up, run, and handed over simultaneously will optimise for whichever of those three has the loudest advocate in the room, unless someone holds the tension deliberately.

Underneath that sat a subtler problem. A customer data platform is not a project that finishes; it is a product the enterprise has to understand well enough to ask sensible things of. Where that understanding lags, expectations outrun capability—teams request activation the platform cannot yet support, and the resulting gap gets read as delivery failure rather than sequencing.

So the mandate was never only to track dependencies. It was to make the platform legible as a product, align expectations to actual capability through an agreed prioritization framework, and keep five parallel workstreams pointed at one destination while ownership steadily moved from us to the enterprise.

Confidentiality boundary

Platform architecture, internal program names, commercial terms, and transition plans are generalized. The operating model, workstream structure, and leadership decisions are represented faithfully.

See what must move together.

The engagement runs in four movements rather than a straight line. Each one changes what "good" means, so each one needs its own definition of ready before the next can start.

01 / AlignExpectation to capability

Establish what the platform can do now, and the prioritization framework that governs what comes next.

02 / BuildPlatform and pipes

Stand up the CDP and its connections into the existing martech stack.

03 / OperateRun it in the open

Prove the platform under real activation demand, with governance holding.

04 / TransferOwnership moves

Hand capability, documentation, and decision rights to enterprise teams.

The five workstreams run in parallel across those movements. They are deliberately not all technical—two of the five exist because a platform nobody understands or trusts will not be adopted, however well it is engineered.

Scope of servicesFive parallel workstreams
01

Value realization

Tie platform capability to outcomes the business actually asked for, and show the connection.

02

Organizational change management

Bring stakeholders to a working understanding of the CDP as a product, not a one-off project.

03

Data governance, taxonomy & metadata

Definitions, ownership, and structure—the layer that decides whether activation is trustworthy.

04

Program management & executive communications

Cross-pillar alignment, decision flow, and a leadership view built around what needs deciding.

05

System integration & enterprise connectivity

The CDP as an activation tool inside the existing stack rather than a destination beside it.

Manage the seams, not just the streams.

The transformation risk lived between programs—where ownership, assumptions, and timing could quietly diverge.

01

Design the transfer on day one

Treat handover as a property of how the work is done, not a phase at the end. Documentation, decision rights, and enterprise capability are built while the platform is—because a transfer scheduled for later is a transfer that arrives unearned.

02

Govern demand with a framework, not a queue

An agreed prioritization framework lets a "no, not yet" be a shared position about sequencing rather than a delivery team's refusal. Without it, every request becomes a negotiation and capability gaps read as failures.

03

Separate progress from readiness

Make each workstream prove its transition conditions with evidence instead of equating activity with confidence. Percent-complete describes effort; readiness describes risk.

04

Escalate consequence, not status

Frame issues around what becomes impossible, costly, or irreversible if a decision does not land—so escalation protects momentum rather than documenting delay.

05

Hold one narrative across pillars

Give teams and executives a coherent view of the same transformation even when their local details differ, so leadership can intervene at the system level.

Movement became coordinated.

The work gained a clearer view of what must move together, where decisions were blocked, and what each program needed before transition.

That shared readiness view let teams discuss the same transformation rather than several disconnected local plans. It also kept the analytics program connected to the decisions shaping the wider platform.

BOTTransfer built in

Handover treated as a property of the operating model rather than a closing phase.

FiveWorkstreams, one destination

Technical and organizational tracks pointed at the same definition of ready.

E2EReadiness logic

Evidence carried from local delivery through to coordinated enterprise transition.

What this work reinforced.

Transformation leadership is often the work of making the space between programs visible.

  • The most consequential dependency is often a decision, not a deliverable.
  • Readiness must be evidence-based or it becomes a synonym for optimism.
  • A shared narrative lets leaders intervene at the system level instead of chasing local status.
Coordinating a transformation with too many moving parts?

Let’s make the system visible.

Start a conversation →