Most project failures are not failures of programming skill or technique. The blame lays pretty squarely on a failure of judgement when applied to risks. This is the blog form of my presentation for the eCLA Summit 2017 in Vienna. i.e. it's (words and pictures) - (messing around with microphone and accidental sweariness)
So kicking off we see our shadow man walking right into a risky project, ignoring the dangers and ending up battered with radiation poisoning and limbs missing.
And I've run a few projects in this manner!
An example cited to emphasise the point was...
If a customer gives you some hardware, do you quote based on it doing the job?
What if it doesn’t?
We have often been given hardware new to us, and quoted time with no contingency. The assumption that this new hardware will operate flawlessly is ALWAYS incorrect. A L W A Y S!!!!!!!
The following graph was used to discuss delivery times.
The Jan 1 point is called the nano-probability point, it is the first date where there is a nano% chance of the project delivery happening. So it would be unwise to quote Jan 1 as the delivery date wouldn't it?. Looking at May 1 you have the greatest probability of delivering on this day, but looking at the area under the graph you will still have more chance of failure than success (this is typically 30% of area under the graph). July 1 is actually the 50% point.
This graph came from Waltzing with Bears (Tom DeMarco & Timothy Lister) and brought home to me how many times I was quoting the nano% point as the "earliest" possible delivery date. It's possible, just not very probable.
You can avoid risk by not taking on challenging projects and in my opinion this was a life diminishing choice. All good things come from risk!
Or you can manage risk, like what grown-ups do....
Looking at the Denver Airport Baggage Handling System as a great example of various software factors being blamed for a projects failure, when in fact it was just poor judgement.