Consulting Value Chain: SELL

In the previous edition of this blog, I discussed the "Envision" stage of the CVC. Here's a quick re-cap:

To build our credibility and develop trust (being the most likely way we'll win business), we must develop solution options, plus advantages and disadvantages of each, and a clear recommendation with supporting arguments. Most importantly, the supporting arguments must show alignment with business objectives and priorities. Because without that, why should the customer follow our recommendations?

In this post, I'm moving on to the next stage, "Sell".

You could argue that this stage is the most critical in the CVC. After all, without the sale, we won't be delivering the solution or any related services. But I believe that to be successful in the Sell stage we need to do a great job in the previous stages, Engage and Envision, by building our credibility and developing trust with the customer.

That process must continue here - we haven't won anything yet.

Most bids are unsuccessful: the average win rate for sales-lead Proposals is about 45%. The average win rate for RFx (RFQ, RFP, RFT) is even lower. 👉 And most bids are lost on price.

Given the thousands of hours that an IT services company may spend on bids (Proposals and RFx) and the related costs, it might seem strange that most of them don't have a methodology for creating winning bids. Nor do they have a way to ensure that methodology is followed, for example through consistent upskilling. Strange, but true.

The majority of IT services companies do little beyond providing templates, calculators and management of the bid process. These are important, of course, but if consultants don't know what to write in those templates, or how to estimate the effort for those calculators, they will lose most of those bids. These leads to "copy/paste" bids

So there's a huge opportunity for IT pros like you in gaining these critical skills:

1️⃣ Collaborate with customers to define scope and avoid unwelcome suprises

2️⃣Writing compelling Proposals (no, GPTs aren't the answer 😉)

3️⃣ Estimate effort accurately and consistently

4️⃣ Develop the delivery schedule

5️⃣ Write tight, clean, risk-managed Statements of Work (GPTs still not the answer)

When you develop skills and proficiency in these areas, you'll massively improve your value proposition to employers because these skills are critical but aren't taught.

Let's break each of these skills down and look at them in a bit more detail.

1️⃣Collaborate with customers to define scope, avoid unwelcome suprises

Customers engage IT services partners when they don't have the expertise or resources to do the job themselves. However, they often have a budget in mind when they first engage with those partners; understandably they want to have some financial guidelines in place.

However, this can be problem if it leads to a fixed expectation of the budget, in the customer's mind. Another problem might arise if, in order to set a budget, the customer has already developed an idea of what they think the solution will be.

This in turn presents the IT services consultant with a challenge, if we are constrained by an unknown budget and early assumptions about the solution which might not be appropriate.

One way to get around this is to simply ask the customer what their budget is. They are unlikely to share it with us of course, but we might get an indication if we frame the question as "previous experience has shown that this might cost in the region $x to $y. Is that in line with your expectations?". But that puts the risk on us; by mentioning any figure, even indicatively, we risk setting expectations with the customer.

The way I approach this is through what I call "enlisting" the customer. If we've done our job well in the previous stages (Engage and Envision), we will have a good understanding of the customer's objectives and the proposed solution options. So it should be possible to progress through the development of scope in close collaboration with the customer, step by step, so that it's literally a joint effort - after all, it's in the customer's interests to get the best result, and, customers hate surprises.

Taking this approach will continue to build credibility and trust with the customer and is much more likely to be successful than spending weeks assuming we know what the customer wants only to then find out we don't.

2️⃣ Writing compelling Proposals (no, GPTs aren't the answer 😉)

A compelling Proposal, or proposition, will reflect perfectly the customer's context, challenges and objectives. For the customer, it should seem like they're looking in a mirror; they will feel seen and heard. When this happens, price becomes a secondary consideration, because the customer is confident we've understood the problem and we've got the right solution (after all, we just worked through it collaboratively with them).

A compelling Proposal will position ourselves as the obvious choice of partner. We've shown clearly our understanding of the customer and solution but we've also skillfully woven our "win themes" - our differentiators and value-adds - throughout.

And a compelling Proposal will be targeted, personalised and, above all, easy to read. Sounds reasonable, right?

Well, that's not what happens in the majority of cases. More likely, wodges of copy/paste techno-blather are lumped together in a Frankenstein's nightmare which requires considerable patience, dedication and desire to read through and understand. These will inevitably be put aside in favour of better-written and presented Proposals.

💡And that's why most bids are unsucessful.

(GPTs can help only if they can be trained on a body of good examples. Most IT services companies would struggle with that).

3️⃣ Estimate effort accurately and consistently

I've put this question to many IT services leaders:

"If you gave the same requirements and information for the same customer and project to all of your pre-sales consultants and asked them to scope, estimate and price the work, what degree of variation would you expect?".

In every case, the response was a wry smile and, "a lot".

Because, naturally, if there's no consistent approach to scoping and estimating, the pricing will always be different. Further, without consistency we can't have confidence. And without confidence, the SME will add contingency, the Principal will add a bit more, the PM will add some and then finally a bit more stacked on by bid governance.

💡And that's why most bids are lost on price and why most IT services companies try their best to avoid fixed-cost work.

4️⃣ Develop the delivery schedule

IT pros, when hearing the word "schedule", think "project manager" and "not my problem". But optimising the delivery to manage risk, cost and quality is what gives us the estimate of effort. Yes, a project manager should review the schedule but they will thank you for doing most of the heavy lifting for them. After all, you're the subject matter expert.

Project scheduling should be a skill in every technical consultant's toolkit. But, as with everything else I've described here, it's unlikely you'll be taught these skills by your IT services employer because "scheduling is for Project Managers", right?

💡And that's why projects often overrun, are delayed or exceed their budgets.

5️⃣ Write tight, clean, risk-managed Statements of Work

The Statement of Work should be a separate document to a Proposal. It may accompany a Proposal, or it may come after the Proposal is accepted. It shouldn't be confused with a Proposal which, as discussed, should be compelling, persuasive and easy-to-read documents aimed at decision-makers and senior stakeholders. Whereas Statements of Work are the details of how the work will be performed, aimed at the person(s) charged with overseeing the work (such as IT managers, project managers and others).

As with Proposals, Statements of Work are often a lumpy collage of copy/paste from previous attempts. Not only is this extremely risky (because the Statement of Work forms part of the legal contract) but it's also more time-consuming to find, copy, paste and re-engineer the content than to write it from scratch - assuming a good methodology exists and is used, of course.

But because most IT services companies don't apply or even have a methodology (templates can form part of a methodology but cannot be a substitute for it), once again it's down to each individual to figure out their own style.

💡And that's why arguments over scope and responsibility arise, and why risk is often not managed leading to delivery issues.

(As with Proposals, GPTs can help only if they can be trained on a body of good examples. Most IT services companies would struggle with that).

Imagine having learned these skills and techniques and being able to demonstrate proficiency to an IT services company (current or new).

How do you think that would affect their perception of you? And how do you think you’d compare against others who haven’t learned these high-value skills?