Program management for digital commerce: a field guide

A program is a set of projects that only make sense together. A multi-brand commerce replatform is a program: the platform build, the PIM integration, the data migration, the payments and tax work, the storefront design, the go-live and hypercare are separate projects with separate teams, and the business outcome — one platform, lower cost to operate, higher conversion — arrives only when all of them land. A single storefront redesign is a project. Calling a project a program inflates cost and slows decisions; calling a program a project loses the dependencies and blows the date.

Not scheduling. The job is to own three things nobody else owns: the dependencies between workstreams, the budget and benefits case as a whole, and the single version of the truth the sponsor hears. Everything else — standups, Jira hygiene, release notes — is delegated to project leads. When a program manager is running standups, the program has no program manager.

Discovery and architecture (4–6 weeks). Outcome: signed target architecture, data model, integration map, non-negotiable dates, and a budget with contingency the sponsor has seen.

Build workstreams in parallel (12–20 weeks). Platform (Adobe Commerce / Shopify Plus), PIM (Pimcore), integrations (ERP, OMS, payments, tax, search), storefront, data migration. Each has a lead, a weekly demo and a dependency register.

Integration and performance testing (4 weeks). The program manager owns the test environment calendar; contention here is the most common cause of slipped dates.

Go-live and hypercare (2 + 4 weeks). Rehearsed cutover, rollback tested, hypercare rota staffed, acceptance signed.

Benefits tracking (quarterly, 12 months). Conversion, cost to operate, time to launch a brand or market. Without this, nobody knows if the program worked.

Every program I run has one dependency register, owned by me, reviewed weekly. Each line: what is needed, from whom, by when, what breaks if it is late, and the decision date by which we re-plan. Most program failures are not engineering failures; they are a dependency that was known for eight weeks and escalated in week nine.

A 30-minute weekly steering with three slides: outcome status (RAG against the benefits, not the tasks), the three decisions needed this week, and the money (spent, committed, forecast to complete). Anything longer becomes status theatre and sponsors stop coming. The program manager's credibility is built on those three slides being right every week.

Hold 10–15% contingency and make it visible; hidden contingency gets spent by the team, visible contingency gets spent by the sponsor on things that matter. Every scope change gets a change request within the week, priced, with its impact on the date. Report spend against forecast-to-complete, not against the original budget — the original budget is history.

Five regions means five tax regimes, five payment stacks, five launch calendars and at least three time zones for the team. The things that work: one global platform template with regional configuration rather than regional forks; a regional launch sequence that starts with the smallest market to burn in the runbook; and a follow-the-sun hypercare rota agreed before the first go-live.

Three consecutive Adobe Commerce production upgrades, each protecting live trading, taught the pattern: treat each upgrade as a small program with its own discovery (compatibility audit of every extension and customisation), a full-environment rehearsal, a blue-green or maintenance-window plan the client has approved, a rollback that has actually been executed in staging, and a hypercare week. Upgrades fail as projects because they are treated as tasks.

An AI supply-chain program for a global CPG brand delivered +22% forecast accuracy and −18% stock-outs. The data science was perhaps a third of the work. The rest was program management: data access agreements, integration with the planning system, planner training, a benefits baseline measured before the model went live, and a decision on what the model was allowed to do (advise) and not do (order). AI programs that skip those parts produce a demo, not a result.

A program manager owns one outcome across several projects. A delivery leader owns every program and project in the practice and the P&L they produce. The best program managers become delivery leaders when they start caring about the margin on programs they do not personally run.