"Can't You Just Do It in 6 Months?" — Why Rushing IT Transformations Backfires Every Time

There's a meeting that happens in every organization. You know the one.

Someone presents a solid, well-thought-out IT roadmap. Three years. Phased approach. Dependencies mapped out. Risk mitigation built in. Realistic budget.

And then a senior leader leans forward and says: "That's great, but can we do it in six months?"

I've been in that meeting. Many times. On both sides of the table. And I can tell you exactly what happens next: either the IT person folds and says yes (and everyone pays for it later), or they push back and get labeled as "not commercial enough."

Neither outcome is good.

The Real Cost of "Just Get It Done"

Let me paint you a picture. You're running SAP, your ERP has been in place for a decade, and leadership decides it's time to move to something modern. Great — that's often the right call. But instead of planning a proper migration over 2–3 years, someone decides it needs to happen before the next fiscal year.

So the team scrambles. They skip the data cleanup. They don't map all the integrations properly. They underestimate the change management. They go live. And for the next eighteen months, half the company is working around broken processes while the other half is still using spreadsheets because they don't trust the new system.

You didn't save time. You moved the pain from "before go-live" to "after go-live" — where it's ten times more expensive to fix.

This isn't hypothetical. I've inherited these situations. They're brutal. And they're entirely preventable.

Why Leaders Push for Speed

I get it, by the way. I understand why business leaders want things fast. Markets move. Boards want results. Competitors aren't waiting. There's genuine pressure.

But here's what most leaders don't realize: a well-executed IT transformation actually delivers value during the journey, not just at the end.

A phased approach means quick wins in the first 3–6 months that demonstrate real impact. It means lower risk because you're not betting everything on a single big bang go-live. Your team actually learns and adapts, instead of drowning in change. And you can course-correct based on real data, not assumptions.

Speed isn't about doing everything at once. Speed is about doing the right things in the right order — and not having to redo them six months later.

The Foundation Analogy That Changed a CEO's Mind

I once explained it to a CEO like this: "You're building a house. You can skip the foundation and have walls up in two weeks. But the first storm blows it over, and now you're rebuilding from scratch — in the rain."

He got it. Not because it was a clever analogy, but because he'd seen it happen. His previous company had rushed an ERP migration and spent three years cleaning up the mess. Three years. The "fast" approach took longer than doing it right would have.

We built a three-year roadmap together. By month four, his finance team had better reporting than they'd had in a decade. By month eight, the sales team had a CRM that actually worked. By year two, the entire organization was running smoother than it ever had.

No drama. No emergency weekend deployments. No "we'll fix it in phase two" that never comes.

How to Push Back Without Getting Fired

If you're the IT leader in this situation, here's what works:

Speak their language. Don't talk about technical debt and architecture. Talk about risk, money, and competitive position. "If we rush this, here's what it costs when it breaks" lands harder than "the architecture won't support it."

Show early value. Build your roadmap so the first phase delivers something visible within 90 days. Leadership needs proof you're moving, not just planning.

Quantify the alternative. "We can do it in six months. Here's the risk profile and the likely cost of fixing what breaks. Or we can do it in eighteen months with this risk profile. Which do you prefer?" Give them a real choice, not a lecture.

Get an ally. Find the CFO or board member who's been burned by a rushed project before. They exist. They'll back you up.

The Bottom Line

Fast is good. Reckless is expensive.

Every IT transformation should have urgency built into it. But urgency and haste are different things. Urgency means prioritizing ruthlessly and executing with discipline. Haste means skipping steps and hoping for the best.

One builds lasting value. The other builds job security for consultants who clean up the mess.

At Galactus, we build IT roadmaps that balance speed with sustainability. If your leadership team is pushing for unrealistic timelines, we can help bridge that conversation.