Cold Case File: Why Projects Fail
May 6, 2003
By Paul Chin
File #A387: The victims are a five-month-old CRM, an eight-month-old ERP, and a two-month-old CMS. Although the three victims originated from different companies in unrelated industries, the causes of death suggest the same modus operandi. Preliminary examinations revealed signs of poor communication, internal politics, late project deliverables, and overrun cost estimations. The project managers and development teams in all three cases -- although not considered suspects -- are currently missing and wanted for questioning in relation to these ongoing investigations. (The identities of those involved are concealed for their own protection and will only be referred to as "project originators.")
The three victims described are textbook cases that can teach us a lot. The promising ideas and enthusiasm displayed during the kick-off meetings have boiled down to a single, dumbfounded sigh. Project members begin asking themselves the elusive "W" questions -- who, what, where, when, and the infamous "why" -- and throw in a few colorful expletives for good measure. The answers to these questions, however, may help us find the culprits.
What makes determining the causes of project failure so tough are all of the variables involved. Companies, teams, and projects have different sets of requirements and environmental factors that can influence outcome. Small and seemingly harmless circumstances can snowball and bring the whole project to a standstill.
"Project failure," however, is not synonymous with "project death." There are varying degrees of failure. The most extreme case, of course, is total project cancellation, and perhaps a few broken windows and bruised egos.
But a project can also be considered a failure if it deviates too far from original specifications, doesn't meet key user requirements, and is late or over budget. In the latter case, project failure is somewhat of a subjective issue -- one...