The area of project failure analysis, or reasons of why projects fail, is well studied. These analysis and corrective action plans are pure conjecture and less useful. There is only one root cause of failure the understanding of which will lead to a new development approach. This new approach will avoid failure and predict success.

Software entity, within the context of enterprise, is described in two aspects: essence inherent in the nature of software and accidents attending its production but that are not inherent. The essence of a software entity is a business concept: a construct of business processes, business rules, entities, relationships, algorithms, and invocations of business functions. This business concept is abstract in that such a conceptual construct is the same in view of different software technologies. It is nonetheless highly precise and quantitatively detailed and hence the "essential" property.

The accident of a software entity is the representation of the essence by means of computer languages in the form of graphic user interfaces, databases, components, middleware, and network protocols, etc. This representation is concrete in that such representation can be in many different ways subjective to IT workers' experience and preferences. It is nonetheless highly diversified and qualitative and hence the "accidental" property.

Essential properties are those properties that a thing must have to be that thing. A car must have an engine, wheels, and a transmission in order to be a car. A car might have a V-8 or V-6 engine, an automatic or manual transmission. These are "accidental" properties that do not affect the basic "car-ness" of a car. The essential property of a software entity is the business construct and the accidental property is the computer language construct. Essential property to accidental property is a one-to-many relationship. The former is objective and relatively stable, and the latter is subjective and relative volatile within the window of software life-cycle development. Essential property to accidental property is like a body to its shadow(s).

The hard part of software development consists of describing the "essential" property of the software entity, not the labor of representing it in software platforms and testing the fidelity of the representation. We will still make syntax errors, but they are fuzzy compared with catastrophic conceptual errors in most systems.

If this is true, the root cause of software failure is an attempt to construct the "accidental" property, the code, without first constructing the "essential" property, the business. Today's prevailing software methodologies build software based on the "shadow analysis" rather than the "body analysis." The arbitrary nature of the "shadow" (depending upon the location of light source, experience, and perspective) makes it difficult to capture the essence of the software entity.

Therefore, "shadow analysis" before or without "body analysis" is the only root cause of all software project failures. The desire to code first, the "hurry up to show results" syndrome all too frequently found in design situations, is one of the greatest sources of having "cost-regret" in design. Software failure can be eliminated if "body analysis" occurs prior to "shadow analysis." How to conduct "body analysis" before a "shadow analysis"? It requires a new understanding of software.