http://www.25hoursaday.com/weblog/2007/03/22/TopTenSignsYourSoftwareProjectIsDoomed.aspx
Raymond Chen has a blog post entitled You don't know what you do until you know what you don't do where he writes
I've seen a lot of software projects, and one thing I've learned is that you don't have a product until you start saying "No".
In the early phases of product design, you're all giddy with excitement. This new product will be so awesome. It will slice bread. It will solve world hunger. It's designed for everybody, from the technology-averse grandmother who wants to see picture of her grandkids to the IT manager who is in charge of 10,000 computers. It'll run equally well on a handheld device as in a data center.
When I see a product with an all-encompassing description like this, I say to myself, "They have no idea what their product is." You don't know what you do until you know what you don't do. And the sooner you figure out what you don't do the better, because a product that promises to do everything will never ship.
In my five years at Microsoft, I've seen a bunch of projects fail. Some were public flame outs that are still embarrassing to mention today while others are private mistakes that you'll never hear anyone outside the b0rg cube mention. A few months ago I wrote a blog post entitled Top 5 Signs Your Project is Doomed and since then I've considered a few more entries that should be on the list bringing the total to 10. The list below are common signs that a software project is doomed. Meeting one or two of these criteria isn't necessarily the kiss of death but three or more and you might as well start circulating your resume.
-
Trying to do too much in the first version. See Raymond's point above.
-
Taking a major dependency on unproven technology.
-
Competing with an existing internal project that was either a cash cow or had backers that are highly placed in the corporate hierarchy.
-
The team is understaffed. If you have less people than can handle the amount of work you have to do then the right thing to do is to scale back the project. Practically every other choice leads to failure.
- Complexity is one of the goals of the project because "complex problems require complex solutions".
-
Schedule Chicken
-
Scope Creep
-
Second System Syndrome
-
No Entrance Strategy. When a project can't articulate how it goes from a demo or prototype to being in the hands of end users, there's a problem. This is particularly relevant in the "Web 2,0" world where many startups only strategy for success is getting a mention on TechCrunch and the fact that their service has "viral" features.
-
Tackling a problem you don't know how to solve. It's pretty amazing how often I've seen this occur.