Why software projects fail

I would say that software projects fail for the same reasons why all the rest fails, too. People are badly organized and overwhelmed by the number of e-mails coming in, the amount of work distributed to them and all other requirements.
Instead of organizing better and working harder, people survive by "setting their own priorities" and "thinking positive and not allowing others to put pressure on them". With the result that e-mails are not answered and people do not even feel guilty for not answering. They have lots of excuses like "the header did not say it is important" or "if an e-mail is not announced by a phone call, I consider it to be not important". Many tasks distributed on people are not done, endangering the success of a complete team´s project. Here, again, a lot of strange excuses are acceptable like "I was told only once. So, I could not know that my results are really needed" or "I saw that you all work a lot, so I thought that someone of you might have done it already".
Anyway, stress is an excuse always acceptable. And who of us has no stress?
Well, OK, back to work. I have a deadline today.
steppenhund - 7. Mär, 13:14

One could mean, that the reason for failure is only human. But there is a deeper cause that stems from the very early days of programming.
A software project includes programming. And programming necessitates knowledge about what you are wanted to program. Eventually there must have been a wish that something will be done by the computer.
But people can't express their wishes.
You just have to watch people when the have to order something to eat from the menu card. It is easy if you only have to select between a hamburger and a cheeseburger. However, when you have to choose from 100 fancy dishes set up on 6 menu pages, some just can't make up their mind.
Ambiguity, Contradiction is the result in requirements when you have the feeling you can wish for everything. - why do I say so? I claim this to be having been a witness to a change of the human mind during the early 70s. Before that requirements (or specifications) were vital and had to be considered before a production started. Once the microprocessor stepped in, people neglected to think about exact requirements. "We will sort that out later. It is programmable!" We nowadays know that changing a software system is quite tedious and requires a heavy workload. But in our minds we still have imprinted: "We will think about that later."

AndreaHerrmann - 9. Mär, 16:24

Yes, these are two problem fields: knowing the requirements and working in a team. The menu makes choices easy. You need only to choose from a list of dishes. Asian restaurants with 200 dishes (=combination of 4x4x12 main ingredients) are extraordinarily difficult. Here, I do not try to read everything but take the first one that strikes me. Imagine, you could design your own meal!!

Nevertheless, it is not always the customer´s fault when the team does not manage to fullfill the requirements.

User Status

Du bist nicht angemeldet.

Aktuelle Beiträge

Survey about creativity...
In order to study about innovation and creativity during...
AndreaHerrmann - 29. Aug, 14:09
Report about the CreaRE...
Here, now my report about the CreaRE 2018 workshop....
AndreaHerrmann - 5. Apr, 17:21
Back from REFSQ: first...
I am back from REFSQ. You definitively will get some...
AndreaHerrmann - 23. Mär, 14:07
call for participation:...
call for participation: Seventh International Workshop...
AndreaHerrmann - 18. Dez, 21:00
Oh, sorry, Ihren Beitrag...
Oh, sorry, Ihren Beitrag sehe ich erst jetzt! Das Programm...
AndreaHerrmann - 18. Dez, 20:58

Links

Suche

 

Status

Online seit 5009 Tagen
Zuletzt aktualisiert: 24. Jul, 02:02

Credits


Profil
Abmelden
Weblog abonnieren
development