Why Software Engineering Fails!

“A Standish Group research report shows a staggering 31.1% of projects will be cancelled before they ever get completed. Further results indicate 52.7% of projects will cost 189% of their original estimates” 

“…such failures occur far more often than they should. What’s more, the failures are universally unprejudiced: they happen in every country; to large companies and small; in commercial, nonprofit, and governmental organizations; and without regard to status or reputation…” 

 

About 10 years ago, I remember reading at the pantry (of Motorola Malaysia GSG – my office then), that if there was any other engineering field, has had as many failures as Software Engineering, that field would have vanished from the face of the earth long time ago! But here we are, in IT/Computer Science/Software Engineering (what ever you call it), an ever expanding universe of techs, and taking over the NYSE like no one ever did before!

 

But why are there still such high rate of project failures in Software? 100 billion dollar question – some will say! Of course, there are many segments, mobile apps, embedded software, enterprise, etc…
Of course, more impact is felt in the enterprise section, because of the sheer size of the budget..

 

Reasons for the failures:

 

1. Software Requirements
If there was one reason why 90% of enterprise level software projects fail, that would be requirements.
Requirements is so important that we can never have spent too much of time in Requirements.
The best way to describe the requirements is in the below image (a picture is worth thousand words! – and this word deserves its own book!)

 

2. Software is not tangible
I have always told people that I envy the civil engineering architects. They are able to create an exact replica of what they envision, make it as a 3D model, which their “users” can open, look inside, upto to the micro level details as to what wood is used for the window frame, door material and color, or if even given time, even create a show room within few weeks, with brick and mortar, and give a taste of the actual invention to their “users”.
With all the technology/techniques available, currently, we are only either provide a proof of concept or wire frame or worse some models (use cases/activity diagram/object model, etc – which almost NO users will ever want to understand).

 

3. Time & Cost
This of course is a classic one. Time and Cost. As cheap as possible, and as fast as possible. Or at least I always hear this from my Asian customers. The western customer seem to pay more attention to the quality part, hence they understand that if they press too much of the time and cost, quality is affected.

 

And not having a solid requirements from the customers and software developers who are unable to model the software well, doesn’t help much. As when time and cost starts running, who cares about quality right? Its all about getting the User Acceptance signed off, and get the payment, right?
Well, that’s where the problem starts!