Monday, 28 September 2009 00:00

People: Common Failure Symptoms

Rate this item
(0 votes)

In daily talks and presentations, I am often asked what the most common reasons are for project failures. I usually turn the question around and ask people what they think. It is a fun exercise and people list a mixture of symptoms and sources. As mentioned in the previous blog, one must drill past the symptoms and get down to the problem itself. It is my firm belief that most project problems are rooted in the people, however people are creatures of habit.

For conversation purposes, it is handy to classify the common problems into three categories—team, process and customer (see Table 1).

Team concerns are usually communication, attitude and motivational, skill set, internal scope creep and interrelationship problems. To address these takes a soft-skills approach. Training in organization development and working with difficult people is a great plus (more on this in an upcoming blog).

Problem Area Symptom


Attitude and motivation
Internal Scope Creep
Skill set


Risk Management
Change Management and Scope Issues
Estimation and Scheduling


Difficult, trying to get something outside of scope
Incomplete understanding of product (manifesting as scope issues)
Lack of Project Management (manifesting as scope issues)

Table 1: Major Failure Reasons

Internal scope creep is a nasty beast where the team is increasing scope by suggesting features to the customer. This requires close involvement with the team and training on the results of expanding scope. The root of this is the inability of the team members to say "no." The Project Manager needs to step in and use all means to correct this behavior.

Process problems are relatively straightforward to solve. They are:

  • Change management and scope control;
  • Document coordination;
  • Estimation and scheduling;
  • Risk management.

The worst of these to fix is a broken or misapplied process. The reason? A process has followers and people who believe in it—they have read it in a book, someone has told them they have to do it or they are unwilling to move away from it since it is their comfort zone. Changing the process may be more like changing the culture. Results change a culture, culture does not change results. Show results and the organization will follow.

Customer issues come in a variety of shapes and sizes but many times the solution is training the customer in project management techniques or their product. It may also require educating the project team in the customer’s way of doing things. This is especially true in international projects. The most common problem is a customer’s lack of understanding of the product. This may be solved by implementing a better change management process or moving to an Agile methodology. Poor Project Management skills can only be solved by education of the customer.

Regardless of the issues, it still takes drilling down to find the source. The project audit finds the symptom and project analysis finds the root cause. After identifying the source, it must be fixed and the people need to buy into the solution and help implement the changes. Identification is just the beginning of the work.

Read 11221 times

Related items

  • Success vs Culture

    The other day a Latvian student contacted me for my views the connection between culture and success criteria—an important and intriguing topic. After working in Taiwan, Singapore, Korea, Japan, Israel, United States, and Canada, I wear many scars of both blatant and subtle cultural violations. I also know that within a culture one person's success is often another person's failure. So, after dispelling concerns about clicking on some random email link, I completed her survey (please feel free to take it yourself). In the process, I struck up a friendship with the student, Kristine Briežkalne, who is studying at Riga International School of Economics and Business Administration . She has some interesting views and presented me with a Venn diagram showing four frames to a project (business, client, project management, and growth perspectives) and how they intersected. As the diagram is part of her Master's thesis, I will let you ponder the how to label the overlapping areas (an eye-opening exercise).

  • Kill The White Knight

    There is a reason we do not teach classes on fixing failing projects. Many a cynic feels that we simply do not want to teach our trade, however, our reason is far nobler—we should be teaching prevention rather trying to create white knights to save the day. It is the same philosophy as building a fence at the cliff's edge rather than an emergency room at its base. Our language is replete with idioms telling us to look past the symptom and address problems at their root cause. 'An ounce of prevention versus a pound of cure' or 'a stitch in time saves nine.' Please, feel free to supply your own in the comments. Unfortunately, most of our businesses loathe this philosophy, waiting to address an issue until it is irrefutably broken.

  • The Executive-Project Manager Gap

    It was such an innocuous question, "Working on an article; what is the biggest problem you see with project governance at orgs? Can you comment?" Can I comment? Really? That is like cheese to a mouse. Where could I start—bureaucracy, draconian process, poor executive sponsorship, disengaged leaders? Plenty of fodder, because they all lead to project failure. I fired off, "Creating an over bureaucratic morass stifling innovation & implementing process instead of cultivating leaders." Then the maelstrom started and it went directly to the gap between the executives and projects managers. Naomi Caietti, Robert Kelly and I had a great conversation. Most of the thread is below.

  • Disband Your PMO

    After nearly 30 years of project work, I struggle to understand the role of a project management office (PMO). Even though, I have written of the pros and cons, and read a plethora of articles, opinions, and how-to guides little has been done to convince me that the PMO is reducing project failure. It seems to be nothing more than a tool to fill a void in leadership? Even the acronym, which is so widely thrown around, has little meaning as the "P" has no less than four meanings. It is an executive's crutch for their lack of understanding in how projects work. These, like other, unattended holes in the corporate accountability create opportunities for new and greater bureaucracies and empires that further obfuscate accountability.

  • The Catch-22 of Organizational Change Management

    "Kotter, ADKAR, or CAP which methodology should we be using to build our approach to improving project adoption?" I hear this question repeatedly from people trying to implement an organizational change management (OCM) program. The problem is that is the wrong question. Take a perfunctory peek at any of the models and you will see that in the quest for an answer people have mistakenly jumped over the first few steps and they head down the road of failure. It is a Catch-22; unless you already have an OCM process in place, you will most likely fail at implementing it. Putting one in place, however, is a change—one of the most difficult cultural transformations your company will undertake. As a result, people jump to the solution stage, which is well down the change management process path (which, they did not know, ironically, since there was no procedure in place).

Leave a comment

More Info on Project Recovery

Tell me More!

Please send me more information
on fixing a failing project.

Rescue The Problem Project

Internationally acclaimed

Image of RPP

For a signed and personalized copy in the US visit the our eCommerce website.

Amazon logo
Buy it in the United States Buy it in Canada Buy it in the United Kingdom
Buy it in Ireland Buy it in Germany Buy it in France
Buy it in Italy Buy it in the PRC
Buy it in Japan
Book sellers worldwide.

Upcoming Events

Other's References