Why Projects Fail and How PMOs Can Prevent This

2

+++ What Constitutes Failure? +++ Success Factors for Projects +++ What PMOs Should Keep in Mind +++

By Johann Strasser                                                                                                           Read article in German

As a PMO, you know that projects sometimes fail. Some projects are even expected to fail, and this is taken into account. With other projects, failure is painful. For yet others, failure can be fatal to the company.

But why do some projects fail, and others succeed? What project success factors can be influenced, in particular by the Project Management Office (PMO)?

In this article, we explain some of the key factors for avoiding project failure and / or analyzing a failure. These factors include:

  • Prioritizing projects correctly
  • Preparing a clearly defined project order
  • Developing a good early warning system to quickly detect problems
  • Developing a corporate culture that accepts failure
  • Before we delve into the details, let’s first take a look at what constitutes a failure.

How do you identify a failed project? This depends on how you define “failure”.

As a PMO, you’ve surely given some thought to this topic. However, have you clearly defined what exactly constitutes a failure?

In our experience, how people define a failure can vary greatly. The definition can vary from project to project.

So, let’s take a closer look at three scenarios.

Special Download: 10 Reasons why a PMO is important (PDF file)

Please fill in the form.
* Required Fields  |  Data Protection

Scenario 1: Halting a project is not the same as aborting it

Failure has a negative connotation and gives the impression that something has gone wrong. In reality, there are some projects in which some degree of failure is expected. This is the case in, for example, some research-intensive industries.

Here, projects are sometimes launched with the intention to continue them only as long as is practical. Such projects are aborted as soon as there is no longer any realistic prospect of success.

In essence, success would have been a “great result” but not necessarily assumed. However, this assumption should be made clear at the outset.

In research-intensive industries, successes are celebrated but not necessarily assumed. It’s important that everyone involved understands this right from the start.

Example: Think of all the pharmaceutical materials developed that never make it to market as a medical product. Sometimes they don’t receive regulatory approval. Or the development lead time overshadows the patent’s lifetime.

Maybe only one in five projects is actually successful. Given this scenario, you could say that failure is quite normal in this industry.

Scenario 2: An aborted project is a failed one

Whether or not an aborted project is a failed project is open to debate as it depends on your definition of failure. The two terms are often used interchangeably.

Many companies have specific criteria that determine when a project will be aborted.

A goal has been set, but during the project it becomes increasingly clear that this goal won’t be met despite everyone’s best efforts to reach it. Projects such as this are deemed to have failed.

Whether or not an aborted project is a failed project is open to debate, as it depends on your definition of failure. The two terms are often used interchangeably.

Example: A software project involving the introduction of a new system. After selecting a vendor, the company determines during the course of the project that this vendor is unable to deliver the desired functional environment within the required time frame or at the agreed-upon price.

So, the company aborts the project. Then, it finds another vendor with whom it tries a new strategy for implementing the desired system.

In this scenario, the company clearly expected the project to succeed. In contrast to the research efforts in Scenario 1, success was not just a hope, but rather an expectation. For this scenario, aborting the project is clearly a failure.

Scenario 3: Completed projects are not necessarily successful ones

Projects can be completed successfully but still be deemed a failure. Let’s consider these two examples:

Example 1: A development project produces a result that meets all the requirements with regard to features and functions. However, the users reject it and don’t buy it or use it.

So, the question is, was the project a failure? Was the order to deliver this result at fault?

You could say that it depends on the following:

  • Was defining the requirements was part of the project?
  • Did the project just involve implementing a set of predefined specifications?

Example 2: A product development project has achieved all the objectives, but there are production problems with the product. In the end, the entire product is considered a failure, including the perfectly executed development project.

Important: Define exactly what factors will be considered and what constitutes a failure.

  • How bad must a project be before it is considered a failure?
  • What happens when the project is deemed a failure?
  • Is a project considered successful if the work is completed on time and within budget, but the resulting product is unusable?

There are Various Ways to Define Project Failure

1) The project goals weren’t met

If only the project itself is considered, failure could be defined as failing to meet one or more of the project’s objectives, or not sufficiently meeting these objectives. Common examples of this are:

  • Exceeding the project’s budget
  • Overdue deliveries
  • Quality specifications are not met

If the result is accepted and used despite these shortcomings, the problem could be that it was delivered too late and was too expensive. However, the result is great and enjoys widespread acceptance.

In the end, however, the project manager failed because the cost and delivery targets weren’t met.

If the resulting rewards are reaped within the project manager’s own company, these shortcomings will probably be more tolerated than if the rewards benefit another company.

2) Subjectively perceived failure

Projects are often deemed a failure simply because it feels like they didn’t produce the expected success.

When stakeholder expectations aren’t met, it’s often because:

  • The stakeholders and / or their expectations weren’t known.
  • The stakeholders weren’t sufficiently informed.
  • There were no clear guidelines for defining success and failure.

All these problems can be avoided by having clear guidelines and having the PMO actively communicate with those involved.

Important: Using even simple methods, the PMO can play a vital role in ensuring that key information reaches the right people in a form understandable to all.

One of the PMO’s primary duties is to provide all the relevant people with information relevant to them.

This helps avoid misunderstandings and minimizes grapevine news. Along the lines of “A little knowledge is a dangerous thing”, half-truths about critical results makes for bad headlines. Having an effective communication plan can help prevent this.

When Projects Fail – Reasons and Actions for the PMO

A project can fail for reasons within and beyond someone’s control.

External Causes of Failure

External Measures

  • Define guidelines and standards, and ensure an optimum environment
  • Ensure that those involved have the proper education, training and support
  • Provide the project manager with lessons learned from other projects
  • Check to see whether the risk prevention measures make sense

 

External actions with which you, as the PMO, can minimize the chances of a project failing

Analyzing and assessing the external factors requires significant experience and awareness with regard to stakeholder management and risk management.

It is important to remember that:

It is the project manager’s duty to monitor the progress and adopt countermeasures as needed. This should be done continuously during the project. The PMO is only involved indirectly, as it normally has no direct contact with the project’s external stakeholders. The PMO is therefore not expected to (and may not even be able to) have a direct influence in these matters.

To learn more about the PMO’s duties, read about what the future holds for PMOs.

As the PMO, however, you certainly have an indirect and effective influence on the project’s success.

  • Define the guidelines and standards in such a way as to provide the project managers with an environment conducive to success, and ensure that they have the necessary education, training and support.
  • Provide project managers with lessons learned from other projects. Check to ensure that, for example, the stakeholder and risk assessments sufficiently take into account the lessons learned from other projects.
  • Check to see whether the planned risk prevention measures make sense and are appropriate.

It is impossible to predict exactly the weather, future political changes, and what new requirements a client may request. You can, however, learn from previous experience and use this knowledge to develop some general guidelines for dealing with these uncertainties. Having this knowledge is definitely better than being caught unprepared.

You can’t eliminate all uncertainties, but you can actively work to analyze past problems and develop solutions or escalation strategies for dealing with these uncertainties, just in case they happen.

Simply being able to react more quickly to problems previously judged as risks may give you the head start necessary to prevent anything worse from happening.

Internal Causes of Failure

Internal Measures

  • Ensure that the following have been clearly defined:
    – Project orders
    – Criteria for aborting a project
    – Project success
  • Develop an early warning system
    – Use traffic light symbols to measure time, effort, costs and risks
    – Have traffic light symbols to indicate the project’s overall status
    – Create a “Needs action” status
  • Monitor and support the project managers
    – Provide processes, methods and tools
    – Support / monitor the project managers

 

What steps you, as the PMO, can take to minimize the risk of project failure

Always conduct an internal stakeholder and risk analysis, if possible, because even internal issues can pose risks and should therefore also be considered.

However, different countermeasures are required when dealing with internal issues. These can also relate to the PMO’s role itself. Here there are many actions you can take to help reduce or eliminate the root causes of failure through careful planning.

Start by developing objective criteria for evaluation

It is essential to clearly define:

  • Project orders
  • Project conditions that trigger an early warning
  • Criteria for aborting a project
  • What constitutes project success

These are all issues to which you, as the PMO, can develop solutions. When you have the solutions ready, make them available to the project managers and other stakeholders.

Clarifying these issues by providing solutions to them gives you a foundation based on objective criteria. Whether or not a project can be deemed a success will then no longer be based on subjective assessments.

Important: Having a framework of objective criteria ensures that any decisions as to whether or not a project has failed are comprehensible.

Of course, there will always be people who want to use internal political pressure to interpret the project results in one way or another for their own benefit. The preparatory work you did beforehand, however, gives you the power to positively influence the rumor mill.

During the Projects: Monitor and Support the Project Managers

Providing processes, methods and tools fulfills the prerequisites needed to optimize the chances of success, During the project, it’s the PMO’s responsibility to help the project managers comply with the established guidelines and ensure that they do so.

Important: Two of the PMO’s key responsibilities are consistently monitoring the projects and supporting the project managers.

It is important to monitor all the projects to ensure that they comply with the established guidelines. It is also important to provide the support needed to help the project managers accomplish this as efficiently as possible.

Another interesting read: Aborting a Project – Establish a Culture of Successful Failure

There are various methods for establishing an early warning system. Having an early warning system helps you detect problems in a timely manner and helps the project managers implement countermeasures to resolve any problems. However, this only works if you, as the PMO, continually work to keep the system running.

Key Success Factors for Projects

In the following section, we’ll discuss what we consider to be the key success factors for projects.

1) Choose the right projects

The sooner you exercise control, the easier it is to stay on the right path. Start by only initiating projects with the necessary importance.

Avoid giving priority to someone’s pet project if this would waste resources that could be used for a more important project. As the PMO, you have a say in prioritizing the projects and can ensure that these are aligned with the corporate strategy.

Don’t wait until a problem occurs and everyone realizes that it’s due to some unimportant other project that is then subsequently killed. You can proactively work to avoid this type of mistake by acting proactively.

Important: Only launch projects that are important enough to be rescued from a difficult situation if necessary. Also, only initiate projects whose results are vitally needed, not the pet projects of a handful of people.

Priorities can naturally change, resulting in some projects being halted if necessary. These should not be considered failures. however, and the same applies to projects that are halted because a strategy shift has led to a change in priorities.

The key is to properly communicate and justify these decisions. These two vital aspects shouldn’t be underestimated or overlooked. Doing so would give the impression that the project failed or was unintentionally terminated, and that could harm the reputations of those involved.

2) Have a clearly defined project order

The PMO is generally responsible for developing the project management standards, and the project order is one of the most important of these.

It is often a cause of concern when it simply doesn’t exist. Other times, the project order doesn’t contain the information needed by the project manager to successfully execute the project.

Important: Ensure that the project sponsor provides the project manager with a clearly defined project order.

Don’t confuse this with the client’s order to the company. Here, we’re talking about the project sponsor’s order to the project manager.

  • Sponsor: clarify who, internally, requested the project
  • Project manager: clarify who is responsible for delivering the results

Think about your own company: how many projects do you know of in which one or both of these roles hasn’t been clearly defined – or better yet, is unknown? This isn’t as simple as it sounds.

Make sure you know who, internally, requested the project (project sponsor) and who is responsible for delivering the results (project manager).

In signing the project order, the project manager shouldn’t confuse courage with carelessness.

As the PMO, you hopefully know the available project managers. This lets you influence the project by choosing for this role the person most suitable for the project.

The project order should clearly define the project’s goals, which can be measurable objectives or soft issues.

Define the goals as specifically as possible, ideally using measurable criteria.

It’s always better to have measurable objectives, as it makes it easier to measure or determine the project’s success and minimizes the discussion afterward.

This includes naming those items that are not among the project’s goals but are nevertheless relevant. Doing so often draws attention to stakeholder expectations, allowing these to be put into perspective.

Important: Be specific about anything that is not among the project’s goals.

Example: You hope that a project will earn you subsequent orders from the client, so you acquiesce when the client subsequently makes additional demands. If the percentage of order volume or exact figures haven’t been specified, the project manager must ask each time such a request is made to find out just how much leeway is possible. Or find out later that their decision was wrong because:

  • They conceded too much, yet still didn’t gain any subsequent orders.
    Or maybe there were subsequent orders, but they conceded too much to gain those orders.

In essence, the orders were gained, but at a loss, or maybe the project was aborted because too much was conceded too early.

The project order should also specify an internal budget for time and expenses, ideally including profit and benefit.

The project order should also include information about the internal budget for time and expenses, and also the profit and benefit.

With external orders, the internally-defined times and expenses don’t necessarily have to match the values communicated externally. Depending on the situation, the internal values can be higher or lower than the external ones.

Important: The project manager must know which factors will be used to judge their performance.

The key to a successful project order is not only having agreed standards but also monitoring the quality throughout the project’s duration. Ideally, all project orders should be checked for completeness, clarity and measurability before being presented to the PMO for a signature.

3) Be cautious when making changes to a project

Every project is, at some point, subject to planned or unplanned changes. These can be requested by the client, due to external influences, or sometimes simply technical considerations.

These aren’t necessarily disruptions, as they can also be opportunities.

What’s important is that the PMO has appropriately trained the project manager in dealing with these changes and provides support if necessary.

The epitome of a good project manager is one who can handle changes successfully.

The art of successful project management lies in turning changes into opportunities. This is your chance, as the PMO, to help.

Changes can result in great amendments that can turn a modest business project into a more profitable one. Some amendments are never requested because someone wants to be helpful or show strength. In the end, there is often no thanks – or even recognition – from the recipient.

Important: Incorrectly assessed or wrongly negotiated changes unfortunately often lead to project failure.

The PMO is generally not directly involved with this. However, the PMO can, by creating the right project management environment, providing incentives for project managers to turn changes into economically exploitable results.

However, it might also be a good idea, in general, to help project managers reject, or argue away, any changes.

Important: It’s essential that project managers deal correctly with any changes facing the project. This depends heavily on the project management training specific to that particular company. It tends to be the responsibility of the PMO.

4) Detecting Problems Early

To prevent failure, projects must be continually monitored, managed and possibly given support.

To accomplish this, create a reporting system that enables you to detect any problems in a timely manner.

Such a reporting system involves more than just a “code red” symbol that is displayed once the project is heading downhill to failure. Many parameters (together or individually) are needed to identify situations in which the project manager needs some assistance.

Ensure that the reporting system alerts you early enough to allow you, as the PMO, to step in and provide the necessary help.

However, avoid giving the impression that the project managers are constantly being monitored.

It’s better for the PMO to develop an atmosphere of trust in which project managers are supported and encouraged, instead of blamed and shamed, when the project seems to be going off track.

A traffic light symbol is generally used to indicate when time, costs and / or risks have exceeded a given threshold.

We also advise you to include a traffic light symbol that you can manually set to indicate the project’s overall status in the status report. Project managers are individuals and differ as to their experience in dealing with problems.

We also recommend having a “Needs Action” status that the project manager can set. This enables them to draw attention to their project before its status becomes a “code red”. This alerts the PMO that:

  • Decisions need to be made.
  • Resources needed later have not yet been allocated.
  • There are other issues that can, at this point, still be handled with simple organizational solutions.

As the PMO, you are responsible for ensuring that the status reports are current, accurate and plausible.

You probably won’t have the time to check each project every month, so it’s important that you carefully choose which projects need extra scrutiny.

Tip: We recommend that you focus not only on those projects labeled “code red” or “code yellow”, but also those that are “code green”. Doing so will help you detect projects that have unjustifiably been kept as “code green” for too long just to avoid drawing attention to their problems.

Why? The project manager may have encountered problems right from the start, but decided, given the circumstances, that it would be easier to wait and not report these till the project was over.

If the difficulties are detected early enough, the PMO has a greater chance of fixing the problems and avoiding project failure.

5) Develop a framework for aborting a project

Ideally, you have established criteria to facilitate the decision to abort a project. In reality, however, the decision is easy for some types of projects and very difficult, if not impossible, for others.

If a project has great importance for the company, this might be one reason why it is not aborted despite fulfilling the criteria for doing so. There will always be exceptions.

The same rule of thumb applies to criteria for aborting a project as to the criteria for initiating a project – easy to define criteria should be set down.

Important: Don’t waste time creating an exhaustive set of rules. Your time is better spent monitoring the projects and asking questions to learn more about specific problems.

A horrible end is better than unending horror, as the saying goes.

Through careful communication, the PMO can have a major influence in helping to establish a corporate culture in which projects that are justifiably aborted early enough are not viewed as a project manager’s failure. In fact, the conclusion of these projects may come to be seen a necessary and ultimately meaningful.

Conclusion – Why Projects Fail

5 Success Factors

  • Choose the right projects
  • Have a clearly defined project order
  • Provide support for dealing with changes
  • Detect problems early
  • Create a corporate culture for dealing with aborted projects

 

Five key factors for avoiding project failure

This article has shown you why projects fail and demonstrated the importance of correctly defining the word “failure” as it relates to projects. Define measurable criteria.

You now also understand the primary internal and external causes of project failure. We’ve explained such things as the importance of project prioritization and how to effectively use a reliable system for detecting problems early.

You are also familiar with a PMO’s duties and responsibilities in a clearly defined project order, the correct way to deal with changes that occur during the project, and the importance of having a corporate culture for dealing with project failures.

Paying attention to the tips and success factors for projects outlined in this article should help you greatly minimize the risk of a project failing.

What are your experiences with project failure? What is your opinion on why projects fail. Let us know in the comment field shown below. We look forward to hearing from you.

Final tip: Subscribe to the TPG Blog Newsletter now and never miss another blog post.

print this article

Share.

2 Comments

  1. Gerald Prieur on

    These are useful tips for our government environment that has multiple small projects but does not have an established PMO.

Leave A Reply