Business Productivity

What the &^%$! does my consulting client really want?

- November 7, 2018 4 MIN READ

When a potential consulting client receives a consultancy proposal the very first thing they are concerned about is:

  • Does this consultant really understand what I’m trying to get done here?
  • Do they understand what my problem or issues are – do they really get it?

Your proposal is your one chance to convince them of this. But getting that right can be tricky – especially when you’re new to the consulting game. Because guess what….

Consulting clients often don’t know what they want

I don’t state this with any intention to criticise my clients, but the reality is that they often struggle to provide a clear project scope for consultants. They know they have a problem, they know they want outside help, but they may not know how to capture the essence of what’s needed from a consultant.

In many cases they’ve never had to do this this before.

So the bottom line is, helping clients figure out what they need is a core part of the consulting role. Unless your proposal tells them ‘you get it’, they’re unlikely to hire you. But how do you make sure you understand what they need, even when they aren’t sure?

Here are my tips….

Never take the consultancy brief at face value

I use the term ‘brief’ loosely here to describe a variety of ways in which a client’s needs might be conveyed to you. It may present as a tender, a formal written brief, or an email with some basic details, or it could be just a phone call. No matter what the guise, never assume that this initial information is an accurate reflection of what the client needs or wants.

Even if everything seems to be set out in great detail in writing – don’t trust it. You need to interrogate it, dig around, find the essence of the problem. I can’t tell you the number of times over the years that through a bit of digging, the project turns out to be very different in scope than the original version.

Get the back story

Nothing will give you more insight into the ‘real’ set of issues than getting the back story. That’s where you’ll find the information you actually need to prepare a proposal that’s going to resonate with the client. It’s all about reading between the lines and finding out what’s really going on.

Even if you have a written brief, get the client to tell you their basic requirements. There’s no doubt about it, getting them to tell you in their own words will yield a lot more information – and potentially tell a slightly different story than the written brief.

And if you need to talk to them more than once, that’s fine. I often find that when I’m writing the proposal I have additional questions, and I’ve learnt from experience that it’s much better to clarify those now than just make assumptions [which invariably turn out to be incorrect].

When I first started out as a consultant I worried that this would give the impression I didn’t know what I was doing, that I needed a bit too much hand-holding. Over time, I’ve come to realise that this is actually an extremely valuable service I provide for my clients. Done well, those conversations invariably bring clarity for them [as well as you] about what they need.

So pick up the phone before you charge ahead with a proposal.

Find out what the client hopes will be different at the end of the project

Clients use consultants when they have an organisational problem they need help with. They need an independent lens, a fresh set of eyes. The brief might be clear about the problem, and maybe even the process they want you to use, but you also need to know what the client expects to be different once you’ve come and gone.

It really is as simple as asking them exactly that: What do you hope will be different once the project is completed?

Their answer to this is critical.  If they are clear about this and their expectations are realistic, you can prepare a proposal that speaks directly to those. If the client can’t answer this question, or their expectations are unrealistic, it’s an opportunity for you to help them gain clarity and/or to discuss more realistic expectations. And if you can’t do either of those, it should definitely flag alarm bells for you.

Confirm the deliverables

Every project will have a set of tangible deliverables – make sure you confirm what these are. The end point one is usually clear – it’s commonly a report, a plan, a strategy, a policy, a set of guidelines. But don’t stop there – there are always a number of other deliverables that are required along the way – find out about those too. It could be a final project plan, a stakeholder workshop, preparation of an issues paper, progress reports, consultation guides, a Board presentation. Once you know what all the deliverables are it’s easy to incorporate these into the proposal.

The win for you [and your client]

When a client reads your proposal, you want their response to be total confidence that you really understand what they’re trying to get done, what problem they have, what they want to be different and what they want you to deliver.

Because if you can do that, trust me, clients are going to warm to you, they’re going to be grateful to you, they’re going to want to hire you. You’re going to become sought after.

AND – as a bonus, if you and your client are on the same page right from the start, you are much more likely to be able to deliver to their expectations, and both of you will have a more positive experience.

Just this week I sent a project proposal to a client after a telephone briefing for a pretty complex project. He rang me the following day and said “I have no idea how you managed to create something so coherent out of that conversation….its exactly what we want”.  Job done.

Of course after years of experience it’s second nature to me these days, but if you at least understand that this is a key consulting skill right from the start of your consulting career, you’ll also build your expertise over time. If you’re keen to learn more about this topic and other key consulting skills, take a look at my free video series.