Project Methodologies and Project Failure

For years, project failure rates have been ridiculous. Various groups have published statistics showing troubled or failing project rates range from forty to eighty percent. People have asked time and again the primary reason for project failure and I repeat the same list so many have already stated—poor management, inadequate understanding of the goals, miserable communication, the list continues. However, I have discovered one problem common to every project I have recovered that I think is core to many of these generic observations.

Projects can be on-time, within budget, meet the specifications and still be a failure. Case in point, the new Dallas 160x72 foot mega screen. It seems the screen displays what it should, but is positioned a bit too low. So low, that on August 21st, the punter kicked a ball into it. Did someone forget the purpose of the stadium was playing football?

It is common that when I am called into fix a red project to have management assign all of the projects ills to one problem. As of yet, I have to see such a project. There are multitudes of problems deeply embedded in the organization and the project team to make a project truly crimson. Managers look at how the problems manifest themselves, skip diagnoses and assign blame. Prior to getting to the point of calling an outside party, they have tried to fix the issues by attacking these symptoms. This only makes matters worse and the project becomes a deeper shade of red.

The other day a friend said that there were three reasons for project failure. I took exception and stated there were two. As I thought about it more, there is only one. People are at the root of all failures, everything else is a symptom. Let’s look at some common reasons.

The project is over constrained. People set the constraints. If they do not understand the project well enough to set the constraints, or listen to the people that are suggesting the constraints, then they are the problem.

I sent a note to professional organization's program director the other day asking if their group would be interested in hearing about methods to increase project success. The organization was for a technical group that worked with data transformation—a skill set used in every IT project I have ever been on. The reply came in a prompt, succinct, and sarcastic reply:

"We [sic] you please tell me just how this would ever relate to the members of our group. You obviously do not understand that we are not responsible for running the project."

Why would anyone need to teach a group of managers how to tie their shoes? It seems improbable anyone could make it to this point in his or her career lacking this simple skill. However, I feel quite confident that a vast majority of project managers, managers, leaders, and probably you, are improperly lashing your laces. This prognostication will go one step further stating that even after proving a better method, they, and you, will be unwilling to put forth the effort to change. Adopting change, beyond just tying your shoes, is at the root of our inability to improve many of our business processes. Furthermore, studying this behavior and the subsequent difficulty of maintaining a new and better method will help us understand the high recidivism rate.

A project manager's job is to deliver value. Achieving the original schedule, budget, and features is meaningless if the customer does not receive value. As with all simple statements, this much easier said than accomplished. Projects managers must assemble adaptable teams that use flexible, lean methodologies. Arrogantly selling the latest technology or tool is narcissistic. Focus on the customer. Be vigilant at ensuring the information is always available for the customer to reassess the project's value and for the project team to reevaluate their proposal.