The questions that quietly predict a difficult project (and what to look for instead)

Hopefully this is a helpful post to kick-off 2026, and prevents some difficult projects before they become difficult projects!

Most disaster clients don’t start out as disasters. They start out reasonable, curious, often well intentioned.

In my experience, the projects that go wrong rarely do so because of one big mistake. They unravel slowly, through small signals that show up early, usually in the questions clients ask and how they ask them. None of these questions are unreasonable. What matters is the posture behind them.

This isn’t about spotting bad clients. It’s about noticing early signs of misaligned ways of working, before they turn into frustration, scope creep, or work that feels harder than it needs to be.

1. “If we remove X, does the price go down?”

Why it’s fair: Of course it is. Budgets are real.

The red flag version (service mindset):

• They pre-decide what’s “optional”

• They optimise for price before understanding impact

• They treat the scope like a menu, not a system

This often turns into:

• Fragile outcomes

• “Why doesn’t this work as expected?”

• Blame drifting back to you

The healthier reframe (partnership mindset):
“How can we adjust the investment so this works for us right now?”

That question:

• Acknowledges constraints and expertise

• Invites trade-offs rather than cuts

• Keeps responsibility with the system, not individual line items

2. “How many hours will you work per day? When will I get updates?”

Why they’re fair: Visibility reduces anxiety.

The red flag version:

• Focus on time spent rather than outcomes

• Updates driven by reassurance, not progress

• An implied need to monitor rather than align

This often turns into:

• Micromanagement

• Performative updates

• Less deep work and slower progress

The healthier reframe:
“What check-in rhythm works best with your process?”

That framing:

• Respects how you work

• Shifts focus from hours to momentum

• Creates a shared cadence instead of a reporting obligation

3. “We’ll have a few people giving feedback”

Why it’s common: Work is collaborative. Opinions exist.

The red flag version:

• Multiple stakeholders

• Equal weight

• No clear decision owner

This often turns into:

• Circular feedback

• Design by committee

• You acting as mediator instead of expert

The non-negotiable:
There must be one person who gives the final yes or no.

Why this matters:

• Decisions stick

• Accountability is clear

• You are not responsible for defending every choice later

4. “Can you just try one more option?”

Why it sounds harmless: Iteration is normal.

The red flag version:

• No decision criteria

• Exploration without direction

• “We’ll know it when we see it” as a strategy (Spoiler: BAD strategy)

This often hides:

• Unclear goals

• Fear of committing

• The hope that more options will create clarity

The healthier reframe:
“What would make this the right direction to commit to?”

That question:

• Forces criteria into the open

• Turns taste into strategy

• Makes decisions possible

5. “We need this fast. It’s pretty simple.”

Why it sounds efficient: Speed feels decisive.

The red flag version:

• Thinking time is underestimated

• Complexity is deferred, not removed

• Urgency replaces clarity

This often turns into:

• Rushed decisions

• Missed dependencies

• Rework later

The healthier reframe:
“We have a tight timeline. What needs to be true for this to work well?”

That framing:

• Surfaces trade-offs early

• Aligns expectations

• Makes speed sustainable

6. “We’ll figure that out later”

Why it sounds flexible: Nobody wants rigidity.

The red flag version:

• No anchors

• No boundaries

• Decisions endlessly postponed

This often turns into:

• Scope creep

• Decision paralysis

• Frustration on both sides

The healthier reframe:
“What decisions do we need to lock now, and where can we stay flexible?”

That distinction:

• Creates momentum

• Protects scope

• Keeps flexibility intentional

None of these questions are wrong.

What matters is how responsibility is framed.

Disaster projects don’t usually fail because of bad intentions. They fail because thinking, ownership, and decision making are outsourced in the wrong places. Learning to spot that early is less about being picky and more about protecting the work, for you and for the client.