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.

1. 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.

2. 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.

3. 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.  

4. 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.  

5. No Entrance Strategy: There is a lot of talk in the software industry of exit strategies but a lot of the time software products do not have an entrance strategy. How do you get people to use the application? How do you get the first 100,000 or 1 million users? Sometimes in big companies, there is also the corporate strategy tax to consider when deciding whether a product has an entrance strategy or not. When I was on the XML team at Microsoft, there were folks on the team working on a project they called X#. The project was basically C# with extensions to handle relational and XML data access as operations native to the programming language. I attended an internal presentation about the project and when asked what the deliverable from the project would be, the team members actually showed a Photoshoped image of a Microsoft Visual C# box which read Microsoft Visual X#. Of course, this was at the time Microsoft was taking heat for introducing both C# & Visual Basic.NET at the same time. It was unlikely that Microsoft would ship a third similar language anytime soon. The project was killed, resurrected  and morphed a couple of times. The story eventually ended happily with a lot of the innovations in the language eventually showing up as .NET Language Integrated Query (LINQ) (aka C# 3.0). That was one instance with a happy ending, a counter example is the new file system for Windows being cancelled a few years after it was announced to be shipping separately from the operating system. A file system that doesn't ship with the operating system doesn't sound like a product with an entrance strategy to me. How about you?