Why Projects Fail

[David Vaughan]

On Tuesday, March 26, 2002, at 06:13 , Rob Cozens wrote:

>> 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,
snip
>   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.
snip
> 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.
snip

Rob
Any large project has (and even small projects should have) an explicit 
risk budget - money included in the customer price but not allocated to 
any task. It is there for the problems you know from experience will 
arise from somewhere but can not yet specifically identify. The earlier 
resort, after polite clarification, is unyielding adherence to change 
management process. Where that process allocates the task to you, then 
you use risk money and hope you have not already dissipated it owing to 
estimation error. This is part of where risk management comes in. Since 
this money is in your price, it raises your price, so poor estimation 
(of risk as well as the base task) can lose you the job in one direction 
or set you up for later failure in the other. Another common error is 
spending the risk money too late; dribbling it out ineffectively, but 
I'm getting beyond a simplified discussion so I'll stop.

> 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.
snip
I sympathise with the point but as you said in the second paragraph I 
retained above, you just can not realistically achieve it. A 
multiple-cycle prototype and sign-off with re-estimation of further work 
is the most efficient way forward except that the customer will view you 
as laying all risk on them with no end to the budget, and want you to 
fix your price. It's a tension.

regards
David
> --
> 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)
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>