paulchinonline.com

Cold Case File: Why Projects Fail

By Paul Chin

Originally published in Datamation (06-May-2003)

back back to portfolio


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 person's success may be another's failure.

So, to begin our investigation, let's ask this not-so-simple question: Why did those three projects described in our Case File fail when other similar projects succeed?

There is no one answer. While it would be so much easier to ignore the problem and resort to some superstitious magic formula—lying prostrate before a two-foot garden gnome or sacrificing a rubber chicken—to make the problem go away, this is not the way to handle it. You need to understand why the project failed in order to prevent it from happening again. Otherwise, you'll be stuck in a vicious cycle, making it more and more difficult to convince management to sign-off on future project proposals.

The list of reasons for project failure is a long one, but after we've gathered all the evidence from the lab, we can conclude that the main causes in all three cases mentioned above stemmed from:


Setting an Overly Ambitious Project Scope

It's essential to understand that there's a compromise between what you want to accomplish and what you're actually able to accomplish. An overly ambitious project—when goals exceed your ability to deliver timely results—was the silver bullet that undid our victims.

The project originators came to the realization, halfway into development, that they overshot their ability to deliver what was promised. After that, their once analytic mindsets quickly dissolved into survival mode. And when this happens, critical project decisions are made with a "deliver-at-all-costs" mentality. They figured that too much money was already poured into the project and believed that it was too late to turn back. They pushed forward simply to have something to show for all the time and money that was invested.

The result was an unreliable and bug-filled product, rushed through to meet a deadline they never had any chance of meeting from the start. To compound the issue, key user requirements had to be dropped to accommodate an overly aggressive schedule. User confidence in the systems was shaken and it never recovered. The projects were eventually abandoned by the users they were meant to support and cursed by management who was left with the bill. The originators' woes began with the three most common scope mistakes:

Cliches about biting off more than you chew are cliches for a reason—because they're true.


Lack of Project Methodology

The lack of project methodology—a road map from conception to completion—forced our originators to make on-the-fly decisions, based more on gut reactions than factual and objective analysis.

Instead of following a well thought-out route, they ended up going in circles, getting lost, and hitting countless roadblocks. Taking this type of unstructured approach will lead to unstable results because things rarely fall into place by themselves. These projects didn't have a firm footing at the very beginning so what chance did they have in a production environment?

Methodology varies greatly from project to project, taking into account environmental factors and project specifics. And, of course, methodology is relative to the size of the project. The bigger the project, the more important it is to have this road map. But regardless of size, every project methodology must address three core issues: planning, development, and implementation. By following a pre-defined set of guidelines and a migration path, you have something concrete in which to reference and measure progress.


Poor User Input and Requirements Gathering

Nothing kills projects faster than giving users something they didn't ask for and then pretending they did. The IT teams associated with our three victims were given a vague and informal set of requirements—probably something sketched out by hand or mentioned verbally in passing—and they, in turn, didn't bother to follow-up with the users or ask any questions.

Instead, our intrepid developers vanished in a thick cloud of smoke only to reappear three months later asking, "So, was this what you had in mind?"

This lack of user involvement caused a great deal of resentment among the corporate user-community and the projects were seen as something forced upon them by developers who only wanted to test out their new toys. Don't forget that systems are built to support the end-user, not the developers.

Requirements need to be worked out on both sides because there's a symbiotic relationship between users and developers:

Our victims lacked a formal set of project specs and too much was left open to interpretation. The developers ended up delivering what they thought their users wanted rather than what they actually needed.

Before we move on, there's one note of caution about user input and project requirements that bears mentioning here: Beware of scope creep. This is the name given to the constant "morphing" of the original project specs, turning any well-planned project into a runaway Frankenstein's monster. Stick to the specs—major revisions to project scope should be addressed in later releases.


The Lack of Support from Senior Management

You don't need to be a detective to know that few projects have any chance of getting off the ground without the support of those high up in the corporate food chain. Aside from the obvious fact that they're the ones signing the checks, it's also a matter of perception.

Non-sponsored projects like our three unsuspecting victims are taken less seriously and may sometimes be viewed upon as someone's self-interest pipe dream. Without the backing of senior management to lend credibility to these projects, our originators had a difficult time recruiting employees to participate in development and testing. Why? Because teams are usually made up of people from different departments who all have their own set of priorities. And, of course, they all have their own bosses. It would be tough to justify participating in an unsanctioned project with the twenty other tasks already on their plates—no mandate, no effort.


Poor Interpersonal Skills

Our victims fell prey to one of the most unfortunate and entirely preventable causes of project failure—forgetting about the human factor. Its impact on a project's outcome is unmistakable but often overlooked.

The three most notorious suspects to be wary of in this category:

A project will only be as good as the people and effort placed behind it. Our victims—high visibility, enterprise-wide projects—required the skills, input, and knowledge of multi-disciplinary personnel from various departments.

The teams in these cases lacked the ability to work as a cohesive unit and were in constant disagreement. The arguments and infighting caused everyone to move in opposite directions, lowered morale, and spawned an "us versus them" attitude.

It's natural that those involved in any project will have the tendency to keep the best interests of their own department in mind. And there's nothing wrong with that. In fact, it's why they're on the team, to represent the needs of their department. However, the risk is in having any one person or group hijack the project and run away with it, ignoring all other requirements.

Remember what your parents used to tell you about playing nicely with the other kids? Well, the same principle applies here, and it's imperative that everyone works together toward a mutual goal. It's simple: Dysfunctional parents raise dysfunctional kids.


Case Closed?

No matter how well you plan your project, however, there may be times when a project is cancelled for reasons beyond your control such as changes in management or priority shifts. But too many projects have failed because of foreseeable circumstances. So keep your eyes open—I don't want to have to come by to draw a chalk outline around your next project.


Copyright © 2003 Paul Chin. All rights reserved.
Reproduction of this article in whole or part in any form without prior written permission of Paul Chin is prohibited.