And finally, assignment of blame

I was discussing the natural progression of projects with an experienced friend. Here are the real project stages:

  1. Planning (have an idea)
  2. Estimation – always wildly optimistic
  3. Design – this stage may be done while implementing
  4. Implementation – project starts to overrun
  5. Private discussion with customer introduces a few trivial changes
  6. Design is finally written down – this stage may be omitted if time pressing
  7. Changes are discovered to double the project time and budget
  8. Project starts over-running severely
  9. Features start being cut, but are replaced by new features
  10. Project now massively over-running
  11. Features cut again
  12. Project released in beta
  13. Steady set of bug fixes
  14. Blame assigned
  15. Testing carried out – this stage can be omitted if customers desperate
  16. Innocent punished

Obviously this is different from the Design – evaluate – implement – evaluate – test – evaluate cycle that I learnt during my MSc, but I fear that even that included the two vital stages: assignment of blame and punishment of the innocent.
The easiest technique for blame assignment is, of course, to blame the absent. They are safely out of the way, and it will not harm them. Second is to blame the customer and the boss. This does not damage the team. Finally, blame may be placed on whoever appears most vulnerable to it. This has no relation to responsibility

Costing projects

I’m very aware that I should put keywords in my blog. I’m also aware that I’m not attempting to monetise my blog. Anyone who reads it regularly, leave me a comment and I will be most grateful. Anyone who doesn’t read it regularly: you’re missing out.

I was comparing the fantasy of Agile management to the joys of converting a house.

Firstly, no matter how tightly you plan your project, it won’t work. The tyres get punctures, the render doesn’t go off because it’s cold, the plaster sets too quickly because it’s warm and so on and so on. One of the illusions that computers peddle is that values are fixed and unchangeable. Over years of experience one discovers that an apple this year is not the same as an apple last year: it may be smaller, sweeter, less common and so on and so forth. In the same way, programmers get ill, libraries get updated, life turns out to be a little difficult. It’s fine if you’re building on a greenfield site, but in the real world you may not be.

So we are dealing a non-representative series of events. Estimates are based on normal – that frictionless set of billiard balls or that perfectly rational economic creature… Life is imperfect, unbalanced, frustrating, and driven by chance. People on the top want to believe that it is driven by skill. They wish to confirm that it is their qualities that have given them their privilege, and others’ failures that have denied it. When talking about becoming a premier league footballer, people are willing to admit that some people are born with more talent than others. You rarely hear the fact that given a couple of X chromosomes, you’ll never make it. One sperm over another. Your chances ruled out, just like that.

Given the innate unpredictability of life, you need a reserve fund to cover the likely overruns in time and cost and temper whenever you’re planning a project. You also need a contingency plan.
This is one of the things I find most interesting. What do you do when a project has overrun? At what point are you prepared to say “pull the plug/cut the costs”?

It is my belief that life is much simpler if you have a hard deadline, chosen in advance, such that when you go over it, the project is pulled automatically. I would be curious to see how many things would get sacrificed if you knew that at fifty per cent above the original estimate, or at twenty per cent above the original time, consequences dropped in.

When I was in a partnersip, I rekember bidding for a contract. We honestly told the buyers “It’s not possible to do y in the time, but we can do x”. We didn’t get the contract. We were correct, of course, but people want to hear that they can do y in time t. Anyone who says “No” will lose out to anyone who says “yes”. You therefore need heavy penalties for misleading on contracts.

There is less temptation to gain a contract bby being over-optimistic if you know there is an automatic penalty for getting it wrong. But how may customers prefer illusions to truth?

Project management and priorities

As detailed before, I have the hardback book (it’s green – anyone else remember the Porridge quote). It has pages and pages of lists, all neatly sorted into four sections, interspersed with scribbles, diagrams of flues, back of the list calculations and so forth.

Approximately once a day we have the discussion.

The discussion consists of:

1. What can we cross off yesterday’s/this morning’s to do list?
2. Oh, what did you do then?
3. Oh

Long pause

4. Well, I’ll add them to the list and cross them off.
5. Where are they in the list of prioritites?
6. OK, these are my priorities
7. What do we absolutely have to get done before we move in.
8. OK, we can survive without a shower.

Heated drawing up of two lists: one of things that must be done and one of things that are nice to have
We end up with three things crossing the line (insulation, decoration and chimney cowls if you must know).

9. So when you say do floor, what exactly does that involve?

Calmer and much longer list of all the components of the “things that must be done” list. During the discussion, we discover other things that must be added to said list.

What user interface design point am I demonstrating (or any other point)? I would say that it’s a technique that is a refinement of Bill Buxton’s Sketching User experience.

It is only when you have your ideas out there in some form that you can discuss them. I cannot stress this enough.

What I have in my head is non-negotiable because nobody knows about it.
What I say is somewhat negotiable, but it is often not clear what I mean.
What I sketch or model or put on paper is utterly negotiable because there is something to negotiate over.

Here is a mock-up of the stairs to the basement. It’s a starting-point.
They’re not on the priority list though.