ERP Go/No-Go Decision: Is Your Business Really Ready?

tom.hensler@inflective.com (Tom Hensler) — Tue, 13 Oct 2026 20:56:46 GMT

Why the most consequential decision in an enterprise transformation requires more than project status, checklists, and assurances.

The Moment of Truth

Every major ERP transformation eventually reaches a moment when years of planning, development, testing, and preparation converge into a single decision:

Go or No-Go?

For a mission-critical enterprise transformation, the consequences of getting that decision wrong can be enormous.

Yet organizations frequently approach this decision armed with project dashboards, completed deliverables, testing statistics, open-issue reports, and risk assessments.

All are important. None necessarily answers the question that matters most:

Will the organization actually be able to operate its business successfully after Go-Live?

I learned the importance of that distinction more than 30 years ago, during one of the most consequential implementations of my career.

A Cruise Line, a Hurricane, and an Unmovable Deadline

In the early 1990s, I was involved in leading a major systems transformation for one of the world's leading cruise lines.

The program involved replacing mission-critical applications that supported the company's ability to conduct its business. We were planning a Big Bang deployment—a direct cutover from the existing environment to the new one.

There was no comfortable transition period during which the old and new environments could operate in parallel.

The stakes were substantial.

It had been a long, difficult project. The team was exhausted, and we had overcome numerous obstacles.

At one point, IBM backed away from certain commitments involving computing capacity and growth. That forced us into extensive last-minute technical development, including detailed peer-to-peer machine-level work that had never been part of the original plan.

Then Hurricane Andrew struck South Florida.

We survived the disruption, but the scheduled cutover date did not change.

The commercial pressures were equally significant. Our contract was fixed-fee, with penalties for late delivery. The cruise line was approaching its busy season, during which a major systems cutover would be impractical.

Missing the deployment window could mean a lengthy delay and substantial additional costs.

Everyone had powerful reasons to want to proceed.

But wanting to go live and being ready to go live are two very different things.

How Would We Really Know?

We were managing the project using the disciplines you would expect: schedules, milestones, deliverables, issues, risks, testing results, and technical readiness reviews.

But given the magnitude of the decision, those measures did not seem sufficient.

The cruise line took an extraordinary step.

It rented a duplicate facility where the new systems could be installed and subjected to a realistic simulation of business operations. It also engaged an independent consulting firm to assess whether the environment was ready.

I remember being extremely nervous about that decision.

The consulting firm could reasonably be viewed as a competitor, potentially looking for an opportunity to establish a relationship with the client.

And I knew that no system of this complexity would perform flawlessly under every conceivable scenario.

I imagined an assessment involving hundreds of checklist items, test scenarios, and exceptions, followed by endless debates about which failures were important, which were not, and whether the remaining risks were acceptable.

But the consulting firm did something that changed how I would think about enterprise readiness for the rest of my career.

They framed their assessment around a deceptively simple question:

Can the organization perform a day's worth of business in a day?

That was brilliant.

Rather than evaluating technical performance in isolation, they established the context of the business outcome the technology was supposed to enable.

The question was not whether every component worked perfectly.

It was whether the environment could support the volume and complexity of business activity required to operate successfully.

"Do I Have a Problem or Don't I?"

I still remember the assessment readout.

My partner was at the duplicate facility with the assessment team. I was in Miami with the cruise line's CIO.

Go-Live was rapidly approaching, and anxiety was running high.

We joined a conference call with the consulting firm to hear its findings.

Although the firm had framed the assessment exceptionally well, the presentation began with an elaborate discussion of detailed technical results.

The consultants talked through observations, qualifications, and supporting information.

The CIO became increasingly frustrated.

Finally, he interrupted and demanded:

"Do I have a problem or don't I?"

In other words, could the system support a day's worth of business in a day—or couldn't it?

Fortunately, the answer was yes.

That moment has stayed with me for more than three decades.

The CIO did not need another lengthy presentation about everything the team had done.

He needed a clear answer to a business question, supported by enough evidence to make a consequential decision.

That experience gave me a principle I have used ever since:

A day's worth of business in a day.

The systems went live, and the solution proved remarkably durable. The underlying system remained in use for decades.

But the more enduring outcome for me was a different way of thinking about readiness.

From Technical Readiness to Business Readiness

Over the years, I began applying the principle far beyond technology.

After all, a system can perform perfectly while the business struggles to operate.

Consider the questions that must be answered before a major ERP deployment:

Technology: Can the systems, infrastructure, and integrations support required business volumes and performance?
Data: Is the information sufficiently complete, accurate, and accessible to support operations?
Processes: Can the organization execute its end-to-end business processes, including exceptions and nonstandard situations?
People: Do employees possess the knowledge, competencies, and capacity required to perform their responsibilities?
Business outcomes: Can the organization process orders, ship products, serve customers, manage cash, and close its books at acceptable levels?
Compliance and controls: Can the business satisfy its regulatory, financial, security, and internal control obligations?
Contingency: If something fails, can the organization continue operating while the problem is resolved?

These are not simply implementation activities to be completed.

They are conditions that must exist for the organization to operate successfully.

And they require evidence.

An Unexpected Lesson from Missile Engineering

Years later, while leading a global ERP transformation for a roughly $20 billion high-technology communications equipment manufacturer with defense operations, I had conversations with engineers who had worked on the Peacekeeper missile program.

We discussed how they approached readiness in an environment where the consequences of failure could be extraordinary.

They described the use of affirmative statements identifying conditions that needed to be true before a solution could be considered ready.

I found that concept fascinating.

Instead of beginning with a list of activities, begin with statements describing the conditions that must be achieved.

Then establish the evidence necessary to determine whether those statements are true.

The concept stayed with me.

It would become particularly important years later.

When the Stakes Reached $1 Million a Day

I was subsequently involved in another large, complex ERP transformation with a program expenditure rate approaching $1 million per day.

The organization faced an enormously consequential Go-Live decision.

I was asked to develop an approach that would establish readiness while ensuring extensive engagement and ownership by the business.

Traditional project management reporting would not be enough.

We needed a way to connect implementation accomplishments to the conditions required for business success—and to engage the executives and managers who would actually be accountable for those outcomes.

I returned to two ideas that had stayed with me.

The first was the cruise line's fundamental question: Could the organization perform a day's worth of business in a day?

The second was the engineers' approach to describing readiness through affirmative statements.

Together, these concepts became the foundation of what we now call Assertions.

An Assertion describes something important that must be true for the transformation to succeed.

For example:

"The organization is capable of processing its anticipated daily order volume accurately and within required service levels."

That is fundamentally different from saying:

"Order management testing is complete."

One describes an accomplished activity.

The other describes a required operational condition.

We refer to these required conditions as Future Truths.

Readiness Must Be Owned by the Business

The real power of Assertions comes from how they are evaluated.

Each important condition is entrusted to stakeholders who have responsibility for, or meaningful knowledge of, the corresponding business outcome.

Those stakeholders evaluate whether the Assertion is true, partially true, or not true, based on available evidence.

They identify gaps, uncertainties, and required actions.

The objective is not to create another checklist.

It is to establish a disciplined process through which the organization develops justified confidence in its ability to operate successfully.

This also changes the nature of the Go/No-Go discussion.

Instead of asking:

"Have we completed the planned testing?"

Executives can ask:

"Have the accountable business stakeholders demonstrated that the required operating capabilities are ready?"

Instead of asking:

"How many critical issues remain open?"

They can ask:

"Which required business conditions remain unproven, and what are the consequences of proceeding?"

And instead of relying on a generalized green dashboard, executives can examine the evidence supporting readiness, the remaining uncertainties, and the business risks they are being asked to accept.

The Go/No-Go Decision Is a Business Decision

A systems integrator can recommend that the technology is ready.

A program manager can report that milestones have been achieved.

A testing leader can explain that acceptance criteria have been satisfied.

All of those perspectives are essential.

But the ultimate question is whether the enterprise can operate successfully following deployment.

That decision belongs to the business leaders accountable for the consequences.

They need candid information, objective evidence, and a clear understanding of what remains uncertain.

They also need the willingness to hear answers they may not like.

When a major transformation approaches Go-Live, schedule pressures, financial commitments, executive expectations, and organizational fatigue can create an overwhelming desire to proceed.

That is precisely when disciplined readiness assurance becomes most important.

A Go/No-Go meeting should not be a ceremony to ratify a decision that has already been made.

It should be the culmination of a process that has established what must be true, determined whether those conditions have been achieved, and identified the risks that remain.

From Experience to Transformation Certainty

Those experiences ultimately contributed to the development of Inflective's Assert™ Transformation Certainty approach.

The underlying idea remains straightforward.

Define the Future Truths required for success.

Translate them into Assertions that accountable stakeholders can evaluate.

Establish evidence, identify readiness deficits, and take action before those deficits become operational failures.

The objective is not absolute certainty. No complex transformation can eliminate every risk.

The objective is Rational Certainty—a defensible, evidence-based level of confidence that the organization is prepared to operate.

And that confidence should be developed throughout the transformation, not manufactured in the final weeks before Go-Live.

The Question That Still Matters

More than 30 years after that anxious conference call in Miami, I still believe the cruise line CIO asked exactly the right question.

"Do I have a problem or don't I?"

Today, I would expand that question.

Can our technology, data, processes, people, controls, and supporting organizations collectively enable us to perform a day's worth of business in a day?

Do the people accountable for operating the business believe we are ready?

And, most importantly, what evidence supports their confidence?

Those are the questions executives should be asking before authorizing a consequential ERP deployment.

Because the real measure of a successful transformation is not whether the new system goes live on schedule.

It is whether the business can operate successfully the next morning—and every day thereafter.

About Inflective

Inflective helps organizations lead complex enterprise transformations and establish greater certainty about business outcomes. Its Assert™ Transformation Certainty approach uses Future Truths, evidence-based Assertions, and accountable stakeholder engagement to identify and resolve readiness deficits before they become operational problems.

Facing a consequential Go/No-Go decision?

Inflective's Go-Live Certainty Assessment helps executive teams prepare for and understand whether their organizations are genuinely ready to operate—not simply whether the implementation plan is complete.

Contact Inflective to discuss your transformation's readiness.

Inflective Insights