When "kill" is off the table

How easy is it for your company to “kill” a project? Are projects being given a “go” decision indiscriminately? And what are people telling themselves?

The world is moving more and more towards adopting the ideas of Agile for project management and product development. Yet, the phase-gate is still a workhorse process for most companies developing tangible products. And not all is well with it.

Big-batch decision-making

One of the biggest issues of the phase-gate is that it promotes big-batch decision-making. Each project phase results in a batch of deliverables and team recommendations. This serves as a proxy for project progress and residual risk and is checked in a very important and visible gate meeting. In this, a steering board seeks to make an informed decision about the project’s future. Supposedly, it’s this gate review ritual that effectively safeguards project quality.

Steering boards and project teams expend significant effort in orchestrating gate reviews. While some of this effort is justified, much of it is an unnecessary waste. It often takes the form of preparation busywork with no correlation with product value, and of distractive and destructive group dynamics with detrimental effects on decision-making quality.

To be fair, companies try to implement the phase-gate process as it has been sold to them for decades: as a clearly structured approach that enables rational decision-making that progressively reduces project risk. On the surface, things look clean, organized, reasonable. Under the surface, however, things look rather different.

“Go”, “go”, “go”! OK, but “go” where?

Whenever I can, some of my favorite questions to ask leadership teams, project and product managers, and training participants, are “how long should the average product development project last?” and “how often does your company kill projects?”

Over many years, the answers reveal that the most sought-after decision at a gate is that of a “go”. It’s also the most popular one, topping the “phase recycle” by a very wide margin. In other words, most companies relying on the phase-gate show little openness to the option of stopping a project. Moreover, they are often forced to stretch phases and delay gates, perhaps exactly because they push so optimistically for “go”.

Inquiring about how many out of a hundred projects are killed reliably yields single-digit figures. The lowest figure I’ve ever heard is “three”. Such numbers might indeed not surprise you, and simply verify your own experience, as they do mine.

Reasons and rationalizations

What is surprising is the consistency of the reasons cited behind such numbers, as well as how they turn out to be rationalizations upon further discussion. Killing on average just five out of a hundred projects sounds great at first. That’s until you realize that it’s “five” because wishful thinking and logical fallacies are preventing it from being “fifteen” or even “fifty”.

So, let’s explore the most intriguing rationalizations that I’ve identified consistently enough to warrant our attention: a) prophetic abilities, b) career self-preservation, c) skirting responsibility, d) fallacies and negligence, and e) imaginary subsidization.

a) Prophetic abilities

Many claim that steering boards do a great job by killing all risky ideas much earlier in the innovation funnel. Allegedly, this can be done early and reliably thanks to steering board members’ intuition about what makes a project successful in the target industry. Such astuteness is attributed to long tenure and rich experience.

This is a disconcerting claim, especially whenever further discussion reveals that the company is living off of incremental, lukewarm updates to features and specifications of mature product lines. It is even more disconcerting that the claim often comes from those more likely to sit on the steering boards that “manage innovation”.

This reasoning is troubling in our times. Established players relying on assumptions and extrapolations from past successes are leaving themselves open to being blindsided and disrupted. After all, there are plenty of non- incumbent competitors flying under the radar, questioning fundamental industry assumptions thanks to new technologies.

b) Career self-preservation

Others, mostly project and product managers, claim that “no team would be stupid enough to recommend to the steering board to recommend killing its own project” (an actual quote). Therefore, “kill” decisions are also rare because having a killed project on your track record can be detrimental to your career. And, at the very least, it leads to distressed relationships with fellow team members and direct supervisors.

However, over time an organization can become addicted to “good news”, such as “go” decisions in gate reviews. This can act as a filter biased in the favor of team members who have never had to recommend or face a “kill” decision. However, such a happy circumstance isn’t always an equitable result of skill. It can also be a result of sheer luck in dealing with lower-risk projects—or of resignation to accepting mediocre project outcomes.

Conversely, in such a setting those more daring and honest (first of all, with themselves) can eventually reach a career impasse. Throwing this back as a rejoinder has sometimes been met with a resigned shrug in the spirit of “that’s life”. This probably proves a point on the survival of the fittest, when the addiction to “good news” selects people for complacency and comfort.

c) Skirting responsibility

Related to the last point, further inquiries often reveal another phenomenon: in many organizations, it’s preferable to have delivered a relatively unsuccessful product than to have been confronted with a killed project.

A project or product flop might still invite scrutiny in the short run, but over time tends to be rationalized away—on all levels of the organization. Various external, uncontrollable factors are then cited as reasons, helping to diffuse responsibility and accountability: “unexpectedly innovative competition” (another actual quote), rapidly changing macroeconomics, uncooperating distribution channels, unreliable suppliers, etc.

While some of these can be valid reasons, people have often revealed that they are actually evasions. In such cases, both the steering board and the project team had failed to make a business-minded decision. With wishful thinking and extra effort, they preferred to keep making “go” decisions, instead of killing the project or delaying gates as needed, learning from the experience, and moving on.

d) Fallacies and negligence

Another popular reply is that “kill” becomes rarer with every passing phase because project effort is frontloaded onto the first couple of phases. Thus, with every passed gate, less and less money would be saved in relative terms if the project would stop. Plus, the later the “kill”, the more the company thinks it would “waste” by not launching something. And with this dynamic, it often does launch something. Either something premature on schedule or something undesirable later than planned.

Many things are going on here. For one, people tend to forget the cost impact of changes undertaken late in the project. Furthermore, this hesitation to kill the project is simply a rehash of the sunk-cost fallacy. It also comes with a hefty dose of myopia regarding the total lifecycle costs of a product. And finally, it relativizes, downplays, and disregards the cost savings of a rightly-killed project. Yet, many relative cost savings of such wasteful projects can quickly add up to absolute resources to be put towards better endeavors.

e) Imaginary subsidization

Finally, from all roles, I have also heard the argument that it doesn’t matter that much if “go” decisions are chosen less discriminately. That it’s not that bad if the product isn’t as good as originally envisioned yet still launches, as “this is normal”. That it’s better to launch a product, even if its business case is much less profitable than originally estimated. Such a viewpoint tends to be justified as a “strategic business decision”.

This line of thought is more evident in companies with a large product portfolio, where the impact of each product is marginal, as is probably the fallout of a flop. Therefore, so the rationalization continues, other products will “pick up the slack” and cover the revenue and profit shortfall of this one.

Yet, curiously, I never seem to find anyone claiming to strive for abnormally great products in order to pick up the slack for other projects that got the “go” when they shouldn’t have…

Don’t treat the symptom

The remedy to an artificially low number of “kill” decisions is not to measure and promote more of them. This would simply be treating the symptom. Moreover, incentivizing more killed projects might simply lead to worse projects being selected to begin with. These “sacrificial lambs” would later be stopped in the name of meeting some “project kill quota”; arbitrarily defined and easily gamed.

The aggregated project rationalizations presented here imply a number of relevant root causes requiring action. There are tendencies, such as confirmation bias, and fallacies, such as sunk cost. There are also organizational culture issues, such as wishful thinking, a low tolerance of error, and a lack of readiness to admit mistakes and learn from them. And, there are also operational issues: frontloading effort instead of knowledge gaps, focusing on deliverables instead of achieving results, and lacking awareness of the total product lifecycle costs.

Finally, there is also the main root cause, the elephant in the room: the phase-gate process. This is accompanied by the unspoken, detrimental implications of its gate-review mechanism on the behaviors of project team and steering board members. We should perhaps reevaluate whether the phase-gate process can still be considered as a key success factor of product development operations, instead of an obsolete mental model and a competitive disadvantage.