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.