Winning And Keeping Corporate Clients

This is

an article about selling to medium and large organisations, based on both

selling to, and buying for corporate clients, and making sure that all

concerned are happy about the result. The amount of work may not be that

large (although the daily rates are attractive), and you may only be dealing

with a small department or offshoot, rather than directly with the behemoth,

but whenever you're dealing with work for a corporate client, the rules

are pretty similar. Actually, many of the behaviours you need to show

will also make life easier if you're selling to smaller organisations

too, so don't ignore all this because your market is SMEs.

Corporate is different

The main difference between

Corporate clients and non-Corporate ones is not size, but the level of

organisational complexity involved. I've worked on a job where the client

was under 20 staff, but they answered to an industry consortium made up

of a number of competitors. The job may be extremely simple (and in that

case, it was), but to win and keep the work, you need to understand that

the organisation who's paying for it is complex and needs to be handled

in a way that respects and responds to that complexity.

A number of the approaches below may strike you as absurd, wasteful and

calculating. A priori, they are. But you

need to think in this way to keep the money flowing in. If you reject

what's below in principle, condemning it as management speak, you're probably

right. But that's the point. If you're targeting Corporate clients, you

need to speak the language — understand the code, play by the rules

— that Corporate clients live by. And as they're the ones with the

work that you want, it makes sense for you to make the compromise.

But why would you bother?

Because that's where the work

is. Not only are Corporate clients the source of most jobs, they're

also the source of the best daily rates — they pay professional

rates for a professional job, and they're likely to be around next month

when payment's due.

The most important difference:

The person you are selling to has to justify the time and money

involved to stakeholders (including but not limited to bosses) who you

won't meet. They will look sympathetically on anyone who will them help

to do this with the minimum of stress on their part.

If you understand this, and are prepared to work with it, 90% of what's

below will flow naturally.

Getting the Work

Who is the Buyer?

This is perhaps the biggest

mistake that inexperienced people make in selling to corporates: they

assume that the client member of staff they talk to can make the decision

on their own. In nearly every corporate environment, many people influence

the buying decision, with varying levels of influence. The person you're

talking to may not even have a significant influence; they may be easily

over-ruled by other stakeholders with different objectives.

So rule number 1: Find

out the stakeholders and their likely agendas. You'd expect those

agendas to be simple: good work for low cost. But it's not that simple.

Every stakeholder will have their own private agenda too. Obstruct that

private agenda and you'll have difficulty gaining their support.

Here's an example of a typical

set of stakeholders, laid out in a way which makes it easy to quickly

devise and stick to a plan of attack. It doesn't address their inner personhood,

but it's about winning business, not lifelong friendship.

The scenario is that Paul has

put your name into the pitch process for the work his team needs because

he's seen that another site you've done does something similar to what

he needs.

Name	Attitude to us	Influence	Role	Personal Agenda	How we will satisfy it
John	Indifferent — also uncaring about who gets the work as long as it's good work	Low	Technical expert We need a tick from him to reassure management that our work will be up to quality.	Needs to be confident that our work is up to quality, plus wants to be able to show off the site to his evolt.org(!) mates	Reassure him that the site will be standards-compliant, usable, accessible and lickably gorgeous
Paul	Positive	Low	Works in the team that will benefit from the site. We need him to be actively pushing us	Wants to be given a project to star in	Subtly position him as the natural leader of the project or an element within it, and help him do it successfully, even if it means crediting him with work we've done.
George	Somewhat negative — would probably prefer DIY	High	Manager of the team that'll benefit from the site.	Needs to be comforted that the work will be completed to time and budget to maintain credibility as an effective manager	Emphasise our professionalism in project management skills — all negotiations handled well, with quality written documentation (check the spelling with a fine tooth comb!)
Ringo	Negative — isn't convinced that our work is best value for money	Medium	Budget holder We need a tick here or the budget won't get signed off.	Wants to show how tough he is to senior management.	Make our initial quote on the generous side, allow ourselves to be beaten down to a fixed project budget. If possible, make our final invoice a bit under budget

So out of all this lot, who's

the buyer? Well they all are, but only Paul needs to actively choose you

to do the work. Everyone else has merely to be reassured that you won't

screw up. Fortunately, Paul is already on your side, so you need to keep

him there while moving everyone else to at worst being unable to think

of a good reason not to use you. And if you give everyone a boost to their

own personal agenda, they won't try that hard to look for that good reason.

RFPs

— Answer the Question

In ideal-world, all you have

to do is show the potential client your portfolio of work, submit a quote

for the work you're pitching for and wait for the call to start. But it

rarely happens like that, and understanding what happens during the 'wait

for the call' stage can be very helpful in getting the work.

Normally, a corporate client

won't have a completely nailed down set of requirements at the point that

it finds an agency to do the work. What they'll often do at that point

is issue a Request for Proposal (RFP), which is a document which is the

bones of a brief, laying out what the current business objectives of the

project are. In responding, the agency must put together a best guess

outline of the how they intend to go about delivering those objectives.

The successful agency will then work with the client to nail that down

in detail.

In assessing the responses to

RFPs, the client is trying to work out a number of things:

1. How well does the agency understand and seem capable of supporting
   our wider business objectives?
   
   Sitting behind the brief is the environment that the buyer
   is sitting in. Above and beyond the specific needs of the work set out
   in the RFP is the larger needs of the organisation. If the RFP is for
   a site to keep lots of conflicting interests informed and supporting
   a major project, will you as an agency help that process? Or will your
   behaviour make that harder by having opinions which are visible and
   upsetting to one of those interests?
2. How well does the agency fit with our industry and organisational
   culture?
   
   If the site is for a banking client, will they embarass us
   by turning up in skate gear and talking whizzbang jargon we don't want
   to make the effort to understand? At a basic level, can we form a mutual
   respect so each side can understand and respond to the other's needs?
3. How well does the agency understand the brief?
   
   The RFP will be written to support a set of business objectives
   and have a set of constraints — both organisational and technical.
   No matter how firmly you believe that a Linux/Apache/PHP/MySQL solution
   is the best solution for the type of site in question, a client with
   an all-Microsoft architecture isn't buying. You may feel that a client
   is best served by a content management system, but if they don't have
   the staff time to update the site and would rather brief you to do it
   for them, you've wasted your time proposing anything else. If the solution
   proposed by the agency doesn't actually deliver an appropriate solution
   or show that the agency could deliver a workable solution given
   the full facts, the work will go elsewhere.
4. How competent is the agency's work?
   
   This is largely based on an agency's portfolio — demonstrating
   that the end result is fit for purpose.
5. How capable is the agency of delivering the project?
   
   This is a key project management question. The agency needs
   to demonstrate that it will deliver on time and on budget, and —
   most importantly — ensure that management are reassured that this
   is the case at all times.
6. What's the estimated price?
   
   This needn't be an absolute firm price at this point, as the
   RFP still isn't a full requirements spec. Either an estimated total,
   or a pricing model could be enough. How and when you're going to bill
   the client can also be significant.

Which is the most important

to satisfy? Which can the buyer let slip a bit if it comes down to a choice

(and no agency is perfect across all areas)? It's easy to assume that

you must demonstrate elegant solutions which look lovely and satisfy all

the standards known. And from a pride in your work point of view, that's

how most of us feel about it. But past a certain level of "Good enough",

that's rarely the case.

Look back at the stakeholder

chart above. John has a low influence — and that's typical in corporate

projects. The highest influence will nearly always come from the traditional

suits — the senior manager and the budget holder. In the vast majority

of corporate project sales, delivery outweighs talent because talent is

common, and talented mavericks are just a pain to explain to the boss.

The rare and valuable creature is the one who when they say they're going

to do something, actually does it.

On the other hand, don't expect

that the lowest price will automatically win. The thing that the budget

person is looking for is that it's in the right ballpark, or could be

once the full requirements are defined and the budget negotiated. Quoting

too low will raise questions over whether you're cutting corners, so it's

important to know what the client expects the going rate to be for the

specified amount of work. Once you understand that — and know you

can still make money — then you know what to quote.

Keeping the Work

Congratulations — you've

got the contract! You've worked out a final spec and price and have started

on the job.

Now how do you keep it? And as the newly incumbent web agency, how do

you use this position to gain more work? It's all based on how much the

client trusts you.

Building Trust

As we've already seen, the best possible thing to do to a manager is

to deliver what you promised, when you promised it and for the price you

promised. Consistently do this, and you'll get a reputation for reliability

— your client's project manager can make promises based on your

word and know that the promises are good. Project managers

thrive on this kind of stuff: it's what they get rewarded for, and as

you now know, supporting personal agendas gets you sales.

Conversely, the worst thing you can do is spring nasty surprises on them,

because then they have to explain to their stakeholders that they can't

deliver their promises without the benefit of having prepared the ground

first — the hassle goes on up the chain.

Everything you do on the job needs to be aimed towards building

and maintaining your client's trust in your ability to deliver what you

promise.

Manage Expectations (aka Cover

Your Arse I)

At all times, you have to be

in control of what is expected of you. It'll come as a pleasant surprise

to learn that clients do understand that sometimes things run late or

over budget, provided they know about it and are reassured that you're

doing what you can to bring it back in line. If they know about the possibility

early enough, they can plan around it, and make sure that their stakeholders

don't get upset about it. But the key is that they have to have accurate

expectations, which they will base on what you tell them.

Progress Reports

At all times, you have to be

able to tell your client project manager how you're doing, compared to

where they expect you to be (aka the Project Plan). They may not require

you to submit monthly, weekly or (heaven help us) daily progress reports,

but if they ask you for the information, you have to be able

to answer within a day or so.

Most importantly, you have to proactively tell your client project manager

when you're going late or over-budget, by how much and what you're doing

about it. You need to do this at the earliest opportunity: as soon as

you think it's a risk.

This means that you're also

going have to have a very strong project plan, separate from the one that

the client holds — usually in more detail. This should be based

around what you need to deliver to clients and be 100% clear how you're

doing against it, including best and worst case outcomes. And to get that,

you need accurate information from everyone working for you. Unless

you're absolutely against deadline, having progress information to hand

is more important to keeping client trust than doing the work.

You need to be on your staff's backs about this to the level of near fascism

because it goes against the natural grain of nearly all developers, designers

and writers (this is why agency account directors have authoritarian reputations).

It makes sense to formalise

this — make it a regular appointment both with your team, and with

the client and get absolutely everything documented in writing in more

detail than you expect to tell the client. That way (a) you won't forget

(b) you can respond to client requests for more information (c) the client

can't complain that they weren't told about any likely problems.

Manage Changes (aka Cover Your

Arse II)

Show me an agency who hasn't

had to cope with changes in their client work and I'll show you an agency

that doesn't have a portfolio. It's inevitable that changes will come

along. If you hope to still have the contract afterwards (and ideally,

charge for making them), you need to have everything nailed down tightly.

Repeat After Me: "It's Not In Scope"

The very first piece of work (chargeable, ideally) you should do is to

define the requirements of what you're agreeing to do. This will be the

basis of your final contract, and will let you calculate the exact time

and cost you'll need to do the work. Once that's agreed and signed, then

you can start work proper.

However, once you've started, it's inevitable that the environment will

change (usually at the order of one of the stakeholders you can't influence),

and your schedule of work will change along with it. This can go in one

of two ways - more work (and the same size job built differently is nearly

always more work) or less work.

If it's more work, the mantra you need to repeat until you can recite

it in your sleep is "It's not in scope," which means "we

didn't agree to do that in our original time/budget exercise." The

outcome of this should be a renegotiation of the time and/or budget involved.

You'll need to work out what the difference is, and the client will need

to formally accept that so that it becomes a variation in the contract.

This needs to happen before you start any work on it.

Otherwise you're doing work that the client hasn't contractually agreed

to, and your chances of being paid for it are limited.

If it's less work, you may have the choice of demanding the money anyway.

But the breakdown in the client relationship involved is rarely worthwhile,

particularly if you want to sell to them again. If you've built the right

relationship with the client project manager, they'll be feeling angry

about it too — particularly if they have the same personal needs

as Paul above. As well as being upset on their own behalf, the client

will also likely feel that they owe you one. So stop and think of an outcome

which is good for both of you, such as a committment to (or at least a

sympathetic opportunity to pitch for) another unrelated piece of work.

In either case, it's useful to put in place a process for managing change

requests. A change control process can be formal or informal, related

to the size of project, and may have different levels of formality and

signoff depending on the impact of the change. But the bones of it will

always be a description of the change, a benefits statement, an assessment

of the impact on time and budgets, and signoff from both client and agency.

"I Serve at the Pleasure of..."

It should go without saying

that all changes to the site need to be instructed by the client. They

own the result, and pay you to make that result the way they want. If

you disagree with the client on what this should be and how it's best

implemented, it's fine to challenge them. But it's not your decision in

the end. Ultimately, the client has to sign everything off and you will

rarely get paid until that happens.

This also means that if you

make changes on your own initiative, don't expect to be able to bill for

them. If the client tells you to make the 404 error page a duplicate of

the homepage, by all means demo a

better alternative. But if they don't go for it, the time taken to

change your demo to their instructions isn't client billable (unless otherwise

agreed).

Manage Risks (aka Cover Your Arse III)

There will inevitably be a list of things which could go well, or badly,

and that you don't have control over. The thing to do is make sure the

client is aware of them,so there are no nasty shocks, and your plan for

dealing with them, so they have confidence that you can cope if they do

turn out that way.

As with progress reports, you need to keep a register of these separate

from any register the client keeps. At a minimum, for each one, you need

to know:

• What the result could be
• How likely it is (could be a rough percentage, or a simple high-medium-low)
• What impact it will have if it happens (both in detail "the result
  is x" and summary on a simple critical-high-medium-low scale)
• What you're doing to reduce the likelihood of it happening
• What you plan to do to reduce the impact should it happen

To help you take it all in in a glance and concentrate on the important

ones, most projects use the the probability and impact ratings to produce

a simple red-amber-green rating for each one.

When Do I Get Paid?

The short answer: when the client signs off on

your work.

The longer answer: at stages set out in the contract,

usually based on milestones (eg "When we have a site structure"

or "When the site is live") in the project plan. The client

needs to formally accept that the milestones have been reached —

this should be in writing. For the site go-live, it's inevitable that

some measure of UAT

will be involved.

Summary

Getting work from the Corporate sector isn't impossible. Keeping the

work right through the contract and onto the next sale isn't impossible.

Both need a broadly similar approach to the one traditionally taken by

independent developers:

• work out your stakeholders
• work out their needs
• build the relationship by responding to stakeholder needs

The difference is in what those needs are and how you respond to them.

You'll need to talk differently and behave differently to reassure your

stakeholders that you can help them manage the complexity of their environment.