“We’ll Handle That in a Future Phase” Usually Means It’s Already a Problem

In NetSuite projects, there’s always a “future phase” list.

On paper, that’s normal.

You can’t solve everything at once.
You have timelines, budgets, and competing priorities.

But in practice, that list is where unresolved design problems go to hide.

What “Future Phase” Actually Means

When something gets pushed, it’s rarely random.

It’s usually because:

• The current design doesn’t support it cleanly
• It introduces complexity no one planned for
• It exposes a flaw in the original approach
• No one wants to reopen decisions that were already “final”

So instead of addressing it directly, it gets deferred.

When It Is Legitimate

Not everything pushed to a future phase is wrong.

Sometimes:

• Scope is real and needs to be controlled
• Timelines force prioritization
• You’re intentionally separating phases to reduce risk

That’s normal.

But the difference is intentional vs avoidant.

If something is deferred with:

• Clear reasoning
• Defined impact
• A real plan to revisit

That’s planning.

If it’s vague, open-ended, and keeps slipping…

That’s avoidance.

Why Deferring Can Make It Worse

Deferring something doesn’t freeze it in time.

The system keeps evolving around it.

While that item sits in the backlog:

• New scripts get added
• Workflows get layered in
• Integrations start depending on current behavior

Now that “small issue” is no longer isolated.

It’s entangled.

What Happens Later

By the time someone revisits it:

• The original context is gone
• Multiple processes depend on the current behavior
• Fixing it creates ripple effects across the system

So instead of:

“Let’s fix this properly”

It becomes:

“Let’s work around it again”

And now you’ve compounded the problem.

A Pattern You’ll See Often

This shows up in places like:

• Approval logic that doesn’t quite handle real-world scenarios
• Data models that don’t reflect how the business actually operates
• Integrations that assume perfect sequencing and clean inputs

At go-live:

“We’ll handle that later”

Six months later:

• Users have built manual processes around it
• Reports are adjusted to compensate
• Scripts are added to patch symptoms

Now fixing it means undoing multiple layers of adaptation.

The Line Most Teams Miss

Not everything needs to be solved immediately.

But you need to separate what you’re deferring:

Safe to Defer

• UI improvements
• Non-critical automation
• Performance tuning

Dangerous to Defer

• Data model gaps
• Core process logic
• Anything affecting transaction integrity

If it touches how data is created, stored, or processed…

It’s not a “future phase” item.
It’s a foundation problem.

The Real Cost

Deferring foundational issues:

• Increases long-term complexity
• Raises the cost of change exponentially
• Creates hidden dependencies

And most importantly:

It trains the system to operate around a flaw.

Bottom Line

“Future phase” isn’t just planning.

It’s a decision.

You’re either:

• Deferring something safe

or

• Accepting a problem that will get harder to fix every day

Most teams don’t make that distinction.

And that’s where “future phase” stops being strategy
and starts becoming debt.