Project Management
PMI Sites
Join the Conversation on Artificial Intelligence
Register
Search

The Top Ten Reasons Projects Fail (Part 7)

Frank Winters has more than 30 years of consulting and Information Technology experience serving as a project/program manager, consultant and IT service industry executive.


So far this series has discussed five of the top ten reasons for project failure. The series has a companion discussion thread that some ganttheads feel is even more interesting than the articles themselves. The reasons for project failure are many and varied, and most are mentioned in the thread.

 

Before continuing with a discussion of what's next on the Top Ten List--poor effort estimation--let's use this mid-point as an opportunity to reflect on what is meant by project failure.

 

The list is designed to get folks thinking. It seems that most PMs have opinions regarding the causes of failure and enjoy articulating them. Anybody's top ten list is a good place to start a discussion. But in this case I'm the writer, so we used my list to start with.

 

As a reminder, here's the list of The Top 10 Reasons Projects Fail:

  • Inadequately trained and/or inexperienced project managers
  • Failure to set and manage expectations
  • Poor leadership at any and all levels
    ADVERTISEMENT

    Trending Articles

    JA Worldwide: Project Management for Good

    by Howard Leong

    In support of PMIEF’s global youth serving non-profit partnerships, PMI and PMIEF continue to highlight the exceptional student project managers from regions all across the world. Here a student shares his experiences with JA (Junior Achievement) Worldwide.

    The Downside of 'Tough it Out'

    by Lonnie Pacelli

    Trying to "tough it out" at the expense of your health and well-being not only doesn’t make good sense, but can be harmful to your work, your colleagues, your loved ones, and yourself. Get help recognizing the warning signs.
  • Failure to adequately identify, document and track requirements
  • Poor plans and planning processes
  • Poor effort estimation
  • Cultural and ethical misalignment
  • Misalignment between the project team and the business or other organization it serves
  • Inadequate or misused methods
  • Inadequate communication, including progress tracking and reporting

I stand by this list as probably as good as any, but far from absolute. In fact, lately I'm thinking more about the importance of culture as an influence on project management success or failure. Culture is reason No. 7 in the original list. If I redo the list at some point, I'll probably move culture up a bit.

 

Success and Failure Defined

One popular topic in the discussion thread is the definition of success and failure. How do we know when a project is one or the other? Some of the more obvious ways of measuring success follow:

  • Has the project satisfied the business requirements of the primary stakeholders?
  • Were the deliverables produced on time and within the budget (as amended by formal change control)?
  • Do the business owners believe the project was successful?
  • Has the project delivered the business value promised?

Sometimes the operation is successful--but the patient dies. In the realm of projects this might be a project that satisfies all the criteria of success but still carries the stigma of failure because that's what people think it is. People in business have been saying perceived is real for many years.

 

So if stakeholders, financial types, users, business people, peers and superiors think your project has failed, it has. Late projects, projects over budget, projects that don't deliver the business value they promise, and of course projects that deliver the wrong thing--these are all failed projects. That is unless these failures are not perceived as failures.

 

Sometimes it's a matter of having a good enough excuse for failure in an environment/culture where really good excuse-making is appreciated. Sometimes it's a matter of being in a company or other organization that has very soft measures of success.

 

What Is a Project?

In many ways, the measure of project success or failure has a great deal to do with how projects are defined. PMI's Project Management Body of Knowledge defines a project as follows:

 

"A project is a temporary endeavor undertaken to create a unique product or service."

 

In most businesses, there are only a few distinct kinds of activities. Businesses activities are most often either part of an ongoing operation or they are part of a project.

 

Any developmental effort, particularly systems development, is usually a classified as a project. On the other hand, if an activity is part of the routine transaction processing and record keeping involved in maintaining a business, it's part of an operation rather than a project.

 

Research and development or data analysis activities such as sales analysis and market research could be classified as either operational in nature or as part of a project. The distinction here is somewhat arbitrary but has to do with whether the activity is repetitive and continuous or has a well-defined beginning and end.

 

Organizations that successfully use project management disciplines know exactly how rigorously they mean to apply the disciplines and how to measure success. PM disciplines can be applied to operations or projects.

 

For example, a project can be created to improve the quality of products coming from an assembly process. The assembly process is operational, while the improvement effort is a project.

 

In many organizations the distinction of operation versus project is unclear, as are the measures of success. If this is true, the PM needs to seek clarification from his management.

 

If the management team can't decide, the PM is left with no choice but to declare that the nature of the activities is either a project or not a project. In either case the manager needs to also declare what she thinks the success criteria are and seek corroboration from the stakeholders and managers involved.

 

In this sometimes murky definitional water, it's important to remember that ambiguity will not serve anyone well.

 

The Spectrum of Failure

Project failure is measured across a spectrum. On one hand there are the clear failures:

  • No value for money delivered--nothing was delivered and all the money and time spent have been wasted
  • The wrong thing was delivered
  • The delivery was so late as to make the product useless
  • The product quality was so poor as to make the product useless
  • The project cost so much more than planned making the product financially not viable

Each of these clear failures can be seen along a spectrum moving from complete failure to complete success. For example, a high-quality product that meets the business need exactly and is delivered early and under budget is almost always perceived as a complete success.

 

This is true unless there has been a catastrophic political failure. If the stakeholders don't know that the project has lived up to or exceeded all its promises and something goes wrong that is unrelated to the project itself, it is possible for the project to be unfairly blamed.

 

How to Avoid the Perception of Failure

To avoid the perception of failure, it's not enough to succeed--but it's a start. Here is some advice regarding dodging the perception of failure. Define the boundaries of your project well, including:

  • when it starts and ends
  • how much budget it has
  • what its goals and deliverables are
  • who the stakeholders are, and what benefits they expect
  • what level of quality is required and how quality will be measured

In addition, the change control process must be well defined and executed.

 

Finally, make sure the stakeholders and other important interested parties such as management know that what you are doing is in fact a project with expected results that will benefit many of them. Use the well-defined project boundaries to build an appropriate level of expectation.

 

Then deliver within the boundaries and meet or exceed the expectations you have set.

 

Finally, and perhaps most importantly, make certain everyone who should know does know about your success. Don't let false modesty deter you in this regard. The public relations/political aspect of perceived project success can't be overlooked or your project could be misunderstood (a terrible fate for a successful project!).

 

The PR needs to be done tastefully, with a degree of humility and at the correct decibel level. These factors will vary from organization to organization, so you must know your organization before you launch your PR campaign.

 

Summary

Much has been written about the ambiguities associated with such things as what is a project, how do you measure success, and who needs to know what. This perception of ambiguity is caused primarily by the different corporate cultures and degrees of maturity regarding project management and general management practices found in organizations.

 

The way to avoid the trap that definitional ambiguity sets is to define your terms and measures of success in the project plan and in the memos and other documents that announce the launch and progress of your project as it proceeds. Be certain that those in authority review and agree with your definitions and measures.

 

The rule to remember is "Ambiguity serves no one." Treat ambiguity like a particularly dangerous pest--getting rid of it at every turn. Then deliver. Then the project management gods and goddesses will smile on you as you bask in your perceived--and real--success!

 

Discussion Thread

Please keep our ongoing discussion thread in Project Management Central alive. Comments regarding measures of success and how to avoid failure are welcome. As are additions to our gallery of causes of project failure. It would be particularly interesting to read war stories of failures that were perceived as successes, and vice versa. Meanwhile, remember: Perceived is real (or it might as well be).

Frank Winters has nearly 40 years of consulting and Information Technology experience serving as a technical developer, team lead, project manager, program manager, consultant and IT service industry executive. He currently consults, writes and speaks on program and project management related topics and is a frequent contributor to gantthead.com. He can be reached at [email protected].



Related Content

ADVERTISEMENTS

"What is wanted is not the will to believe, but the wish to find out, which is the exact opposite."

- Bertrand Russell

ADVERTISEMENT

Sponsors



Newsletters

Dec 4: Do Your Commitments Make Sense?
Nov 20: Are You a Chronic Canceler?
Nov 13: Celebrating Quiet Competence

See all newsletters