Turn complex IT transformation into measurable business progress

Both, and the contract says which before you sign it. The usual shape is that named senior people sit inside your programme structure rather than beside it: a transformation programme manager who owns the plan, the governance and the reporting to your executives, with lead architects on the business and the IT side. Where the work is an assessment rather than a delivery it is advisory, and it ends in a report and an action plan. On the larger programmes we have chaired the governance bodies we designed and led negotiation with the counterparty on the client’s behalf — which is running it, not advising on it.

With two sets of documents meeting in the middle. From the separating side, a prepared separation proposal for each system domain. From yours, three things that have to exist before any design begins: the target architecture, the application landscape, and the target operating model. Those meet in high-level design workshops run domain by domain — core ERP, workforce and decision support, metering, operational systems, document management, infrastructure — and converge into a single transition design and roadmap. If there is no transaction and it is your own estate being reshaped, the equivalent first step is a survey of the organisation, processes, contracts and measures as they are, then gap analysis, before anybody draws a target.

The date stops being a deadline and becomes the constraint that outranks technical preference. On a carve-out we ran, the governing directive was written as two things at once — the closing date, and a working operation the morning after it — and the depth of separation was then set per class of system rather than uniformly: administrative systems separated logically, operational systems on a mixed basis, because separating everything physically would not have landed in time. When the counterparty later asked for full physical separation of the operational systems by closing, the request was neither refused nor waved through: it went through three explicit tests — better on total cost of ownership, does not endanger the date, technically future-proof — and only a change passing all three proceeded. Planning continued in a joint architect working group on a fixed fortnightly cadence, so a scope question was answered in a fortnight rather than in a change-request queue.

Three senior roles, and we normally propose all three rather than offering a choice between them. A transformation programme manager: the programme plan, the governance, reporting to your executives, and coordination of your specialist teams and your suppliers. A lead business architect: the to-be process catalogue, fit-gap analysis, and scope control with simplification proposals attached. A lead IT architect: the architecture roadmap, integration design and validation, and the working relationship with your IT leadership. Where the schedule is compressed we propose all three at full-time allocation rather than part-time, because part-time senior roles are the first thing a tight programme breaks.

Cutover is the switchover itself — the hours and days in which systems, data and business processes actually move — and it needs its own plan because no single application stream can see the dependencies between the others. It runs in four stages. Planning: each stream works out its own migration procedure and technical conditions, and a dedicated cutover team merges them, resolves the anomalies between them, or hands them back to the owning stream as tasks. Rehearsal: migrations are tested and refined in the streams, and the cutover plan is amended against what actually happened. Go-live: run from one consolidated schedule with a dashboard per system, so the state of everything is visible at once. And babysitting: roughly three weeks afterwards for the long tail of work, ending in a formal handover to your business-as-usual teams rather than at go-live.

It is reported by name with the consequence attached, and a workaround is designed before it becomes a crisis. Enablers are tracked on one consolidated schedule with dated milestones, and every area is reported across all the organisations involved as not affected, on plan, or slipping — with a comment saying why, in plain words, including “this procurement has not started”. On one programme where the production hardware procurement had not begun, the same report carried both a documented fallback so the dependent work could proceed without it, and a record that the other blocked dependency had been escalated. And the downstream consequence was written down rather than implied: if these milestones move, the next wave moves with them. That is the sentence that makes a steering committee act.

A PMO tracks the plan. What large programmes usually lack is something that owns the seams between streams, and a body with the authority to decide. Three things get added. A cutover team belonging to no single stream, whose whole job is the space between them. An architecture forum with a chair, a fixed slot, a decision sheet and a decision register — and a written statement of what it may decide and what remains the project manager’s, so that the two do not collide in month four. And a responsibility matrix that crosses company boundaries — you, your IT service company, the counterparty — deliberately reconciled against the responsibilities already written into the separation contract, so the two cannot contradict each other.

The governance is built to be handed over rather than withdrawn. An architecture forum is delivered as a rulebook you own: who chairs it, how often it meets, what an agenda item looks like, and templates for the decision sheet, the decision register and the minutes — including the rule that a project cannot close until the architecture record has been updated, which is what stops the documentation decaying the month after we go. A cutover ends in a defined handover and acceptance to your business-as-usual organisation after the babysitting period, not at go-live. And on advisory work the analytical framework and the templates are designed from the outset to be reusable, and are handed over adapted to your organisation rather than to ours.

Two shapes, priced differently on purpose. A bounded assessment — IT organisation, governance, contracts, processes — is a fixed price against a stated number of weeks. A transformation programme is priced by role at full-time allocation, with a lower rate above a minimum commitment period, because these are multi-month placements rather than deliverables and pretending otherwise helps nobody. On scale: programmes of this kind run in waves, and the ones we have led have spanned around two years from first planning to the final wave going live, with individual cutovers planned roughly eight months ahead of the switchover date.

From the reporting, before you hear it anywhere else. Steering packs carry a red, amber or green status per area, with the reason in plain words and the forward consequence stated — that a slip here moves the next wave. Where something is genuinely blocked, the same pack records that it has been escalated and what the fallback is, rather than carrying the problem quietly to the next meeting. And the things nobody wants on a slide go on the slide: on one programme we wrote down in advance that the most complex wave was too complex to rehearse end to end. That is a sentence a supplier is tempted to leave out, and exactly the one a steering committee needs early enough to plan around.