Let’s take one of the problems in the previous article (It’s not rocket science), and see what’s driving it, which may give us a better perspective towards possible fixes.

I’m going to use a tool that I first saw (read, actually) used by Clarke Ching in Rolling Rocks Downhill, which uses a diagram to define the conflicting behaviour, and thence to uncover the assumptions behind it.

1. state the behaviour that you want to get rid of
I said that developers were so pushed for time that they didn’t test their code as they wrote it, nor before committing it to Subversion, our code control system. They were clear that they were working as hard as they could – doing the best they could – in the circumstances. Their repeated complaint was that the requirements kept changing so nothing could be finalised. That statement goes into the box marked D.

2. State the need that is being met by the undesirable behaviour, or which drives us putting up with it
On this project, at least, it was crystal clear – we had no time: we just had to meet the deadlines. Speed was driving slapdash development methods. So that’s what goes into the box marked B.

3. State the behaviour you desire, which is the opposite of D
Again, straightforward: I want developers to test their code before they commit/release it. This goes in the box labelled D’ (”d prime”).

4. The need that the desirable behaviour fulfills
Well, if we’re testing, we’re catching bugs during the development phase when it is cheaper/easier to fix them, rather than the later testing phase. That goes in box C.

5. The objective that the needs fulfill by both being present
Need B is meeting the schedule/delivering the project on time; Need C is delivering a high-quality product. Thus the objective we have to put in box A is: delivering a high-quality project on time and budget.

So, put it all together, and you get the conflicting behaviours and the reasons behind them, and a reminder that both reasons are aiming at the same target. Note also that for the objective to be reached, both needs have to be met, i.e. desirable and undesirable behaviour both have the same ultimate goal.

I’ll look at what comes assumptions are revealed from this exercise shortly.

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?