Most transformations don’t fail because of bad technology or bad teams. They fail because the conditions for success were never set up. By the time a program is visibly in trouble, the structural problems have usually been there since the beginning. They were just easier to ignore when momentum was fresh.
The first 30 days of a new transformation, or the first 30 days after a leadership change on an existing one, are where the trajectory gets set. Not in the business case. Not at the kickoff. In the early decisions that most leaders either skip or delegate.
Here are five moves that consistently separate programs that stabilise from programs that drift.
1. Name what success looks like in plain language
This sounds obvious. It is not.
Most programs launch with objectives that are technically correct and practically useless. “Deliver a modern platform that enables digital-first customer engagement” tells you nothing about what decision you would make differently at month six versus month twelve. It gives nobody a basis for saying “we are on track” or “we are not.”
In the first 30 days, the sponsor needs to articulate success in terms that a non-technical executive could evaluate. What business outcome changes? By when? How will we know? If the answers require a glossary, they are not clear enough.
This is not about dumbing things down. It is about creating a shared reference point that survives the inevitable drift of priorities, personnel, and political attention.
2. Clarify who can make which decisions and at what cost threshold
Decision authority is the single most underrated factor in transformation performance. When it is clear, programs move. When it is not, they stall while people escalate, second-guess, or wait for permission that never comes.
The pattern is predictable. A steering committee is established. Terms of reference are written. And then in practice, decisions get re-litigated across multiple forums because nobody is confident they have the authority to commit. Teams learn to hedge. Delivery slows. The program develops a reputation for being “complex” when the actual problem is structural ambiguity.
In the first 30 days, get this written down. Who can approve scope changes? At what value? Who can commit resources? Who resolves disagreements between workstreams? This does not need to be a 40-page RACI. A single page that people actually use beats a governance framework that sits on SharePoint.
3. Find out what is actually true before you commit to the plan
Every transformation inherits assumptions. Timelines from the business case. Cost estimates from the vendor. Resource plans based on who was available when the plan was written, not who is available now.
Some of those assumptions will be wrong. The question is whether you find out now or in six months.
This is where leadership discipline matters. It is tempting to treat the first 30 days as a period of optimism and forward motion. The plan exists. The team is assembled. Momentum feels good. The last thing anyone wants is someone asking difficult questions about whether the baseline is realistic.
But the cost of an unrealistic baseline does not reduce because you ignore it. It compounds. Programs that stabilise early are the ones where someone had the nerve to pressure-test the plan before it became politically impossible to change.
4. Make reporting about decisions, not status
The default reporting rhythm on most programs is a weekly status update. Green, amber, red across workstreams. A handful of risks with mitigations. Some milestones. It satisfies the governance requirement without actually telling anyone what is happening.
This is how watermelon projects happen. Everything looks green on the outside until someone cuts it open and finds red.
In the first 30 days, set a different expectation. Reporting should answer one question: what decision does leadership need to make this week? If the answer is none, the report should say that in a sentence, not dress it up in 15 slides. If the answer is “we need to de-scope workstream three or the timeline moves,” then that should be on the first page, not buried in an appendix.
This is not about creating a culture of bad news. It is about creating a system where information travels fast enough to be useful. The speed at which truth moves from the people who know it to the people who can act on it determines whether problems get solved or compounded.
5. Protect the team from organisational noise
This one is rarely discussed but consistently present in every program that stabilises quickly.
Transformations exist inside organisations. Those organisations have competing priorities, political dynamics, restructures, budget cycles, and dozens of other demands on the same people. The team delivering the transformation is not working in a vacuum. They are being pulled in multiple directions by people who all believe their request is the most important.
The leadership move is to create a boundary. Not rigidly. Not arrogantly. But clearly enough that the team can focus on delivery without being constantly destabilised by requests, reviews, and reporting obligations that serve the organisation’s comfort rather than the program’s progress.
This means the sponsor actively manages upward and sideways. It means saying no to the third governance forum that wants a monthly update. It means pushing back when another initiative tries to share resources without adjusting timelines. It means treating the team’s attention as a finite resource, because it is.
These are not heroic moves, but they will stabilise a transformation
Nothing on this list requires exceptional talent or visionary leadership. It requires discipline, specificity, and a willingness to do the unglamorous structural work in the first 30 days rather than assuming it will sort itself out.
Programs that stabilise early almost always have a leader who understood that the conditions for success are not inherited from the business case. They are built deliberately, one decision at a time, before the pressure arrives.
No responses yet