A lot of people have been commenting that the customer is important, and without customer input the project will fail.
This is true, but if you’re developing a general product to be consumed by many customers, it becomes difficult to know what is the right feature-set to develop, and to develop a product that will be acceptable to the target market.
This is where Product Management and friends step-in to research product requirements based on Marketing requirements. Now if the PM fck up because they don’t know what features the customer really wants, the software product (not project) is dead. And it’s easy to fck up primarily because it’s hard to get a feel whether feature X is useful to 10 customers or 1000 (you want the latter because == $$$ revenue). And this is regardless of the fact of how the software product was developed.
What’s worse than a dead-product is that Marketing decides that the company really needs the dead-product since they shipped it to 10 customers (and it looks good on a power point slide to partners). So now developers not only have to keep the dead-product alive, but have to maintain it forever on newer code-bases and keep it backwards compatible.
Large software projects fail for many reasons, but I will throw my $.02 cents in here. Part of the problem is that the bar for quality is binary: Works (1) doesn’t work (0). Works really well (3?) doesn’t exist. a 100 “else if else if else if” statements might work, but it clearly is not flexible and is difficult to maintain. Will you ever be given time to fix it? Nope. Why? “If it ain’t broke, don’t fix it?” (insert similar logic of choice).
The problems with software are institutional. Imagine if Intel released HW that had as many critical bugs as Windows? Intel would be sued broke. But, for some reason, there is no such storm for years of buggy software – and not just from MS.
Another problem: Price. Releasing bugged HW is nearly impossible to remedy once it’s out the door – and requires a fortune when it has to happen. Software: “We can always issue a ‘hot’ fix”
Boils down to this: There is no incentive to produce good code other than your own pride.
For several years now, I am using a different fundamental approach to estimating software projects by targeting specific risks that plague most projects: choice of development tools, QA inflation, infrastructure inflation and red tape, policies applied to the project before project is even done (“speed bumps”), VM inflation (VM cuts the developer’s productivity in half because it is horribly slow for server-side development), “big bang” releases (often, iterative releases look like “big bang” releases because of unrealistic expectations midway through the project… final thing to avoid is tasks inflation. Why does every development task have to be broken down to quarks (or even protons and electrons)? If you have two things to do that don’t do much on their own, why not put them together in the first place and cut down QA inflation?
I’ll simplify it for you: 78% of IT projects with a staff budget of less than $500k succeed, while only 3% of projects with a budget of greater than $10M succeed. Keep your project small, dividing into distinct sub-projects if needed.