Questions I Ask Before Starting Any Project

The quality of an engagement is determined before work begins.

I’ve learned this the hard way. Projects that start with vague mandates, unclear ownership, or missing constraints almost always run into trouble. Not because the work is too hard, but because the setup was wrong.

Now I ask questions upfront. A lot of them. The answers determine whether we proceed and how.

Why Questions Matter More Than Answers

Most project problems aren’t execution problems. They’re definition problems.

“Build us a CRM integration” sounds clear. But what exactly should integrate? With which system? What data needs to flow where? Who decides when records conflict? What happens when the integration fails? Who maintains it afterward?

Without answers to these questions, the project scope is an illusion. The request sounds specific, but the work required is undefined.

Questions surface the gaps. They turn implicit assumptions into explicit decisions. They reveal complexity that was hiding behind simple language.

This takes time. Clients sometimes get impatient with questions. They want to start. But skipping the questions doesn’t save time — it shifts the problem-solving to a later, more expensive phase.

The Ownership Questions

Who wants this done, and why?

This reveals motivation. Is this a top priority or a nice-to-have? Is there genuine urgency or is this on someone’s wish list? The level of commitment affects everything downstream.

Who will own the result?

Systems need owners. Someone has to maintain them, update them when the business changes, handle exceptions that arise. If ownership is unclear before we start, it will be unclear after we finish. And unclear ownership means decay.

Who needs to sign off on decisions?

Decision-making processes matter. If every choice requires committee approval, the timeline stretches. If one person can decide, we move faster. Knowing the approval structure upfront prevents surprises.

Who will be affected by this change?

New systems change how people work. Some will embrace it; others will resist. Understanding who’s affected helps anticipate friction and plan for adoption.

The Problem Questions

What’s actually broken?

“We need to improve our process” isn’t a problem statement. What specifically isn’t working? Where does it hurt? What’s the cost of the current situation?

The more concrete the problem, the more focused the solution. Vague problems lead to vague projects.

How long has this been a problem?

Recent problems might have quick fixes. Problems that have persisted for years are probably structural. The duration tells me something about the difficulty.

What have you tried already?

Most problems aren’t new. There have been previous attempts to fix them. Understanding what was tried and why it failed prevents repeating the same mistakes.

What happens if we don’t fix this?

Some problems are urgent. Others are chronic but stable. Knowing the consequences of inaction helps prioritize and set appropriate timelines.

The Constraint Questions

What’s the budget?

Not having a budget isn’t a strategy — it’s a lack of clarity. Every project has resource constraints. Knowing them upfront prevents over-building or under-building.

What’s the timeline?

Is there a deadline? A launch date? An external dependency? Or is the timeline flexible? Constraints shape solutions. A project with six weeks looks different from a project with six months.

What can’t change?

Every project has constraints: existing systems that must remain, processes that can’t be modified, vendors that must be used. Knowing the non-negotiables early prevents wasted effort.

What’s out of scope?

Scope creep is the enemy of completion. Defining what’s not included is as important as defining what is. I’d rather argue about scope before starting than argue about it mid-project.

The Success Questions

What does success look like?

“It should work better” isn’t a success metric. What specifically would be different? What would you measure? How would you know we succeeded?

Concrete success criteria create accountability. Abstract goals create ambiguity.

How will we know if this fails?

Not every project succeeds. Defining failure criteria upfront creates an honest conversation. It also creates exit criteria — points where we reassess rather than continue into a bad outcome.

What would make this not worth doing?

There are conditions that would make the project a bad idea. Regulatory changes. Business pivots. Competitive shifts. Knowing what would change the calculus helps make the go/no-go decision.

The Process Questions

How do decisions get made here?

Organizations decide things differently. Some need consensus; others defer to authority. Some move fast; others deliberate. Understanding the decision culture helps navigate the project.

How do you handle change requests?

Projects evolve. Scope changes. New information emerges. How does the organization handle mid-project adjustments? Is there a change process, or does everything become urgent?

What does communication look like?

Weekly updates? Daily standups? Ad-hoc check-ins? Email-only? The communication cadence needs to match the project and the culture.

What I Listen For

The answers matter, but so does how they’re given.

Confidence or uncertainty? If the client can answer quickly and clearly, the project has been thought through. If answers require long discussions, the project is still forming.

Alignment or contradiction? When different stakeholders give different answers, there’s internal conflict. Better to surface this early than discover it mid-project.

Specificity or vagueness? Concrete answers suggest clear thinking. Abstract answers suggest unclear needs. Vagueness isn’t bad, but it signals where more discovery is needed.

Ownership or diffusion? When someone says “I own this,” the project has a champion. When everyone says “we all do,” nobody does.

When I Don’t Start

Sometimes the answers reveal that the project shouldn’t happen. At least not yet.

If ownership is unclear, I don’t start. The system will be orphaned.

If the problem is undefined, I don’t start. We’ll build the wrong thing.

If the constraints are impossible, I don’t start. The project is set up to fail.

If there’s internal disagreement about goals, I don’t start. The project will become a proxy war.

These aren’t pleasant conversations. But they’re better than the conversation that happens when a doomed project fails.

The Investment in Clarity

Asking questions takes time. It can feel like overhead before the “real work” begins.

But this is the real work. The questions reveal what needs to be built. They surface risks before they become problems. They align expectations before they diverge.

Projects that skip this phase don’t save time. They just defer the confusion to a later, more expensive moment.

Better questions upfront. Fewer problems later.

---

Related

• Article: When a Consultant Is the Wrong Choice — Understanding what kind of help you actually need
• Diagnostic Form: Start Here — Begin the conversation about what your business needs