What Is a Project Reset? And Why It Isn't Re-baselining
What a project reset is, and isn't
There's a moment in most troubled projects when a sponsor stops asking "how do we hit the date?" and starts asking "is this still the right plan?" It usually comes quietly: after one re-plan too many, a resignation, a restructure, or a steering committee where everyone agreed, and nothing moved.
That's the moment a project reset is for. It's also the moment when the two most common responses, pushing harder or re-planning the dates, tend to make things worse.
The short answer
A project reset is a deliberate step back, taken with the people who can make the decisions, to establish what's true now, whether the outcome still matters, and what path forward is credible with the decisions, people and capacity you actually have.
It's not a return to the original plan, and it's not a rescue. Sometimes the right answer is to keep going with a few changes. Sometimes it's a different scope, a different sequence or more time. Occasionally, it's to stop. A good reset makes that choice visible and owned, instead of letting it be made by default.
What a reset isn't
It isn't re-baselining
Moving the dates is the most common response to a drifting project, and it's the one that hides the most. The Victorian Auditor-General saw this in a 2016 review of government ICT projects: "Once time lines are re-baselined, the project status turns from 'delayed' (red) to 'on track' (green)."
A re-baseline changes the plan. A reset asks whether the plan was ever executable, and what has to change for the next one to be.
It isn't a rescue
Rescue language assumes the project has failed and someone has to come in and save it. Most projects that need a reset haven't failed. They're drifting: the same actions carry over, decisions wait for one more workshop, and the people closest to the work have started saying things in the corridor they don't say in the meeting.
Treating that as a rescue tends to put the focus on the vendor, the project manager or the tool. In my experience, the answer usually sits with the leadership team instead: in decisions nobody has made, trade-offs nobody has owned, or capacity nobody has been honest about.
It isn't going back to the original plan
The original plan was built on what people knew at the time, and on the capacity they hoped to have. Both have usually changed. Asking a team to get "back on track" often means asking them to deliver a plan the business can no longer support.
A reset starts from what's true now, not from what was promised then.
What a reset involves
At 6R, a Project Delivery Reset runs in three stages.
1. Before: we establish what's true
Before anyone is in a room, we talk to the people involved one by one: the sponsor, the project manager, the business leads, and the vendor. We look at what has actually been delivered and decided, compare the original plan with the current reality, and find out where different people believe the project stands.
That last part is often the most revealing. Research on troubled IT projects has long found that turnarounds tend to be triggered by someone with enough distance to see the whole picture. Keil and Robey's 1999 study found de-escalation "was triggered by actors such as senior managers, internal auditors, or external consultants".
More recently, a 2024 working paper from the Australian National University found that when project reviews were made more independent, the projects were rated as markedly less successful than they had been. That isn't because the projects got worse. It's because the picture got truer.
2. On the day: decide and rebuild together
Then we bring the people who can make trade-offs into one room. We look at the project through three lenses, Alignment, Action, and Accountability, and test the plan against the organisation's real capacity, including business-as-usual and everything else competing for the same people.
The point of the day is decisions:
What matters most?
What waits?
What stops?
Who owns what?
What does the timeline look like when it's built on reality?
Where we can, the project's core documents are updated in the room, so people leave with something they built rather than something they were handed.
A 2004 study of experienced IT consultants by Dexter and Iacovou named "developing a recovery plan, refining the scope of the troubled project, and re-evaluating the leadership of the project team" as the most important actions in turning a troubled project around. A good reset day covers all three, with the people who have to live with the answers.
3. Afterwards: confirm it's holding
A reset that feels great on the day and fades by the next steering committee hasn't worked. So afterwards, we follow up with the people who took part, one by one:
Does the project genuinely feel reset?
Does everyone know what's expected of them and by when?
What's still unresolved?
This stage matters more than it looks. When the Australian National Audit Office reviewed the Commonwealth's Gateway review process, it found that participation "does not guarantee success in meeting specified project objectives", and that in 106 cases where an earlier review existed, 72% of the time its recommendations had "only been partially implemented". Reviews can name the problem. The work only changes if the decisions are owned and followed through.
What one reset day surfaced
The most recent reset day I ran was prompted by an internal restructure that had landed on the project team. Nothing had visibly failed. The sponsor simply wanted to know where the project really stood before the change rippled any further.
The conversations beforehand showed people describing the project quite differently, depending on where they sat. On the day, two things surfaced that no status report had shown. When we asked what the most important project was this quarter, the CEO said this one was critical. The COO said it wasn't in their top three. And once the plan was tested against the capacity the team actually had after the restructure, it was clear the project needed an extra month.
Neither finding was dramatic. Both had been sitting under the surface for a while. And both are far easier to resolve around a table than in testing, at cutover, or a month after go-live.
Keep going, change course or stop
Every reset ends with a decision, and all three outcomes are legitimate.
Outcome | When it's the right call | What it looks like afterwards |
|---|---|---|
Keep going | The outcome still matters and the plan is broadly sound, but a few decisions, owners or dates need resetting. | The same project with a credible timeline, a decision log and clear owners. |
Change course | The outcome still matters, but the scope, sequence, resourcing or vendor arrangement no longer fits. | A re-scoped or re-sequenced project the business can actually absorb. |
Stop or pause | The outcome no longer matters enough, or the business can't absorb it right now. | A deliberate decision, made early, instead of a slow drift that costs more later. |
The stakes are real. In a study of 1,471 IT projects, Flyvbjerg and Budzier found that "one in six" was a "Black Swan", with "a cost overrun of 200%, on average, and a schedule overrun of almost 70%". A reset won't guarantee you stay out of that tail. It does make sure that if you're drifting towards it, someone has noticed and decided what to do.
When a reset is the right move - or not
A reset is worth considering when several of these are true:
The same issues stay open while the dates hold and the reasons for missing them keep changing.
Leaders describe the purpose or priority of the project differently.
Something has changed underneath the project: a restructure, a new sponsor, a lost key person or a shift in strategy.
The status report and the corridor conversations tell different stories.
It isn't the right move when the project is simply hard. If the problem has a name, an owner and a plan, and bad news arrives early enough to act on, you're dealing with normal pressure. That needs support and protection, not a reset.
And a reset doesn't have to lead anywhere else. Sometimes the best outcome is a leadership team that leaves the room able to carry on without outside help.
Common questions
1. What is a project reset?
A deliberate step back, taken with the decision-makers, to establish what's true now, whether the outcome still matters, and what path forward is credible with the capacity actually available. It can end in keeping going, changing course or stopping.
2. Is a project reset the same as re-baselining?
No. Re-baselining moves the dates and can turn a red status green without anything else changing. A reset asks whether the plan was executable in the first place, and changes the decisions, scope, sequence or capacity behind it.
3. Do we have to go back to the original plan?
Not necessarily. The original plan reflected what people knew and hoped at the time. A reset builds the path forward from what's true now.
4. How do I know if my project needs a reset or just more support?
If several warning signs have persisted for weeks across alignment, action and accountability, it's worth a reset. If the strain has a clear cause, an owner and a date when it will ease, it's normal pressure.
Not sure where your project sits?
That's why we built The Project Undercurrent: 12 statements, about five minutes, and a result that shows which undercurrent is running in your project and where to look first.
If you'd rather talk it through, you can read more about a Project Delivery Reset or book a 25-minute call with me.
Retail improvement, made practical.
Leadership thinking that drives change.
Sign up to receive new articles and strategic guidance.
