A few years ago, I was part of a NetSuite implementation for a company doing around $4 million in revenue.

Leadership had signed off on the project with a clear expectation: six months, new system, done. What nobody had mapped out was what six months actually required from the people inside the building.

There were four of us carrying most of the work internally, and three of them had their full-time job that didn’t pause for the implementation. While the implementation partner handled their side, we were scrubbing years of data, validating transactions, testing workflows, and figuring out how transaction feeds from Amazon and Shopify would flow into a system none of us had used before.

On top of that, I think we pushed the implementation partner harder than they had ever been pushed because we were putting in hundreds of hours on top of our regular responsibilities. We needed them to hold up their end of the bargain.

Eventually, we got there. The implementation was successful. The company moved from Intuit QuickBooks into NetSuite, and the business was better for it.

That project taught me something I’ve carried into every implementation conversation since. A timeline tells you when. It doesn’t tell you what it actually costs to get there.

The Timeline Only Tells Half the Story

A leadership team approves the budget, an implementation partner presents a project plan, and everyone aligns around a target go-live date. On paper, it all seems straightforward.

What gets overlooked is the amount of work required between kickoff and go-live. Data has to be cleaned. Processes have to be redesigned. Systems have to be tested. Employees have to learn new ways of working while still keeping the business running.

The calendar says 6 months. That’s accurate. What it doesn’t capture is that your team is living those 180 days while simultaneously doing everything they were already responsible for before the project started.

That doesn’t mean the timeline is wrong. It simply means the timeline only tells part of the story. The calendar tells you how long the project should take, but it doesn’t tell you what it will take to get there.

Why Some Implementations Move Faster Than Others

I’ve seen organizations complete major transformations in surprisingly short periods of time, and I’ve seen others drag on for years.

The difference isn’t the software or implementation partner; it’s usually the approach.

Looking back on the NetSuite implementation, there were a few things working in our favor. There was no ambiguity about who owned what. Everyone knew what they were responsible for, what deadlines they owned, and what would happen if something slipped. There wasn’t confusion about who was doing what or who was making decisions.

It sounds simple, but it isn’t. Most implementations fall apart because accountability was assumed instead of assigned.

Project plans aren’t perfect, but they exist because every missed task creates a problem for the next one. One delayed decision can impact testing. Delayed testing can impact training. What starts as one small slip turns into a timeline nobody can defend, and a team that’s running out of patience.

That’s not a software problem. That’s a people and process problem, and it shows up the same way every time.

I’m not suggesting that working until midnight should be the standard. It shouldn’t. What I am saying is that successful transformations require commitment, and there are periods where the workload is simply higher than normal.

The organizations that tend to move more quickly define ownership, stay disciplined around execution, and build teams that are prepared for the effort required to get across the finish line.

Transformation Is More Expensive Than the Software

When companies scope out an implementation, they’re usually pretty thorough about the external costs. Licensing, consulting fees, and training hours. That budget is visible. It gets scrutinized.

What rarely gets budgeted is the internal cost.

The implementation partner doesn’t know your business the way your team does. They can guide decisions, but they cannot make every call on behalf of the people who will live in this system for the next decade. At some point, your people have to do the work. They have to review, validate, test, and adapt. The question is whether leadership has actually accounted for what that takes.

Most of the time they haven’t.

That’s how you end up with a project that hits every invoice milestone exactly as planned and still feels like it cost twice what anyone expected. The external budget was right. The internal cost was invisible until it wasn’t.

Here’s what I wish more leadership teams understood before a kickoff meeting: the most important question isn’t whether the timeline is realistic. It’s whether the organization has the bandwidth, the alignment, and the honest commitment to carry the weight of actually getting there.

Signing the contract is the easy part.

The Questions Nobody Asks Before Kickoff

It’s obvious that software implementations are hard. Most leaders already know that, but the organizations that navigate transformation well are the ones that ask the hard questions before the kickoff meeting ever happens.

• Do we know who owns each phase of this project?

• Do the people responsible for executing this have the capacity to take it on, or are we just hoping they’ll absorb it?

• If something gets delayed, do we know what it’s going to cost us downstream?

• Does leadership understand what they’re actually asking of the team?

Nobody puts these questions fully in a proposal, but when they are addressed upfront, they’re the difference between a transformation that delivers and one that technically launches while quietly failing to stick.

The implementation is just the moment that makes it obvious whether the organization was actually ready.

Before you start your next implementation, don’t just ask whether the timeline is realistic. Ask whether the organization has the bandwidth, alignment, and commitment to support it.

If you’re in the middle of an implementation and it feels like things are starting to go off the rails, send me a message. I’m always happy to talk through it.