Why Projects Fail

[Rob Cozens]

>Most failing projects I encounter have problems not with tools or 
>coding as such but with:
>- initial and continuing specification failure by the customer and analyst
>- estimation error or unrealistic deadlines, with feeble risk 
>management [words highlighted in bright red]
>- scope creep [words highlighted in red with clashing cymbals] both 
>in its natural form and feeding hungrily on the first two.

David,

I can't thank you enough for you wonderful analysis.  Every time I 
read about something like the California Dept. of Motor Vehicles 
abandoning an automated registration system after x years and $yM, I 
think, "give me this programmer, that programmer, and myself, and we 
could have done the whole job in six months [a manifestation of 
estimation error?], how is it with all those resources and all that 
money they had to give up?"

I thought your entire analysis was right on except for one issue: 
scope creep.  I think that some scope creep must be factored into 
original estimates.  This is because I don't believe anyone can 
design any application of significance that won't show some design 
failures during real-world testing.  I think initial specifications 
need to be viewed as general guidelines specifying desired 
functionality that are expected to evolve based on experience during 
testing.

I recognize that undertaking a contract project makes it more 
necessary for specific specifications that when doing in-house 
development.  In those instances I want the specifications as 
specific as possible; but the goal is to have a sound contractual 
basis when I come back and say "this and this are not in the original 
specs and will be billed separately".

OTOH, I certainly suffer from the "let me just add this one new 
feature before I release this" syndrome.  So I can see how this can 
get out of hand.

Anyway, I tend to see scope creep as a natural result when people 
experience with the application design as implemented points out 
errors in judgement or approach, and as the users become more 
knowledgeable in computer capabilities & more involved in the design. 
It's the people who were not forthcoming during the initial design 
stage that always seem to complain the most when they see the final 
design.

My guess is the leading cause of project failure--and this applies to 
small projects as well as large--is specification (communication?) 
failure between customer & analyst.  After years of being told "this 
will never happen" and programming accordingly, only to later be told 
"I know we told you this would never happen, but..." (and that's from 
the "good" clients, the others say "No one here would ever have told 
you that...", and I write them off as long-term clients); after years 
of having someone spend hours drafting a sample report format & me 
spend some time programming it only to have them take one look at the 
output and "this isn't really what I want.."; after years of saying 
"I know there is a better way to do this, but that's how the specs 
read; so I'd better follow them..." only to later find myself down 
some dead end or otherwise having to implement the design I knew was 
right in the first place; and after other real-world experience of 
that ilk, I have come to see scope creep as the inevitable result of 
imperfections in the design process, and as a necessary part of the 
implementation of an application adjusted to accommodate the 
realities of user interaction.
-- 

Rob Cozens
CCW, Serendipity Software Company
http://www.oenolog.com/who.htm

"And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee."

from "The Triple Foole" by John Donne (1572-1631)