the seeds of failure are all too obvious, at least with the benefit of hindsight. The two warning signs that really jump out are the absence of any coherent statement of requirements or goals (note, for example, that the notion of performance appears to have been an afterthought) and the fact that the team chose a technical approach they had few qualifications for—namely, writing PC software while avoiding any use of Microsoft technology.This article also points to another reason why this failed product fails:
effort quickly turned into a matter of technology looking for a problem to solve (an all-too-common occurrence)What had been identified by Peter are the cause of failure in my experience. It is not a RIA but a .Net application which ended up best summed up as a .Not application (Not a .Net application but a half-baked one). In this case it was faddish to be a .Net application so they need one! This failure contains many lessons that are worth exposing and will be covered in future blog posts.
In my situation, there required no hindsight to know the right atmosphere for failure; the foresight was arrogantly rejected prior project began; the management was too amateurish and haughty to ask for advice and to receive any. Their steadfast refusal to recognize their failure causing the company huge amount of ongoing waste and their customers excessive expensive run time resources as well as missed opportunities. The resultant is a big embarrassment of a comatose .Not product.