If you only change one thing about how your programme is set up, change its size.

The Standish Group spent twenty-five years tracking around 50,000 IT projects. Their final report in 2020 found success rates ranging from about 61% for small projects down to 6% for the very largest. Projects over $10 million were reported to be more than ten times more likely to be cancelled than projects under $1 million.

A fair warning about that data: Standish never published its full methodology, and researchers have criticised it for years — the definition of “success” leans heavily on time and budget rather than value. So treat the exact figures loosely.

But nobody seriously disputes the direction. Big programmes fail more. They fail more because everything about them is harder: more dependencies, more people who need to agree, longer gaps between deciding and finding out whether you were right, and a scope that keeps growing because the programme is the only vehicle in town and everybody wants their thing on it.

So the first real question is not “how do we deliver this successfully?” It is “how do we cut this into pieces that each deliver something on their own?”

The wrong way to slice is by system layer or module — infrastructure first, then integrations, then the front end. That produces phases where nothing works until the last one, which is a big bang wearing a costume.

The right way is by outcome. One complete thing that somebody uses. One country, one product line, one process end to end, one customer segment. It must work by itself, or it is not a slice.

The test: if the money ran out after phase one, would you have something of value? If the answer is no, you have not divided the project. You have just added milestones to it.

Most transformation goals cannot be failed. That is their central defect.

“Modernise the platform.” “Move to cloud.” “Implement the new ERP.” Every one of these can be declared achieved by someone standing in front of a slide, and nobody in the room can argue.

Compare with: close the monthly accounts in four days instead of eleven. You can hold that up in March and see whether it is true.

This is the discipline the project management world calls benefits realisation, and PMI’s research with BCG puts it among the strongest drivers of project success — behind actively engaged executive sponsorship and alignment to strategy, and ahead of most things people spend their planning time on. Their less flattering finding is that plenty of organisations have a benefits process on paper and few follow it.

Practically, before anything starts, write down for each phase:

• What is measurably different afterwards, in one sentence
• The number, with today’s value written next to it
• When it should be true
• Who is accountable for it — a named person on the business side, not the project manager

That last one matters more than it looks. If the only person who owns the benefit is the person delivering the project, then the moment the project closes, the benefit becomes nobody’s problem. This is exactly why so many transformations get delivered and yet nothing changes: everybody’s job ended at go-live.

Here is the most common quiet killer, and it looks completely reasonable in a plan.

You assign your best people to the programme — at 20%. They already run the systems everyone depends on. So when there is an outage, or a month-end, or a customer escalation, the programme is what gets dropped. Every time. It is the correct decision each individual time it is made, and cumulatively it means the transformation is staffed by whoever happens to be free that week.

PMI’s work on programme structure keeps pointing at the same thing: a dedicated core team, with an executive sponsor and a change owner as real roles rather than names on a chart.

Two specifics that matter more than the org design:

The sponsor has to be available at the moments that count. Research on ERP go-lives keeps finding that programmes falter not because of technical problems but because leadership was not present when a decision was needed. If your cutover weekend arrives and the person who can say “we go” or “we roll back” is unreachable, you have designed a failure into the plan.

The business side needs its best people, not its most available. The people who genuinely understand how the work is done are always the busiest ones. If you cannot free them, that is not a resourcing problem to be worked around. It is the organisation telling you it does not have capacity for this transformation right now, and it would be cheaper to listen.

If you only change one thing about how your programme is set up, change its size.

The Standish Group spent twenty-five years tracking around 50,000 IT projects. Their final report in 2020 found success rates ranging from about 61% for small projects down to 6% for the very largest. Projects over $10 million were reported to be more than ten times more likely to be cancelled than projects under $1 million.

A fair warning about that data: Standish never published its full methodology, and researchers have criticised it for years — the definition of “success” leans heavily on time and budget rather than value. So treat the exact figures loosely.

But nobody seriously disputes the direction. Big programmes fail more. They fail more because everything about them is harder: more dependencies, more people who need to agree, longer gaps between deciding and finding out whether you were right, and a scope that keeps growing because the programme is the only vehicle in town and everybody wants their thing on it.

So the first real question is not “how do we deliver this successfully?” It is “how do we cut this into pieces that each deliver something on their own?”

The wrong way to slice is by system layer or module — infrastructure first, then integrations, then the front end. That produces phases where nothing works until the last one, which is a big bang wearing a costume.

The right way is by outcome. One complete thing that somebody uses. One country, one product line, one process end to end, one customer segment. It must work by itself, or it is not a slice.

The test: if the money ran out after phase one, would you have something of value? If the answer is no, you have not divided the project. You have just added milestones to it.

Most transformation goals cannot be failed. That is their central defect.

“Modernise the platform.” “Move to cloud.” “Implement the new ERP.” Every one of these can be declared achieved by someone standing in front of a slide, and nobody in the room can argue.

Compare with: close the monthly accounts in four days instead of eleven. You can hold that up in March and see whether it is true.

This is the discipline the project management world calls benefits realisation, and PMI’s research with BCG puts it among the strongest drivers of project success — behind actively engaged executive sponsorship and alignment to strategy, and ahead of most things people spend their planning time on. Their less flattering finding is that plenty of organisations have a benefits process on paper and few follow it.

Practically, before anything starts, write down for each phase:

• What is measurably different afterwards, in one sentence
• The number, with today’s value written next to it
• When it should be true
• Who is accountable for it — a named person on the business side, not the project manager

That last one matters more than it looks. If the only person who owns the benefit is the person delivering the project, then the moment the project closes, the benefit becomes nobody’s problem. This is exactly why so many transformations get delivered and yet nothing changes: everybody’s job ended at go-live.

Here is the most common quiet killer, and it looks completely reasonable in a plan.

You assign your best people to the programme — at 20%. They already run the systems everyone depends on. So when there is an outage, or a month-end, or a customer escalation, the programme is what gets dropped. Every time. It is the correct decision each individual time it is made, and cumulatively it means the transformation is staffed by whoever happens to be free that week.

PMI’s work on programme structure keeps pointing at the same thing: a dedicated core team, with an executive sponsor and a change owner as real roles rather than names on a chart.

Two specifics that matter more than the org design:

The sponsor has to be available at the moments that count. Research on ERP go-lives keeps finding that programmes falter not because of technical problems but because leadership was not present when a decision was needed. If your cutover weekend arrives and the person who can say “we go” or “we roll back” is unreachable, you have designed a failure into the plan.

The business side needs its best people, not its most available. The people who genuinely understand how the work is done are always the busiest ones. If you cannot free them, that is not a resourcing problem to be worked around. It is the organisation telling you it does not have capacity for this transformation right now, and it would be cheaper to listen.

If you only change one thing about how your programme is set up, change its size.

The Standish Group spent twenty-five years tracking around 50,000 IT projects. Their final report in 2020 found success rates ranging from about 61% for small projects down to 6% for the very largest. Projects over $10 million were reported to be more than ten times more likely to be cancelled than projects under $1 million.

A fair warning about that data: Standish never published its full methodology, and researchers have criticised it for years — the definition of “success” leans heavily on time and budget rather than value. So treat the exact figures loosely.

But nobody seriously disputes the direction. Big programmes fail more. They fail more because everything about them is harder: more dependencies, more people who need to agree, longer gaps between deciding and finding out whether you were right, and a scope that keeps growing because the programme is the only vehicle in town and everybody wants their thing on it.

So the first real question is not “how do we deliver this successfully?” It is “how do we cut this into pieces that each deliver something on their own?”

The wrong way to slice is by system layer or module — infrastructure first, then integrations, then the front end. That produces phases where nothing works until the last one, which is a big bang wearing a costume.

The right way is by outcome. One complete thing that somebody uses. One country, one product line, one process end to end, one customer segment. It must work by itself, or it is not a slice.

The test: if the money ran out after phase one, would you have something of value? If the answer is no, you have not divided the project. You have just added milestones to it.

Most transformation goals cannot be failed. That is their central defect.

“Modernise the platform.” “Move to cloud.” “Implement the new ERP.” Every one of these can be declared achieved by someone standing in front of a slide, and nobody in the room can argue.

Compare with: close the monthly accounts in four days instead of eleven. You can hold that up in March and see whether it is true.

This is the discipline the project management world calls benefits realisation, and PMI’s research with BCG puts it among the strongest drivers of project success — behind actively engaged executive sponsorship and alignment to strategy, and ahead of most things people spend their planning time on. Their less flattering finding is that plenty of organisations have a benefits process on paper and few follow it.

Practically, before anything starts, write down for each phase:

• What is measurably different afterwards, in one sentence
• The number, with today’s value written next to it
• When it should be true
• Who is accountable for it — a named person on the business side, not the project manager

That last one matters more than it looks. If the only person who owns the benefit is the person delivering the project, then the moment the project closes, the benefit becomes nobody’s problem. This is exactly why so many transformations get delivered and yet nothing changes: everybody’s job ended at go-live.

Here is the most common quiet killer, and it looks completely reasonable in a plan.

You assign your best people to the programme — at 20%. They already run the systems everyone depends on. So when there is an outage, or a month-end, or a customer escalation, the programme is what gets dropped. Every time. It is the correct decision each individual time it is made, and cumulatively it means the transformation is staffed by whoever happens to be free that week.

PMI’s work on programme structure keeps pointing at the same thing: a dedicated core team, with an executive sponsor and a change owner as real roles rather than names on a chart.

Two specifics that matter more than the org design:

The sponsor has to be available at the moments that count. Research on ERP go-lives keeps finding that programmes falter not because of technical problems but because leadership was not present when a decision was needed. If your cutover weekend arrives and the person who can say “we go” or “we roll back” is unreachable, you have designed a failure into the plan.

The business side needs its best people, not its most available. The people who genuinely understand how the work is done are always the busiest ones. If you cannot free them, that is not a resourcing problem to be worked around. It is the organisation telling you it does not have capacity for this transformation right now, and it would be cheaper to listen.

If you only change one thing about how your programme is set up, change its size.

The Standish Group spent twenty-five years tracking around 50,000 IT projects. Their final report in 2020 found success rates ranging from about 61% for small projects down to 6% for the very largest. Projects over $10 million were reported to be more than ten times more likely to be cancelled than projects under $1 million.

A fair warning about that data: Standish never published its full methodology, and researchers have criticised it for years — the definition of “success” leans heavily on time and budget rather than value. So treat the exact figures loosely.

But nobody seriously disputes the direction. Big programmes fail more. They fail more because everything about them is harder: more dependencies, more people who need to agree, longer gaps between deciding and finding out whether you were right, and a scope that keeps growing because the programme is the only vehicle in town and everybody wants their thing on it.

So the first real question is not “how do we deliver this successfully?” It is “how do we cut this into pieces that each deliver something on their own?”

The wrong way to slice is by system layer or module — infrastructure first, then integrations, then the front end. That produces phases where nothing works until the last one, which is a big bang wearing a costume.

The right way is by outcome. One complete thing that somebody uses. One country, one product line, one process end to end, one customer segment. It must work by itself, or it is not a slice.

The test: if the money ran out after phase one, would you have something of value? If the answer is no, you have not divided the project. You have just added milestones to it.

Most transformation goals cannot be failed. That is their central defect.

“Modernise the platform.” “Move to cloud.” “Implement the new ERP.” Every one of these can be declared achieved by someone standing in front of a slide, and nobody in the room can argue.

Compare with: close the monthly accounts in four days instead of eleven. You can hold that up in March and see whether it is true.

This is the discipline the project management world calls benefits realisation, and PMI’s research with BCG puts it among the strongest drivers of project success — behind actively engaged executive sponsorship and alignment to strategy, and ahead of most things people spend their planning time on. Their less flattering finding is that plenty of organisations have a benefits process on paper and few follow it.

Practically, before anything starts, write down for each phase:

• What is measurably different afterwards, in one sentence
• The number, with today’s value written next to it
• When it should be true
• Who is accountable for it — a named person on the business side, not the project manager

That last one matters more than it looks. If the only person who owns the benefit is the person delivering the project, then the moment the project closes, the benefit becomes nobody’s problem. This is exactly why so many transformations get delivered and yet nothing changes: everybody’s job ended at go-live.

Here is the most common quiet killer, and it looks completely reasonable in a plan.

You assign your best people to the programme — at 20%. They already run the systems everyone depends on. So when there is an outage, or a month-end, or a customer escalation, the programme is what gets dropped. Every time. It is the correct decision each individual time it is made, and cumulatively it means the transformation is staffed by whoever happens to be free that week.

PMI’s work on programme structure keeps pointing at the same thing: a dedicated core team, with an executive sponsor and a change owner as real roles rather than names on a chart.

Two specifics that matter more than the org design:

The sponsor has to be available at the moments that count. Research on ERP go-lives keeps finding that programmes falter not because of technical problems but because leadership was not present when a decision was needed. If your cutover weekend arrives and the person who can say “we go” or “we roll back” is unreachable, you have designed a failure into the plan.

The business side needs its best people, not its most available. The people who genuinely understand how the work is done are always the busiest ones. If you cannot free them, that is not a resourcing problem to be worked around. It is the organisation telling you it does not have capacity for this transformation right now, and it would be cheaper to listen.

Poor data migration is cited as the cause of around 38% of ERP failures. It is the single most under-planned part of nearly every programme, because in the plan it is one line near the end, and in reality it is most of the work.

Do it first, not last:

Profile the real data early. Not a sample — actually count the duplicates, the empty required fields, the eleven spellings of the same supplier, the records with dates in 2087. You want that number in month one, when the plan can still absorb it.

Decide what you are not migrating. This is the most valuable conversation of the entire programme and it is always avoided, because the safe answer is “bring everything.” Bringing everything means importing twenty years of accumulated mess into a clean system and then paying to maintain it forever. Old closed records can live in a read-only archive. They do not need to be in the new system.

Agree who decides what the old data meant. Somebody has to rule, thousands of times, on what STATUS_2 = 4 signified in 2011. That person must know the business. It cannot be a contractor working from a mapping spreadsheet.

Migrate for real, repeatedly. Not “test the migration script” — run the full load, on full volume, and have business people look at the result and tell you what is wrong. Then do it again. The last rehearsal should be boring.

Lidl abandoned a SAP programme after seven years and roughly €500 million, and the reported core of it was a mismatch between its internal way of pricing and the software’s standard. Rather than change the process, they kept changing the software.

Every organisation faces a small version of this decision hundreds of times. And every single time, changing the software is the path of least resistance in the room, because the people who would have to change are sitting right there and the software is not.

You cannot decide this case by case in the moment. You need a rule agreed before the arguments start:

• Standard is the default. The burden of proof sits with the exception.
• A fixed customisation budget — a number of them, not just money. When it is used up, further changes require something else to be given up.
• A named decision-maker for exceptions, senior enough to say no to a department head.
• A written test: does this difference actually win us customers or keep us legal? “This is how we have always done it” fails the test.

Some exceptions are legitimate. The point is not zero customisation — it is that each one is a deliberate purchase with a visible price, rather than an accumulation of small reasonable-sounding yeses that together rebuild your old system inside the new one.

There is a version of user involvement that achieves nothing: a demo, a workshop, a slide asking for feedback. Everyone nods. Nothing is learned.

What you need is real users doing their actual work in the real system, early enough that what they say can still change the outcome.

Pick a small group. Give them real transactions, not test data. Watch them — physically, or over a screen share. Do not ask “does this look okay?”, because people are polite. Ask them to complete their normal Tuesday and observe where they stop, sigh, or open a spreadsheet instead.

The spreadsheet is the signal. When a user quietly works around your new system, that is your project’s future in miniature. Fix it now, or watch it become the shadow process that undermines the whole thing.

And take the complaints seriously in a specific way. Most will be “it’s different.” Some will be “this now takes four steps instead of one, forty times a day.” The second kind is the one that decides whether the system is adopted or endured.

For any switchover with a date, the practice here is well established and consistently skipped.

Write the runbook about four weeks out. Every step, in order, with times, owners and dependencies. Not a plan — a script somebody could follow at 3am while tired.

Run a full timed dress rehearsal. Same data, same tools, same people, same clock, on a copy of production. Not a walkthrough. The point is to discover that step 34 takes six hours instead of ninety minutes while it is still Tuesday and not the actual weekend. Teams that skip rehearsal reliably find their blockers at 2am on a Saturday.

Rehearse the rollback too. Almost nobody does. This is why so many organisations end up limping forward through a failed cutover — not because going back was the wrong call, but because nobody knew how.

Set explicit go/no-go checkpoints. A readiness review a few weeks out, a recommendation after the final rehearsal, and a real go/no-go during the cutover window with named criteria agreed in advance. Agree what “no” looks like while everyone is still calm. In the moment, with money spent and people waiting, the pressure to continue is enormous, and that is precisely when a pre-agreed threshold earns its keep.

Check the sponsor is genuinely available. In the room or on the phone, for the whole window.

Go-live is the middle of the project. Plans that treat it as the end fail in a very predictable way.

The established pattern is hypercare: an intense support period, usually two to four weeks and longer for complex rollouts, where issue volume peaks in week one. Daily triage, fast fixes, people physically available to help, and close monitoring of the transactions that matter most.

The common mistake is releasing the team at go-live. The consultants roll off, the internal people go back to their day jobs, and the users hit their first real month-end alone with a system nobody has time to fix. That is the point where an otherwise successful implementation acquires its permanent reputation as a disaster.

Two things to hold on to during this period: keep a daily list of what is actually broken and be visible about closing it, and resist reopening design decisions. Week one after go-live is when every compromise gets challenged again by people who are stressed. Fix what is broken. Log the rest for later.

The quiet failure mode of sensible incremental delivery is stopping halfway. The easy 60% moves, the hard 40% turns out to be genuinely hard, priorities shift, and five years later you are paying for both systems and explaining to new starters which one is authoritative.

The fix is unromantic. The decommissioning date goes in the plan at the start, with a budget and an owner, alongside the archive plan for the data you are not migrating. Decommissioning is a project, not a cleanup task, and if it is nobody’s job it will never happen.

An old system that stays alive “just in case” is not a safety net. It is a second system, with its own licences, its own vulnerabilities, and its own claim on the people you need elsewhere.

The last discipline, and the rarest: go back.

Six and twelve months after each phase, take the numbers you wrote down at the start and check them. Did the close actually shorten? Did the tickets fall? Did the cost per order move?

This is uncomfortable, which is why almost nobody does it. It is also the only thing that makes the next transformation better than this one, because it is the only point at which the organisation finds out whether its business cases are honest.

The reason to do this is not accountability theatre. It is that most organisations run these programmes repeatedly for decades and never build up any real evidence about which of their assumptions were true.

If you only change one thing about how your programme is set up, change its size.

The Standish Group spent twenty-five years tracking around 50,000 IT projects. Their final report in 2020 found success rates ranging from about 61% for small projects down to 6% for the very largest. Projects over $10 million were reported to be more than ten times more likely to be cancelled than projects under $1 million.

A fair warning about that data: Standish never published its full methodology, and researchers have criticised it for years — the definition of “success” leans heavily on time and budget rather than value. So treat the exact figures loosely.

But nobody seriously disputes the direction. Big programmes fail more. They fail more because everything about them is harder: more dependencies, more people who need to agree, longer gaps between deciding and finding out whether you were right, and a scope that keeps growing because the programme is the only vehicle in town and everybody wants their thing on it.

So the first real question is not “how do we deliver this successfully?” It is “how do we cut this into pieces that each deliver something on their own?”

The wrong way to slice is by system layer or module — infrastructure first, then integrations, then the front end. That produces phases where nothing works until the last one, which is a big bang wearing a costume.

The right way is by outcome. One complete thing that somebody uses. One country, one product line, one process end to end, one customer segment. It must work by itself, or it is not a slice.

The test: if the money ran out after phase one, would you have something of value? If the answer is no, you have not divided the project. You have just added milestones to it.

Most transformation goals cannot be failed. That is their central defect.

“Modernise the platform.” “Move to cloud.” “Implement the new ERP.” Every one of these can be declared achieved by someone standing in front of a slide, and nobody in the room can argue.

Compare with: close the monthly accounts in four days instead of eleven. You can hold that up in March and see whether it is true.

This is the discipline the project management world calls benefits realisation, and PMI’s research with BCG puts it among the strongest drivers of project success — behind actively engaged executive sponsorship and alignment to strategy, and ahead of most things people spend their planning time on. Their less flattering finding is that plenty of organisations have a benefits process on paper and few follow it.

Practically, before anything starts, write down for each phase:

• What is measurably different afterwards, in one sentence
• The number, with today’s value written next to it
• When it should be true
• Who is accountable for it — a named person on the business side, not the project manager

That last one matters more than it looks. If the only person who owns the benefit is the person delivering the project, then the moment the project closes, the benefit becomes nobody’s problem. This is exactly why so many transformations get delivered and yet nothing changes: everybody’s job ended at go-live.

Here is the most common quiet killer, and it looks completely reasonable in a plan.

You assign your best people to the programme — at 20%. They already run the systems everyone depends on. So when there is an outage, or a month-end, or a customer escalation, the programme is what gets dropped. Every time. It is the correct decision each individual time it is made, and cumulatively it means the transformation is staffed by whoever happens to be free that week.

PMI’s work on programme structure keeps pointing at the same thing: a dedicated core team, with an executive sponsor and a change owner as real roles rather than names on a chart.

Two specifics that matter more than the org design:

The sponsor has to be available at the moments that count. Research on ERP go-lives keeps finding that programmes falter not because of technical problems but because leadership was not present when a decision was needed. If your cutover weekend arrives and the person who can say “we go” or “we roll back” is unreachable, you have designed a failure into the plan.

The business side needs its best people, not its most available. The people who genuinely understand how the work is done are always the busiest ones. If you cannot free them, that is not a resourcing problem to be worked around. It is the organisation telling you it does not have capacity for this transformation right now, and it would be cheaper to listen.

Poor data migration is cited as the cause of around 38% of ERP failures. It is the single most under-planned part of nearly every programme, because in the plan it is one line near the end, and in reality it is most of the work.

Do it first, not last:

Profile the real data early. Not a sample — actually count the duplicates, the empty required fields, the eleven spellings of the same supplier, the records with dates in 2087. You want that number in month one, when the plan can still absorb it.

Decide what you are not migrating. This is the most valuable conversation of the entire programme and it is always avoided, because the safe answer is “bring everything.” Bringing everything means importing twenty years of accumulated mess into a clean system and then paying to maintain it forever. Old closed records can live in a read-only archive. They do not need to be in the new system.

Agree who decides what the old data meant. Somebody has to rule, thousands of times, on what STATUS_2 = 4 signified in 2011. That person must know the business. It cannot be a contractor working from a mapping spreadsheet.

Migrate for real, repeatedly. Not “test the migration script” — run the full load, on full volume, and have business people look at the result and tell you what is wrong. Then do it again. The last rehearsal should be boring.

Lidl abandoned a SAP programme after seven years and roughly €500 million, and the reported core of it was a mismatch between its internal way of pricing and the software’s standard. Rather than change the process, they kept changing the software.

Every organisation faces a small version of this decision hundreds of times. And every single time, changing the software is the path of least resistance in the room, because the people who would have to change are sitting right there and the software is not.

You cannot decide this case by case in the moment. You need a rule agreed before the arguments start:

• Standard is the default. The burden of proof sits with the exception.
• A fixed customisation budget — a number of them, not just money. When it is used up, further changes require something else to be given up.
• A named decision-maker for exceptions, senior enough to say no to a department head.
• A written test: does this difference actually win us customers or keep us legal? “This is how we have always done it” fails the test.

Some exceptions are legitimate. The point is not zero customisation — it is that each one is a deliberate purchase with a visible price, rather than an accumulation of small reasonable-sounding yeses that together rebuild your old system inside the new one.

There is a version of user involvement that achieves nothing: a demo, a workshop, a slide asking for feedback. Everyone nods. Nothing is learned.

What you need is real users doing their actual work in the real system, early enough that what they say can still change the outcome.

Pick a small group. Give them real transactions, not test data. Watch them — physically, or over a screen share. Do not ask “does this look okay?”, because people are polite. Ask them to complete their normal Tuesday and observe where they stop, sigh, or open a spreadsheet instead.

The spreadsheet is the signal. When a user quietly works around your new system, that is your project’s future in miniature. Fix it now, or watch it become the shadow process that undermines the whole thing.

And take the complaints seriously in a specific way. Most will be “it’s different.” Some will be “this now takes four steps instead of one, forty times a day.” The second kind is the one that decides whether the system is adopted or endured.

For any switchover with a date, the practice here is well established and consistently skipped.

Write the runbook about four weeks out. Every step, in order, with times, owners and dependencies. Not a plan — a script somebody could follow at 3am while tired.

Run a full timed dress rehearsal. Same data, same tools, same people, same clock, on a copy of production. Not a walkthrough. The point is to discover that step 34 takes six hours instead of ninety minutes while it is still Tuesday and not the actual weekend. Teams that skip rehearsal reliably find their blockers at 2am on a Saturday.

Rehearse the rollback too. Almost nobody does. This is why so many organisations end up limping forward through a failed cutover — not because going back was the wrong call, but because nobody knew how.

Set explicit go/no-go checkpoints. A readiness review a few weeks out, a recommendation after the final rehearsal, and a real go/no-go during the cutover window with named criteria agreed in advance. Agree what “no” looks like while everyone is still calm. In the moment, with money spent and people waiting, the pressure to continue is enormous, and that is precisely when a pre-agreed threshold earns its keep.

Check the sponsor is genuinely available. In the room or on the phone, for the whole window.

Go-live is the middle of the project. Plans that treat it as the end fail in a very predictable way.

The established pattern is hypercare: an intense support period, usually two to four weeks and longer for complex rollouts, where issue volume peaks in week one. Daily triage, fast fixes, people physically available to help, and close monitoring of the transactions that matter most.

The common mistake is releasing the team at go-live. The consultants roll off, the internal people go back to their day jobs, and the users hit their first real month-end alone with a system nobody has time to fix. That is the point where an otherwise successful implementation acquires its permanent reputation as a disaster.

Two things to hold on to during this period: keep a daily list of what is actually broken and be visible about closing it, and resist reopening design decisions. Week one after go-live is when every compromise gets challenged again by people who are stressed. Fix what is broken. Log the rest for later.

The quiet failure mode of sensible incremental delivery is stopping halfway. The easy 60% moves, the hard 40% turns out to be genuinely hard, priorities shift, and five years later you are paying for both systems and explaining to new starters which one is authoritative.

The fix is unromantic. The decommissioning date goes in the plan at the start, with a budget and an owner, alongside the archive plan for the data you are not migrating. Decommissioning is a project, not a cleanup task, and if it is nobody’s job it will never happen.

An old system that stays alive “just in case” is not a safety net. It is a second system, with its own licences, its own vulnerabilities, and its own claim on the people you need elsewhere.

The last discipline, and the rarest: go back.

Six and twelve months after each phase, take the numbers you wrote down at the start and check them. Did the close actually shorten? Did the tickets fall? Did the cost per order move?

This is uncomfortable, which is why almost nobody does it. It is also the only thing that makes the next transformation better than this one, because it is the only point at which the organisation finds out whether its business cases are honest.

The reason to do this is not accountability theatre. It is that most organisations run these programmes repeatedly for decades and never build up any real evidence about which of their assumptions were true.

There is a hope in the air right now that AI will make all of this faster, and there is genuine evidence for part of it.

Google’s 2025 DORA research — the most credible ongoing data set in software delivery — found AI adoption correlates positively with throughput. It also found it correlates with more instability: more change failures, more rework. Their conclusion is that AI is an amplifier rather than a solution. Teams with strong foundations get faster. Teams without them get worse faster. AI mostly exposes the bottlenecks that were already downstream, in testing, review and quality.

One more finding is worth carrying into any transformation: teams with a genuine user focus gained the most from AI, and teams without it sometimes saw performance get worse.

Which is the same lesson as everything above, arriving in new clothing. Faster delivery of the wrong thing is not progress. It just gets you there sooner.

The first ninety days, in order:

1. Write the one sentence. What is measurably different, by when, owned by whom. If you cannot write it, do not start.
2. Cut the scope until phase one is genuinely useful on its own. Then cut it once more.
3. Free the people properly. Named, dedicated, backfilled. Not 20%.
4. Open the data. Profile it in week one and share the ugly numbers widely.
5. Agree the customisation rule before the first argument, not during it.
6. Put something real in front of five actual users inside three months.
7. Put the decommissioning date in the plan, with a budget.

None of this is clever, and that is the point. Transformations are not usually lost to a hard technical problem. They are lost to a series of reasonable decisions — take everything, keep the process, staff it part-time, skip the rehearsal, deal with the old system later — each of which made sense on the day it was made.

The organisations that deliver are not smarter. They just made the boring decisions early, while making them was still cheap.