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?

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.