Print
Close

Just Kill It Already!

October 27, 2016

Growing up in England in the 1970s and ’80s I was able to enjoy the magnificence that is Monty Python. One of the most famous of their sketches is entitled “Pet Shop,” although it is better known the world over as “the dead parrot” sketch. It’s never good when I have to compare organizational behavior with Monty Python, but when it comes to cancelling projects—especially strategic projects—the dead parrot sketch frequently comes to mind.

I have spent many hours in meetings with clients where they discuss whether a project needs to be cancelled, and I frequently hear complaints from project managers and PMO leaders about how their organization is notoriously bad at killing projects. In truth, most of those projects are already dead (just like the parrot); the refusal to recognize it and act accordingly is the real problem.

But why is that? Why do apparently well-run organizations continue to invest effort, money and time into major strategic initiatives that have no hope of meeting their goals? I believe there are a number of reasons for it, and I want to explore those here—as well as presenting a better approach when projects need to be cancelled.

The reasons it’s so difficult
It should be a difficult decision to cancel a project—it’s going to have repercussions and formally recognizes that mistakes have been made. However, there are times when it is necessary because the alternative is worse—to continue investing in something that has already failed. When it comes to strategic projects in particular, cancellation is very difficult for a number of reasons:

• The focus on deliverables instead of benefits isn’t sustained. Organizations are getting better at approving strategic projects based on the contributions those projects will make to their goals—approving a new product development initiative because of the net new revenue that is expected, for example. However, once the project is approved, execution reverts to being about the product, not the revenue the product will facilitate. That makes it far harder to recognize failure—the project may still be capable of delivering the product long after the revenue target has become impossible.
• The perception of failure. This is particularly relevant for strategic initiatives because they have such visibility throughout the organization. Following on from the previous point, when the project is perceived to be about developing a new product rather than achieving new revenue, if the project is scrapped, the reputation of the department or business area within the organization suffers. Related products in the same market will be tainted, the next new product proposal will be viewed with skepticism, etc.
• Justification of benefits. When strategic projects are approved, they are generally expected to deliver benefits for an extended period of time. In our new product example, the expectation may be $X million in net new revenue within Y months of launch. But if that is missed, the argument is made that the benefits are simply delayed—or that accelerated growth will make up for it. There may be no foundation for such claims, but equally there is likely no way to disprove them.
• Separation of accountability for costs and benefits. The individual held accountable for delivering the project is generally being measured by performance against the triple constraint. The individual held accountable for delivering the benefits is usually a different person and is measured by performance against the outputs of the project. This separation makes it harder to maintain a complete and accurate picture of what is happening when considering the future of the project because we have two different perspectives—and neither of the roles wants to be associated with failure.

In most organizations, some elements of each of these factors occur. At the same time, the sponsor, customer and other key stakeholders want the project to continue. Failure for those stakeholders is not to continue a project that is already beyond saving, it is to be associated with a project that has been cancelled. True improvements will only come when that perception is changed.

The reasons why failures occur
Let’s now consider why projects fail. This could easily be a lengthy series of articles in itself, but if we consider failure to be defined as the inability to achieve the benefits for which the project was initially approved, then failure occurs for some combination of just two reasons:

1. The project was never capable of achieving the goal in the first place. This is a failure of planning and business casing that led to inaccurate assumptions, estimates and expectations. Further, it is a failure in the strategic planning process that was unable to identify that the claimed benefits were incompatible with the proposed work.
2. The project became incapable of achieving the benefits during execution. This is the more common scenario where challenges during execution mean the expected benefits are no longer achievable.

The first of these is reason enough to cancel the project as soon as it is identified as a problem. Expecting the impossible to suddenly become possible through persistence is just bad management. The problem with projects in this category is they are generally never identified—the rigor around project review during annual planning isn’t robust enough. That’s clearly a major problem, but let’s leave it for another article and focus here on problems within project execution.

The second category is one that organizations have to deal with most often. In these scenarios, the project rarely fails without warning. Rather, it begins to suffer problems that the team attempts to resolve. Either those attempts fail or more things go wrong, and as time proceeds the project veers further from its expected outcomes. As more management effort is focused on resolving the issues, so the focus becomes more and more short term, addressing variances to the project constraints of schedule, budget and scope and losing sight of the performance against benefits. This can make the situation worse because the actions needed to bring the project closer to compliance with the constraints may be different than the actions needed to address the benefits shortfall.

Before we look at how project cancellation should be handled, we need to acknowledge another potential reason for that cancellation. This isn’t a project failure, but should be just as powerful a driver for cancelling. If the organization’s priorities change, or if the environment the organization operates within changes, the benefits the project was approved to deliver may no longer be appropriate. The longer the time between approval and delivery—and with strategic initiatives, those time windows can be lengthy—the more likely this is to occur. If the benefits are no longer appropriate, the organization must be prepared to cancel the project or find it is successfully delivering against the goals it used to have!

A better approach to project cancellation
Cancellation decisions should be made for purely logical reasons, but inevitably when humans are involved, the heart sometimes rules the head and projects are allowed to continue without good reason. This is somewhat understandable during the project itself—people have invested not just time and effort in the project work, but have likely been struggling to help it recover from whatever problems it has been suffering from.

We therefore need to separate the “kill vs. keep” criteria from the timing of the decision. When it comes to strategic initiatives, the single driver of a project should be the benefits the project is expected to deliver—the contribution to the organization’s goals and objectives. If that contribution falls short, it doesn’t really matter why—delayed revenue, slower revenue growth, reduced net revenue because of increased costs, etc. As a result, we can establish threshold criteria at the time the project is approved and use that threshold as the basis for any cancellation decision.

Let’s look at the new product example from earlier. Suppose the product is expected to deliver $5 million by the end of the fiscal year in which it hits the market. To establish threshold criteria, we have to determine at what point below the $5 million the investment doesn’t make sense. That’s not necessarily the “break even” point; it may simply be that the investment can generate a better return elsewhere below a certain revenue number.

By simply asking the question, we are forcing the organization to analyze the expected benefits further, which will help to identify those projects that never have a chance of hitting their goals in the first place. We also increase our understanding of the drivers of the project and we improve our ability to predict and project the expected benefits. That last part is important as we will use the same process of projecting benefits when determining whether a project can still meet the threshold (let’s say it’s $4 million in our example).

Once we have those threshold criteria in place, the decision to cancel the project or continue it becomes a simple matter of establishing whether the benefits contribution still exceeds the threshold. If it does, then we continue—potentially with closer monitoring if the benefits are considered to be at risk. If not, we acknowledge it is an ex-parrot…I mean a failed project…and move on.

Conclusions
I recognize that sometimes projects are invested in not because of the short-term gains that can be achieved, but because they are part of a longer-term strategy—we need a product in a certain market regardless of the cost now because the potential in three to five years from now is immense.

However, those are a small minority of the strategic initiatives, and the organization can only afford to invest in them because of the contribution other initiatives are making. To be successful, the organization needs to ensure the overall portfolio is achieving the collective goals and objectives—and the presence of failed projects that are still consuming resources is a significant drag on performance.

By establishing threshold criteria at the outset, we can define the point at which a project is falling short of expectations and establish a simple metric to use in our “keep vs. kill” decision should the need arise. The reasons for any shortfall are important and must be examined so the organization can learn, but the most immediate problem is to recognize when failure has happened and prevent good money, time and effort from going after bad.