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.

If you haven’t read It’s not rocket science yet, please do first, as this article is a continuation of that theme.

I’ve said that key to a successful project is not just having everyone involved do their best, but having them work out what is the best thing to do, and then do their best at that. Anything else is at best a waste of effort, and at worst will doom a project.

I’ve also said that a sucessful project, just as any other system, needs a systemic view, rather than a bunch of local team views (new business, project management, creatives, developers, etc.).

So, how on earth do we go about finding out what’s best from a systemic perspective? A good place to start may be looking at some of the gripes that sit uncomfortably between teams involved in a project.

For example:

Project Manager (PM): developers’ estimates are always wrong.
Developer: PMs treat our estimates as promises, and thus can’t handle it when they turn out to be inaccurate.

Let’s think about lines on a graph: x axis denotes time; y axis denotes understanding. At the very start of the project, my understanding of what’s involved is minimal. At the end of the project, I know all there is to know about it (ah, the beauty of hindsight!). Between those two points, the line rises in a sloping curve, with most altitude gained in the first half of the project.

Where does estimation take place? Early on in the project, where understanding is incomplete (often requirements are incomplete too).

And that’s only the first problem. Here’s a second: when we estimate towards the start of a project for the length of a project, we’re looking far ahead into the future. The further we peer, the poorer our seeing, and the harder it is to a provide realistic estimate.

Estimating a project from the start requires long-distance lenses, so we may pad with a buffer because that protects us slightly. But, as the project progresses, problems arise, change requests come through, and the specification that we’ve been working from changes (or it doesn’t, even though the functionality does, but that’s another problem). This is how reality departs from our estimates. Towards the end of the project, we’re dealing with bugs that we couldn’t foresee and test results have come in, which frequently mean lots of change requests now that the client’s seen the proposed release version.

Two problems: estimating when our knowledge about the project is less than complete; changes arising that throw the project off schedule. Now what could solve them?

We want our estimates to be more accurate, so they can be considered commitments; and we want to be able to handle changes and problems that arise.

Imagine that, as a developer, you were asked each morning how long it would take to perform the single task you were about to tackle. Your response would be in hours, and probably more or less accurate. Imagine now, that you were given the whole list of tasks up front and asked to estimate on them – the answer would be in days, and a lot less accurate.

Firstly, say it takes 10 hours to complete a task, and you’re 10% out: it takes 11 hours. We’ve lost an hour. Say it takes 10 days, with the same margin of error, and it’s taken 11 days. Say it takes 100 days, and it’s taken 110 days. Thus the same margin of error, when affecting differing timescales, has very different ramifications. And just in case you think I’m being unfair by swapping from hours to days: if you think something will take one hour and I think it’ll take two, we have room for a discussion – the difference is clear; if you think something will take 30 hours and I think it’ll take 31, it’s a lot harder to explain the difference and decide which is a better estimate.

If we can make our estimates more often and more short-sighted, rather than a single one tackling the whole project, we stand a much better chance of getting the estimates right, we can adjust them based on recent learnings, and we can incorporate changes/problems as they arise.

That may resolve the conflict of PMs wanting commitments and developers not having concrete specs to work from (with no changes, ever ever). Whaddya think?