These are all symptoms, the cause is incompetent management every time.
Bad requirements capture usually means management has assigned too much weight an analyst who has no talent.
Then the smart people leave, its clear from early on if a project will fail, they want to leave with a CV full of success.
Schedules slip, but that's not because developing software is hard, it's not, it's easy. They slip because nobody wants to rush ahead to hit the dead ends. There is no win in that situation, when you hit the dead end, *you* will take the blame for rushing ahead, as if the dead end isn't there if you don't reach it!
Planning, is meaningless if the project will fail, why rush... milk it.
Risks, well I've even had one manager who had such poor control of a project, any meeting in late beta cycles could send the spec wildly off at a tangent.... this is a guy who really knows how to snatch failure out of the jaws of success.
There's a sort of gap, one the one hand the code says one thing, the computer works a certain way and it needs to be correct because you can't fool a computer. On the other, the management *believes* the code works in a *different* way. They convince themselves their requirements capture was correct. They convince themselves the code so far is fine, and that the process will lead to success, even if every step fails.
Discussion on:
Message 1 of 1
The best of ZDNet, delivered
ZDNet Newsletters
Get the best of ZDNet delivered straight to your inbox
