We were going through a small project that we’d just completed for the purposes of getting sign-off. We had built in the functionality they wanted, using the designs that they’d agreed to, so it was plain sailing.

And then the spanner.

Part of the project is a news article page with a sidebar listing other news articles. The client decided that he wanted to be able to filter these. “Could we add a couple of dropdowns listing the article categories?”.

That was the point when my anticipated reality and real reality diverged:
- anticipated reality: AM says “Sure, we’ll have a think about the best way to implement filtering, and present a couple of options back to you”.
- real reality: PM says “Right, we’re going to add a couple of dropdowns below the list, one for ‘projects’ and one for ‘countries’ and they’ll alter the article list you see”.

After the phone call, the PM asked me to go ahead with it. Eh? Shouldn’t we get a designer on the job – someone who knows about usability and interface design, perhaps?

I thought I’d won that little spat when the PM sloped off, but she got a tester who wants to be a designer to photoshop exactly what the AM had suggested on the phone. Bang went any hope of getting an expert in human computer interaction on the job.

The Account Manager’s defense is that we’re doing what the client wants. Well, I counter, that’s not good enough – despite my previous post saying that we “pretend the client knows what they want”, we shouldn’t allow them to define the solution. Yes, sure that’s what the client thinks they want, but we are being paid to know better.

I may know what I want to eat when I go to a restaurant, but I still like to hear what the specials are, just in case there’s something even more exciting. I may even know how to cook the dish, but that doesn’t mean they’re going to allow me to roll my sleeves up and get to work in the kitchen. I am paying for the chef’s expertise, and for the satisfaction of delegating a whole bunch of thinking and labour so that I can enjoy the fruits.

Yes, the client should be right in there defining the problem. Then we should check it and redefine it, and again and again, until we’re absolutely clear about it. Then we should get an expert  (maybe a few, even, bringing different viewpoints together) to draw up a solution or two, and present those back to the client. “But it’s just a simple change” the AM cries, except that it isn’t, because it hasn’t been fully defined.

The wannabe-designer did a great mock-up, but couldn’t tell me how the functionality should work – there were different colours of text indicating selected states, but she didn’t know how that would work between the two dropdowns. In short, the solution wasn’t a solution. Meanwhile, the developers aren’t clear what they should be building, the project manager’s frustrated because she thinks that the project is now in development (well, she got us the designs, didn’t she?), and the account manager’s having to deal with an increasingly impatient client who thought the solution was defined over the phone.

If the client’s paying good money for our services, we should provide those services. That’s the clearest thing, isn’t it? We are digital experts: strategy, user experience, design, technical development. The client is an expert in marketing and sourcing quality work (I hope). One side should be bringing a problem, the other a set of solutions. Now, which is which?

Both are clearly untrue (to greater or lesser degrees), and both serve to make our jobs harder because they distance us from the most important person in any project.

So here’s a list of questions I would like answered:

• why do we keep secrets from clients?
• why are we so keen to promise tight deadlines?
• why do we try to squeeze in extra stuff for them?
• what if we treat them as part of the team?
• what if we made them fully aware of the repercussions of their decisions?
• what if we made demands of them, in order to deliver
• what if we explain how risk builds up, and what they can do to mitigate it?

I honestly don’t understand the prevailing attitude towards client in my industry – after all, we can view them as the other, or we can view them as our extension in another organisation, where they have their own set of clients that they are trying to satisfy. After all, we do what we do in order to succeed don’t we, to work our way up the ladder? If my job becomes one of enabling Joe Client to do well in his job, then he and I are allied with a common purpose, rather than sitting opposite each other across the client-agent divide (which is what creates the kind of attitudes I mentioned at the start).

So let’s pretend that clients know what they’re talking about, and that we are there to support them when they don’t. And let’s start down that path by having sensible grown-up conversations with them where we are open about the effect that they have on the success of the project.

I’ve worked for several companies where the money comes in only when production is complete. All speculative brain-storming and project-definition is paid for by the cost of the implementation stage.

Problem #1: brain-storming/project specification isn’t an expense; it’s vital, hard work, required to think up the best product we can. As such, it requires time and skill. If it’s not paid for in its own right, then it is always under pressure to cut costs – by lessening the time spent on it, and/or by putting cheaper resources on the job (when this is precisely the point at which more experienced people are most effective).

Problem #2: if we’ve thought and spec’d up the most wonderful product in the history of the web, but the client changes their minds, all that work hits our profitability. If we only charge for implementation, the time spent thinking up fabulous ideas is money lost unless the project goes all the way through production.

Problem #3: development frequently takes longer than estimated – whether it overruns the schedule or stays within the buffers put into the estimate. If all the up-front creativity is to be paid for by the profit from development, then guess what – we’re making less than we planned to.

Problem #4: because it’s not paid for, the cost of it is frequently covered by the account, which means that the account managers do the work, rather than pulling IAs, art directors, senior developers off paid-for implementation work (after all, they’re expensive). The result is those with least experience define the project.

The most important part of the project is in the definition of the work to be done. That, then, is where we should spend a sizeable part of our time, discovering/brain-storming, defining/specifying, and planning. Given that we are creative agencies, then we should charge for our creativity. It’s bleeding obvious when you read it, isn’t it?

The solution: charge for our creativity. Agree with the client that they will pay a certain amount for us to think up and define a project. Getting paid for the work means we no longer need to skimp or cut corners on it (problem #1). Getting paid means we’ve not lost anything if the client decides not to go ahead with the implementation (#2), or if they choose to take the work elsewhere. Getting paid means that we don’t need to fund that part of the work from somewhere else(#3). Getting paid means that the right people can be on the job(#4).

Bleedin’ obvious, innit?

They reckon that “urgency is acidic” – it burns out morale, especially when working towards an emergency deadline lasts more than a day or two (like, say 7 weeks plus – you know who you are!).

If your deliveries are that critical to the hour or day, maybe you’re setting up false priorities and dangerous expectations.