Six Reasons for Software Project Failure

IEEE Software, September/October 2002, page 97.
Barry Boehm writes:

Larger surveys covering over 8000 projects (see indicate that the major sources of software project failure lie less with shortfalls in formal methods skills and more with shortfalls in skills to deal with stakeholder value propositions.

The top six reasons for failure were
  • incomplete requirements,
  • lack of user involvement,
  • lack of resources,
  • unrealistic expectations,
  • lack of executive support, and
  • changing requirements and specifications.



Note that none of these reasons speak to languages, or development environment. or hardware choices. Five of the six have to do with communications between builders and stakeholders ("Clients" or "Users"). They have to do with processes for determining:
  • what is desired,
  • what is needed,
  • what is possible,
  • who knows,
  • who decides, and
  • what of these is not evident till the system is implemented.

So mechanisms and methods that can draw out this information at the beginning of a project, and keep addressing it thoughout a project, are critical factors for a successful project. And without them, the project is at great risk.

Building architecture and construction has the benefit of several thousand years' worth of experience and accumulated wisdom. The software industry barely has fifty years under its' belt. So a software project is largely
   The First Time It Has Been Done This Way.

Otherwise you could install an existing product, or keep on using the old one. Communicate. Communicate. Communicate.