Last year I was fascinated by the results of the exercise proposed by David Barnholdt concerning the creation of specifications versus the detail of the request provided. David supervises two working groups, to each he gives 1 minute to create the following specifications, to the first group he asks: “draw a meadow during a beautiful summer day, with blue and red flowers in the green grass, some cows and some birds under a bright sun”. To the second he asks: “draw a meadow during a beautiful summer day with: 10 blue flowers with 5 petals each, 5 blue flowers with 6 petals each, 13 red flowers with 6 petals each, 2 cows with 3 black spots, 1 cow with 5 black spots, 2 cows with 4 black spots, 2 birds in the top left corner, 3 birds in the middle, the sun on the right with 5 rays”. The result is stunning but we should have expected it:

The comments are on David Barnholdt’s blog but the point is clear…

My purpose is to extrapolate this game of cause and effect to the level of project contracting. One could say that we remain in the same domain: expression of needs (specifications) which I extend to the previous phase of requirements documents, etc. and thus to contracting.

In France the culture of fixed-price contracts with a very defined scope is strong, even more so in the context of public tenders. In my opinion, this is one of the major causes of failures or difficulties experienced in IT projects.

On one hand, everyone knows well that it is impossible to know 100% of your scope in advance (if you read Popendieck she scatters some “funny” anecdotes including the one about the “marines” (pronounce “marines” with a cigar in your mouth): when they launch an attack they know 70% of their plan, they know that 30% of what will happen is not “predictable”). So committing, paying, contracting for something unknown or worse, false, is a serious error, heavy with consequences.

On the other hand, not content with being unable to define 100% of the scope in

advance, the client, the requester, always has the fear of being

deceived, cheated: they will therefore over-specify (this is where I tie back to

the exercise mentioned previously). They will ask for tons to be

sure to get “their money’s worth”. And this will prove counterproductive

the “over-specification”, the specialization, will probably lead to custom developments which, while they will respond very precisely to one point, will strongly prohibit and limit all other functional or technical aspects.

We cannot blame them, IT service companies exist to make profits and when there is a dispute, it’s the requirements document or the specifications that are authoritative, so very quickly. In short, it’s a struggle, a trench war, rather than a collaboration. And it’s the snake biting its own tail, because the more IT service companies will stupidly play their role, the more clients will over-specify.

Difficult also to find a way out: if a client makes the effort not to “pile on” the IT service company will take this as a windfall and jump on a probable margin to be extracted. I come back to agility which is -once again- the best solution, iteration, collaboration, in short common sense. We must break with contracting based on a complete pre-defined scope. Today in the context of public procurement this is unfortunately virtually impossible.

Two maxims to meditate on: (go OooommmM) “the best is the enemy of the good”, “All failure comes from misunderstanding” (“all failure comes from a misunderstanding”, the wheel of life, Tibetan thing, 500 years BC)