Why do development projects fail?

[Kent Sharkey]

Beta News[^]:

Based on a survey by Wakefield Research of 250 US software developers and architects, at a senior level within enterprises of 5,000 or more staff, it looks at the differences in goals, challenges and reasons for failure between business leaders and architects.

"No plan survives contact with the enemy."

Or management decisions

[trønderen]

One of my old Systems Engineering university textbooks provided an extensive list of reasons why projects fail. Every second point was "Poor planning". Then we got "Agile".

[Greg Utas]

Quote:

[S]oftware architects...cite a 'lack of intelligent tools' as the number one reason for failure....'[T]oo complex,' 'inadequate skills or training' and 'failure to accurately set expectations' all tied for the second most common reason.

Then build the tools, you whiners! The article talks about redevelopment more than development, and if management has agreed to that, it shouldn't be hard to convince them of the need to build tools that will increase productivity. The biggest reason for failure that I saw, multiple times, was trying to build a system that would replace a large one that had been around for a decade or more. This is virtually guaranteed to flush a ton of money down the toilet, because large systems grow out of successful small ones. The odds of success are low, even with skilled management and architects. And the fact they say they can do it means they have strong egos, and hubris is waiting.

Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.

[realJSOP]

Actually, the main problem with creating a new monolithic system to replace an existing monolithic system is that management doesn't understand the reason that it's being rewritten, which is to make it more maintainable and extensible. A given app rewrite can benefit from lessons learned with regards to past efforts to extend the existing version, as well as maintenance pain points regarding chosen architecture. However, those benefits are flushed down the drain when management thinks it's a simple lift-and-shift operation, and then realize it's like writing a whole new app (both the front-end and the back-end). They don't want to put the money into it, because "it works the way it is", despite the fact that maintenance tasks are taking longer and longer (and they fail to grasp WHY that's the case). Here's the way the conversation usually goes (and it happens every month or so): Management: "Why does it take so long to add such and such feature?" Dev: "Because the code base is 13 years old, and you won't approve a rewrite." Management: "How long will a rewrite take"? Dev: "One day." Management: "There's no money in the budget for that kind of effort. Let's just keep it the way it is."

".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013

[Dan Neely]

"plans are useless, but planning is indispensable." - Dwight D. Eisenhower

Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius