Before You Hire a Consultant, Ask These Questions

Start with the problem, not the proposal

When a business begins looking for outside help, it is natural to focus on credentials, deliverables, timelines, and price. Those things matter, but they are downstream of a more important question: does the consultant understand what you are actually trying to improve?

A polished proposal can still solve the wrong problem. Before discussing a solution in detail, I want to hear how the consultant describes the situation in their own words. If they cannot explain the business problem clearly, it is difficult to have confidence in the recommendation that follows.

• How do you understand the problem we are trying to solve?
• What assumptions are you making right now?
• What would you want to learn before recommending a solution?

1. What happens during discovery?

Discovery is where a consultant earns the right to make recommendations. Depending on the engagement, that may include interviews, data review, workflow mapping, customer feedback, system review, analytics, or direct observation of how the work happens today.

I would be cautious when someone arrives with a predetermined answer before understanding the environment. Experience should create better questions, not eliminate the need to ask them.

• Who will you need to speak with?
• What information or access will you need?
• How will you separate symptoms from root causes?

2. How will we define success?

The phrase 'successful project' means very little until both sides define it. A website redesign could be judged by launch date, conversion rate, usability, lead quality, operating efficiency, or all of the above. A technology implementation could technically go live while creating more work for the people using it.

Ask how the consultant intends to measure progress and outcomes. The right measures do not always need to be complicated, but they should connect the work to the reason the project exists.

3. What is included—and what is not?

Good scope is not just a list of deliverables. It should explain boundaries, dependencies, responsibilities, assumptions, and what happens when the work changes.

Ambiguity is normal at the beginning of many projects. Pretending otherwise usually creates friction later. I prefer a scope that is explicit about what is known, what still needs to be discovered, and how new information will be handled.

• What are the concrete deliverables?
• What is specifically outside the engagement?
• Which decisions or materials must come from our team?
• How will scope changes be evaluated and approved?

4. Who owns which decisions?

Projects slow down quickly when everyone is participating but nobody is clearly accountable. Ask who owns day-to-day communication, who can approve changes, who provides subject-matter input, and who makes the final decision when there are competing priorities.

The consultant should also be clear about their own role. Are they advising, executing, managing vendors, leading the project, or some combination of those responsibilities?

5. How do you communicate when something is not going well?

Almost every meaningful project encounters surprises. The useful question is not whether issues will occur; it is how they will be surfaced and handled.

I look for a communication approach that makes risks visible early. A consultant should be comfortable saying that an assumption was wrong, a dependency is late, a proposed approach is not working, or a decision is blocking progress. Quietly absorbing problems until a deadline is much more expensive than discussing them while there are still options.

6. What will we own when the engagement ends?

This is especially important for digital, technology, marketing, and operational work. At the end of the engagement, your organization should understand what it owns and how to operate it.

That may include administrator access, source files, documentation, credentials, analytics, design assets, process maps, training material, vendor information, and a clear handoff. Avoid arrangements where the basic ability to operate what you paid for remains dependent on one outside person.

7. When would you tell us not to hire you?

This is one of my favorite questions because it reveals how a consultant thinks about fit. Sometimes a company needs a specialist. Sometimes it needs an employee with ongoing ownership. Sometimes the problem can be solved internally with a few focused decisions.

A consultant does not need to be the right answer to every problem. Someone who can explain when they are not the best fit is usually giving you more useful information than someone who can reshape every problem to match what they sell.

The proposal should make the relationship clearer

By the time you receive a final proposal, you should understand more than the price. You should know what problem is being addressed, what the consultant will do, what your team needs to do, how decisions will be made, how progress will be evaluated, and what you will have at the end.

The best consulting relationships create clarity before they create deliverables. If the evaluation process itself leaves you more confused about the problem, the scope, or who owns what, that is useful information before signing the agreement.