How to Evaluate a Software Consultant

When I'm too slammed to work on a project solo, I'll hire other consultants to come on and help me out. I'm also hired as a consultant so I've been on both sides of the hiring process.

When I put myself into the place of a hiring manager or future client, I always think about the things they might be thinking about. Like does this person actually know what they're talking about, have they done something like this before and how do I know their estimate is real? If you're still earlier in the process and haven't yet narrowed down candidates, How to Choose the Best C#/.NET Freelance Developer covers how to find and screen candidates before the interview stage.

What is the single best question to ask a consultant that separates a good tech person from someone who is good at sales?

Some consultants are really good at sales and not so good on the tech side. In order to separate those folks apart I ask them this question.

Describe the last solution or project that you have built from start to finish. Doesn't need to be a greenfield project. This can be a situation you were brought into halfway through the project.

A strong answer will be one where the consultant can go into detail about what the problem was along with the detailed overview of the technical stack. They'll talk about at what point in the project they were brought in and how they were able to make an impact. You'll be able to have a conversation with the consultant about the timeline, budgets and the different types of people who were involved. That person should walk through the entire lifecycle of the project from requirements gathering to how they implemented their work to they different ways they have deployed the application to production. There shouldn't be very many unknowns from the consultants perspective.

The weak answer is going to sound less confident and they won't be able to go into the details of the project. They will glance over specifics and use a lot of 'ums'. They might skip over implementation details, requirements gathering and production releases. Maybe the person wasn't involved as much as they wished they were or as much as they'd like you to believe they were. If they have trouble with this question they may not have the depth you are looking for.

What should a competent consultant ask you that a less experienced one will not? And what questions signal they understand the problem?

The first question should be a variant of "What is the problem?" followed by "How is this affecting your day to day business and revenue?". When I'm talking to new clients, I'm trying to find out what their problems are and what's causing them pain. The consultant should be looking for ways to fix the problem and how they can apply their skills to fix it.

It's like a real-life case of debugging. What's the problem? Where is it happening? What fixes have you tried that don't work and are there any that have worked? They should be asking you (the client) follow up questions like "why?" to dig into the issue further. This will get you to think more deeply into the problem and respond with something you might not have thought of yet. A good consultant will get you to think more deeply than you might have been doing.

Someone who cares about your business is going to ask what the impact on the business has been. This shows the person understands this is a real world problem for a business and not just a technical puzzle to solve. Understanding why this hurts the business makes the problem more real to the consultant and helps them understand the real life impacts the problem has.

What does a realistic project estimate look like?

When you're talking to consultants you will want to get an idea of what their project estimates look like and how they come up with them. You can expect project estimates to vary from consultant to consultant. Each one has their own style and method. The best ones won't just have a number. The best project estimate will repeat back to you what the stated problem was with a breakdown of the work needed to resolve the issue. Each breakdown should be accompanied by a cost breakdown. A low-high number estimate of what it will cost to implement the feature. A good estimate will leave wiggle room in case the budget is too much.

Find out their rate but don't scoff at it no matter how high or low it is. Someone who knows what they are doing is going to charge a premium and won't budge on the rate. However, the good ones will break the project down in a way that features can be removed from the work order if the cost is too great. If your initial response is "That's too expensive", someone worth their rate will ask you to clarify - 1) why? 2) respond by asking what you are comfortable removing from the proposal in order to get the cost down to fit within the budget.

The estimate will include a rough time line, project scope, deliverables, cost and language for what data or access is required by you to provide the consultant. In order to make their work go smooth, the client needs to provide everything the consultant needs to do their work. A bad estimate up front is one of the most common reasons projects go sideways - Why Legacy .NET Projects Fail goes deeper on how scoping failures compound over time.

How confident are they in their answers?

When you ask these questions - how confident is the consultant in their answers and in their confidence in understanding your problem? Listen to how they respond, not just what they say. Listen for words and sentences that don't seem authentic, or ones that make it feel like the person doesn't really know what they are talking about.

The low confidence answers should be obvious to spot. These answers will dance around the meat of the question and answer. They won't get to the bottom and will remain surface level. The worst offenders will give non answers or answers to something more broad and not the specific question you asked. The person won't get excited about their answer. Lookout for a low confidence pause or silence followed by a vague answer. Someone who is comfortable in their response and work will be confident in their thinking and communicate that by saying "That's a good one, let me think about that for a second".

A good consultant will have a workflow and process for breaking down their project scoping skills. Good project scoping skills are the ability to see the problem and understand what it takes to solve. If you are going to work for a client it's important to understand the problem. Have the consultant repeat back to you the problem in their own words and then ask them how they would scope this problem out - estimate time, cost, number of people included. Bringing in a new consultant, the timeline and expectations need to be ballparked up front. You having an understanding of the scope, time and cost needs is going to make the project so much easier for everyone. A good scope covers requirements gathering, build time, testing and deployment.

After you pick a consultant

After you do pick a consultant you should expect them to be fully available on day one. Day one should be determined in advance so you set expectations on availability.

Have all the requirements the consultant needs ready to go on that day. The first 30 days should be about gathering requirements and open communication. If you expect to have 100% of their time, be open about this from the start. A lot of consultants will balance multiple projects at a time. If that's not your expectation, then that needs to be made clear.

The start of the project will be the information gathering phase. As the consultant gathers info on the business and requirements, expect to be available. As the project lifts off, your time needed should diminish as they get to work. After 30 days come together to discuss the project so far. You will have a feel by now if you hired the right person. You should have a sense that you hired the right person because they will have made good progress in the first 30 days by gathering requirements and put together a plan, stated a true understanding of the problem and - this is the most important part - have mapped out a path forward toward a solution. If things aren't tracking that way, How to Fix a Broken .NET App You Just Inherited covers what to do next.