In transformation projects, there are two kinds of deadlines: those nobody commits to, and those that stay green until they collapse. Both cost the same. In both cases, what is missing is not the deadline, but honesty about it.

In transformation projects, there are two kinds of deadlines: those nobody commits to, and those that stay green until they collapse. Both cost the same. In both cases, what is missing is not the deadline, but honesty about it.
An example from outside manufacturing shows what the difference looks like.
Nine years late, and the world cheers
Tesla announced the new Roadster in 2017. Production in 2020, they said at the time. It was unveiled in Texas on 15 October 2026. Production from 2028.
Nine years late, and the audience cheers. This works because nobody relied on the original deadline. No supplier set up a production line for it; no customer made a production launch depend on it.
In a plant, things are different. Every deadline affects a line that has to keep running. That is why nobody cheers when transformation projects are delayed, and why it is worth understanding the pattern behind it.
Why nobody commits to a deadline in projects
The pattern begins long before the delay. It starts with no firm deadline being given. Go-live, start of production, handover: everything is "being agreed", everything is "dependent on". There are three reasons behind this.
No commitment, no broken commitment. If you do not give a deadline, you cannot miss one. This protects whoever is supposed to deliver, and it feels professional because it sounds cautious. In reality, it shifts the entire risk onto the client.
Dependencies as a permanent excuse. Every project has dependencies. They become a problem when, instead of being identified and scheduled, they are used as a reason not to commit at all. "Dependent on data migration" means nothing unless someone says when migration will be complete and who is responsible.
Amber means trouble. Where an amber status triggers questions about blame, nobody reports amber. The deadline stays green until it turns red. This is not malice, but the logical response to a culture in which honesty is punished.
In depth:
When a deadline is finally given, it often ends up like the Roadster: delayed many times over. Just without the applause.
What a delayed go-live actually costs
The visible costs of a delay appear in the project budget. The real costs appear elsewhere.
| Cost category | What happens | Where it shows up |
|---|---|---|
| Tied-up capacity | Key users, department heads and the project team remain tied up for months longer and are unavailable for day-to-day operations | In no project cost report, but in every department |
| Duplicate structures | Old and new systems, old and new processes continue to run in parallel | Licences, training, error correction |
| Accumulating problems | What the go-live was supposed to resolve is not resolved, but postponed. The list grows | In the next status report, as new risks |
| Loss of trust | The workforce experiences the third postponed deadline and no longer believes the fourth | In engagement with training, testing and cutover |
| Risk to the site's survival | At sites with thin margins, a delayed go-live turns from a project problem into a question of the site's future | In discussions with shareholders and banks |
We have seen sites where a delayed go-live was no longer a matter of lateness, but a question of survival. Not because of project costs, but because of everything below the first row of the table.
What Tesla got right
Before the stunt on 15 October, Elon Musk told the audience, in essence: success is not guaranteed. It will probably work. If not, we are standing far enough away.
Whatever you think of Tesla, this is a deadline with openly acknowledged risk. Not green. An honest amber, in front of thousands of people. The date was set, the risk was named, and so was the plan in case of failure.
That is exactly what most transformation projects lack. Not the deadline. Honesty about the deadline.
What an honest deadline looks like
A firm deadline has four parts, and most projects provide only the first, or none at all.
- The date. A specific day, not a quarter, not a range. "Q3" is not a deadline, but a negotiating position.
- The confidence level. How likely is the date to hold, and what does it depend on? "80 per cent, if the master data is cleaned up by the end of May" is a statement a client can work with. "We are confident" is not.
- Named conditions. Every dependency that could jeopardise the deadline gets an owner and a date of its own. Then "dependent on" is no longer evasion, but a plan.
- The early-warning rule. Agreed in advance: at what point is amber reported, and what happens then? Anyone reporting amber gets help, not questions about blame. This is the only way to report before things collapse rather than afterwards.
A deadline with all four parts can still slip. But it will not slip without warning, and it will not slip many times over.
Three questions for anyone who gives you a deadline
When commissioning external support, you can test commitment in the first conversation.
- Give me a date, and how certain is it? Anyone who evades the question has an intention, not a plan.
- What needs to happen by when for it to hold, and who is responsible? Anyone who simply says "the client" has already passed on the risk.
- When will I find out if it will not hold? If the answer is "at the next steering committee meeting", you will find out too late.
How we handle this
We give a deadline. We say how certain it is and what it depends on. And we take responsibility for meeting it, or explain early why we cannot. This is less comfortable than "being agreed", for both sides. But it is the only way a plant can plan its production line.
A deadline nobody commits to is not a plan. It is an excuse with a date.
When did someone last commit to a deadline in your most recent project, and what came of it?
Frequently asked questions
Why are go-live dates in transformation projects postponed so often?
Rarely because of technical problems. Usually because no firm deadline was given from the outset, dependencies serve as a permanent excuse, and an amber status has consequences. Where honesty about the deadline is punished, the status stays green until it turns red.
What does a postponed go-live really cost?
Project costs are the smaller part. More expensive are capacity tied up instead of supporting day-to-day operations, structures running in parallel, problems postponed rather than solved, and the workforce's loss of trust. At sites with thin margins, a delayed go-live can become a question of survival.
What makes a project deadline binding?
Four parts: a specific date, a stated confidence level with conditions, owners and dates for every dependency, and an early-warning rule agreed in advance. If any one is missing, the deadline is an intention, not a plan.
How can I tell whether a service provider really commits to a deadline?
By asking three questions in the first conversation: what date, and how certain? What needs to happen by when, and who is responsible? When will I find out if it will not hold? Anyone who evades any of these has already passed the risk on to you.
About SMART iNTERIM
SMART iNTERIM Management is a transformation partner for manufacturing: Operational Transformation, SAP and Enterprise Transformation, Program & Project Management, as well as Interim Management and Executive Search. We bring hands-on experience, not a detached perspective. Headquartered in Switzerland, with an office in Dubai.
