I found it interesting that his list of reasons why the project might fail sounds like pretty much every project I ever saw in the 1990s and early 2000s. Althou

I found it interesting that his list of reasons why the project might fail sounds like pretty much every project I ever saw in the 1990s and early 2000s. Although some of them are definitely bad signs, some are just par for the course in organisations that arent big on software development. I wouldn't say its a guaranteed failure. He might just be unfamiliar with what real-world projects are like in an enterprisey environment. - deadline approaching many of the must-have features are not finished. - Application is unstable and very difficult to use. - System is very convoluted, code very hard to understand, very difficult to change. - complex relational database (100+ tables). - Unclear leadership, the manager responds to every new information with significant change in plans. - Almost no automated tests or unit test. - Heavily depends on other systems, but no integration tests yet. Perhaps upper management will fudge and extend the deadline (rather than be embarrassed) and the project will limp towards some sort of closure that everyone can just about accept.