Why Projects Fail

[David Vaughan]

On Monday, March 25, 2002, at 04:21 , Rob Cozens wrote:

>> My point, however, had little to do with whether or not we are 
>> discussing powerful programming mechanisms. I said they were and was 
>> careful to point out my own familiarity and pleasure at using them. 
>> However, my day job includes finding out why $MM projects are off the 
>> rails and trying to fix them both technically and commercially, and 
>> the techniques you are describing are not industrial strength, are not 
>> tolerable in enterprise software development. This is the history of 
>> the last 20 to 30 years of software development tools. Go ahead and 
>> use them for a stack, debug the hell out of it and you will probably 
>> have a very sweet application to offer. Just please don't tell me that 
>> this is the the way we should present as a standard set of development 
>> tools or techniques.
>
> David,
>
> I'd very much like to learn more about the conclusions you've drawn 
> from your investigations.  If other List members are not interested, 
> let's take this off list.  However, I think a discussion of what you've 
> found could prove helpful to all; so I've started a new thread to see 
> if anyone else is interested.
>
snip
>
> 5.  I have worked primarily independently or with one assistant; so I 
> can only project the dynamics of large group programming projects.  I 
> suspect some of the problems you've investigated may stem from there.

This is the first of two posts on the topic. I need this one so I do not 
give the wrong impression of why projects fail. The most common reasons 
could be called commercial rather than technical. The post straight 
after this one will talk about languages and coding.

If you want to trot down to the library, you might read are Ed Yourdon's 
"Death March" Prentice-Hall 1997 or on methodologies there is the 
somewhat patchy but interesting DeGrace and Stahl "Wicked Problems, 
Righteous Solutions" Prentice Hall 1990. Capers-Jones' "Applied Software 
Measurement" McGraw-Hill 1996 is worth a look for the effects of 
different software tools on productivity, and probably helps account for 
a bias I just might have against C and its derivatives, and admiration 
for the xTalk products among others. There are many other works in veins 
similar to those mentioned above.

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.

Poor project management might equally be seen as causal of the above as 
much as exacerbating those problems. In any event there will almost 
certainly be failure of the contractual relationship in that it will be 
brittle. The project manager and customer will appear to others to be 
friendly but will agree about nothing, like a failing marriage; they can 
no longer resolve contractual issues so as to make progress. A concept 
of triage helps here.

These are large projects (more about that in the next post). DeGrace and 
Stahl suggest (they never assert) that the most productive software team 
comprises two to four people, so many of you here will be in a 
near-ideal position. However, contrary to some rumour that "large 
projects can never finish" studies I have done of reported completions 
show no productivity difference as the scale goes from medium to very 
large. Note that this ignores small projects and non-completions - it 
looks only at productivity.

If you are contracting to do a specified development for a client rather 
than developing own product for market then I suggest you not be shy 
about your contractual rights and obligations, and put serious work into 
estimation and into prototyping and actual sign-off, in writing, on 
micro-stages of your work. Pay and support staff who are genuinely good 
and get rid of those who aren't. Select productive tools early and stick 
with them only.

In general, issues other than the tools are more important in the 
software failure picture but tools themselves have a crucial impact on 
immediate productivity and on longer term maintenance. So, on to the 
topic of more immediate relevance.

cheers
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
>