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!
So, how do we solve this age old problem? Well... that's another article!
1 comment:
Below is my reply to a statement in Linkedin which goes like this "Interesting article! But my opinion is over expecations and not adopting a realistic approach is the main cause of debacle of software houses."
And this was my answer:
Firstly, thank you for your comments. I can see that you are referring to software houses, and the approaches taken by the software houses. Well, I can assure you that the above article is about software engineering generally and does not relate to software houses OR software customer OR even software development processes. I can see you wrote that "over expecations and not adopting a realistic approach" as issues.
Well, not sure whose expectation are you refering to, but most of the time it would be the customer's expectation.
This definitely is an issue in Software Engineering. This relates back to what I wrote earlier. I always refer to civil architects for this, as I envy them a lot. For any civil engineering projects, architects are able to build an exact 3D replica of the blueprint, to the micro details, which provides the customers an precise of view of the end product (of what the customer will be receiving).
This is literally impossible in Software Engineering. There are various tools available for Software Architects, Software modelling, Wire-frame designing, and various other tools. But the issue with all these tools are that the end results are technical, and customers are NOT technical. So in a nutshell, customers are unable to visualize on what is to be expected, hence most of the time, by the time software is delivered, it is deemed to be not up-to the customer's expectation.
The above brings us to your next point, which is not adopting realistic approach. This is easier, as in Software Engineering, the approach would refer to the SDLC - Software Development LifeCycle. Well, it is sad to say that the age old SDLC, called waterfall model which was introduced in 1956 is stil being used till now. And even-tough we have many new processes like Agile, Rapid Prototyping, Iterative, Rational Unified Process, the problem still exists. None of these models are able to provide the customer an early view of what the system might look like. One of the best method which I have tried and tested, is actually developing a full click-able proof of concept system with all buttons and user interface components built in - but most will not agree with me on this, as the cost is high to get this done, and the requirements will have to completed upto 90% for such a POC to be developed. But thats a different article (Soon to be released - Ways to ensure your Software Project success).
Post a Comment