"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 IT roadmap. Three years. Phased approach. Dependencies mapped. 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 more times than I'd like to admit. 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" or "too cautious."

Both outcomes are terrible. But the first one is worse, because it sets a ticking time bomb with a twelve-month fuse.

The Real Cost of "Just Get It Done"

Let me paint you a picture. You're running an ERP that's been in place for a decade. Maybe it's a legacy SAP system, maybe it's a patchwork of tools held together by Excel and good intentions. Leadership decides it's time to modernize. Great — that's usually the right call.

But instead of planning a proper migration over two to three years, someone in the room decides it needs to happen before summer. Before the next fiscal year. Before some arbitrary deadline that has nothing to do with technical reality.

So the team scrambles. They skip the data cleanup because there's no time. They don't map all the integrations because nobody fully understands them anyway. They underestimate change management because "people will figure it out." They go live on a Friday evening and spend the weekend firefighting.

And for the next eighteen months, half the company is working around broken processes while the other half quietly goes back to their 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 and infinitely harder to fix because now everyone's lost faith in the project.

This isn't hypothetical. I've inherited these situations. Cleaning them up is brutal, expensive, and entirely preventable.

Why Leaders Push for Speed (And Why I Get It)

I understand the pressure. I really do. Markets move fast. Boards want progress. Competitors aren't waiting. There's a genuine urgency to modernize, and the frustration when IT says "this will take three years" is real.

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

A phased approach means quick wins in the first three to six months that demonstrate real, visible impact. It means lower risk because you're not betting the entire business on a single big bang weekend. Your teams actually learn the new systems and adapt their processes, instead of drowning in change they didn't ask for. And critically, you can course-correct based on real data from the field — not assumptions made in a boardroom six months earlier.

Speed isn't about doing everything at once. Speed is about doing the right things in the right order, and not having to redo half of it six months later because someone skipped the foundation.

The Conversation That Usually Changes Minds

When I sit down with a CEO or COO who's pushing for an aggressive timeline, I don't argue about architecture or technical debt. That's a losing battle — those words don't mean anything to them, and they shouldn't have to.

Instead, I put two scenarios on the table.

Scenario A: We compress everything into six months. Here's the budget. Here's the risk profile. Here's what historically breaks when you do this — and here's what it costs to fix. I'll be specific: think 1.5 to 2x the original budget spent on remediation alone, plus twelve months of reduced productivity across your teams.

Scenario B: We do it in eighteen to twenty-four months, phased. Here's the budget — often lower in total. Here's what you'll see working in the first ninety days. Here's the risk profile. And here's the timeline to full value.

Then I let them choose. Not a lecture. A real, informed decision with the numbers in front of them.

Nine times out of ten, they pick B. Not because I convinced them to slow down, but because they realized that "fast" and "rushed" aren't the same thing.

If You're the IT Leader in This Situation

A few things that actually work when you're getting pressure from above:

Talk about money and risk, not technology. "If we rush this, here's what it costs when it breaks" lands infinitely harder than "the architecture won't support it." The first one is a business conversation. The second one sounds like you're protecting your turf.

Build your roadmap so the first phase delivers something visible within ninety days. Leadership needs proof you're executing, not just planning. If your first deliverable is in month nine, you've already lost the room.

Find the person in leadership who's been burned by a rushed project before. They exist in every organization. They've lived through the eighteen-month cleanup and they still have the scars. They'll back you up — often more forcefully than you expect.

And if none of that works? Document your concerns clearly and in writing. Not as a political move, but as a professional one. When things go sideways — and they will — you want the record to show that the risks were flagged and the decision was made above your pay grade.

The Bottom Line

Urgency is good. Every IT transformation needs it. Without urgency, projects drift, budgets inflate, and stakeholders lose interest.

But urgency and haste are fundamentally different things. Urgency means prioritizing ruthlessly and executing with discipline. Haste means skipping steps and hoping nothing breaks.

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

Don't be the organization that learns this lesson the expensive way.

At Galactus, we help organizations build IT roadmaps that balance speed with sustainability. If your leadership team is pushing for timelines that don't add up — or if you're the one pushing and want an honest second opinion — let's have a conversation.