I got an email over the weekend from a friend of mine who's leaving Microsoft. I wasn't surprised to see him leave Microsoft, given that the every project he's worked on at Microsoft has either been cancelled mid-project or end of lifed in that release. After being at Microsoft for five years, I've now begun to see the signs that a project is likely to crash and burn early on. Below is a top five list of signs your software project is in trouble I compiled as part of my 'parting career advice' to my intern.

Schedule Chicken: This is typically a sign that the project's schedules are unrealistic. A project with unrealistic schedule is either an indication of poor communication between layers in the product team or even worse, bad management that punishes the messenger when there is bad news (e.g. poor initial estimation of project length). The main problem with schedule chicken is that you can be "date driven" or you can be "quality driven", you can't be both.

Scope Creep: Requirements changing as a software project progresses are natural. They can change due to feedback from the customer after they get to try out a prototype, due to changes in the competitive landscape or because the original requirements had hidden conditions which were not discovered until after implementation. When things get bad is when the goals of a project are changed or increased significantly without a corresponding significant change to the expected timeframe for delivery. WinFS merging with Object Spaces is my canonical example of scope creep at Microsoft.

Underresourced: You don't bring a knife to a gun fight. So you shouldn't expect that 3 developers and $50,000 will be able to compete with the Googles and Microsofts of the world. Similarly, if you work at a big company and you have a handful of folks working on a product where competitors have large teams or entire companies working on the same problem space, you're probably in over your head.

Second System Syndrome: Once you ship a software application, it instantly becomes legacy code. To a developer this means there is something newer and sexier that can solve the same problem in a more elegant way. Eventually a project is started which is intended to replace the existing product which customers are finding useful. This is often a double whammy. The new project is hamstrung out of the gate by having to meet customer expectations on backwards compatibility, performance and new features in comparison to the old product. This burden is often a crushing weight on the second system which eventually collapses under the strain. In addition, the old project is often abandoned or at best put in "maintenance mode" with only a skeleton crew working on it even though it pays the bills.