Killing Projects without Killing Project Teams

The ancient Greek storytellers had keen insights on human psychology. The myth of Sisyphus, a legendary king who played a few tricks on the gods, provides one such example. For his crimes against the gods, he was condemned to a particularly nasty form of hard labor, forced to roll a heavy stone to the top of a hill, only to see the boulder roll right back down as he reached the summit. His eternal punishment was not only physically wearing, but rendered his efforts utterly meaningless, thereby creating a particularly painful torture to mind as well as body.

How often do innovation leaders consign their teams to such a form of hell?

Effective management of product development projects demands that some get canceled. One of the great challenges management teams face is selecting which projects to kill when resources are limited. All too often, bad projects continue to proceed long past their expiration date.

So effective portfolio management requires getting out of bad investments in order to reallocate resources to better investments. But anyone who has ever worked on a project that ultimately gets the bullet knows the frustration, the disappointment, the disillusionment, or the myriad of other negative emotions that go with seeing their hard work come to nothing. Plenty of research has demonstrated the adverse impact of such emotions on creative performance.

To be a strong innovation organization means killing bad projects. The best innovation organizations do so without killing the people who worked on them.

Sisyphus builds Bionicles

To demonstrate the impact of seeing your work go down the proverbial hill, researchers at Harvard University conducted an interesting study. Participants were paid to build characters using sets of Bionicles. For those readers who don’t have kids who went through a Bionicles phase, Bionicles are construction sets of robot-like characters from the geniuses at LEGO. Most characters consist of a few dozen pieces, with step-by-step assembly instructions to ensure that a Mata-Nui doesn’t end up looking like a Baraki (my son confirms that such a sentence actually makes sense in the Bionicle world).

The researchers paid participants for each Bionicle they assembled, in decreasing amounts for each subsequent set: $3 for the first one, $2.70 for the next one, $2.40 for the third, etc. Thus, the financial incentive declined with each completion, to determine the threshold at which a participant deemed the task no longer worth their while.

Participants were divided into two groups: one group simply had their creations placed under the table after they were built, while the other group had their Bionicles disassembled by the experimenter right before their eyes, as soon as the construction was complete. The key question: how long would each group continue to build under those conditions?

The result: on average, the first group of participants (the ones who saw their creations placed under the table) built about eleven Bionicles. The second group (the ones who had their creations immediately dismantled), quit, on average, at only seven. That translates to group one sticking with the effort more than 50% longer than group two.

Meaning and Motivation

It is hard to imagine work with less “meaning” in life than building Bionicles in a Harvard psychology study. Yet builders whose little “achievements” were retained by the experimenter were significantly more driven by that tiny sense of meaning than those who saw their effort unvalued.

Now let’s apply that to the workplace: imagine the impact of seeing something with real importance, like the project work you have been doing for a period of months or years, dismantled by management before your eyes, treated as if it had no meaning. That’s a demotivational poster in the making.

While there’s no getting around the need for some projects to meet their ultimate demise, innovation leaders need to keep this significant consideration in mind: how projects are killed is just as important as whether they are killed.

An innovation leader must create meaning from killed projects. To create such meaning, leaders must drive systematic learning from the experience, and then institutionalize that learning. In so doing, both individual motivation and institutional gain are maximized.

Learning from failure

Obviously, project failure is costly. There are the financial accounting costs of the resources spent on a project that will never generate revenues in return. There is also the opportunity cost of lost development on projects that could have had successful futures, but instead went unfunded in order to provide resources for a the project that ultimately failed.

A good innovation leader does not let a good failure go to waste. The best way to recoup some of the cost of failure is to turn it into an investment – in organizational learning.

Some people call such learning “post-mortems.” I prefer the military term, After Action Review (AAR). The concept is not new, but in my experience, few organizations take this critical part of the product development cycle seriously. Most don’t bother doing the review at all. Many of those that do make the effort, use it as a search for the guilty rather than as a means of genuinely strengthening organizational capabilities.

Whether you call it a Post Mortem or an After Action Review, leverage it for the real value that it can deliver. To do so, seek to answer these three broad questions:

1. What were the differences between what was supposed to happen and what actually happened? These differences should be identified non-judgmentally – without evaluation of the difference as good or bad. For example you may identify that prototypes were completed a week ahead of schedule by following a new process, and that customer beta testing was below benchmark hurdles. Neither is presented as either good or bad, but just as a statement of fact.

2. How could the execution of the project be improved? After identifying the facts of the project, then the evaluation can take place. What may have seemed like a positive, such as completing prototypes ahead of schedule, may turn out to be a negative, perhaps by failing to catch a quality flaw that would have been identified with additional time. Such a-ha moments are more likely to be experienced if the facts are laid out objectively before starting evaluation.

3. What successes should be repeated on future projects? The AAR is not just a search for failure. It is also a search for success. Change management experts have long recognized the importance of finding bright spots to build on when driving learning through a group. Organizational growth will come fastest from not just avoiding what didn’t work, but also embracing and repeating what did work.

Finally, and perhaps most importantly, operationalizing what is learned in the review throughout the organization delivers the real value of the effort. Specifics from the particular AAR need to be converted into generalizable lessons for the organization. Then organizations must define and use mechanisms for sharing the learning, and making it part of the culture of how things are done. IDEO, for example, keeps failed design prototypes on display in their offices as a reminder of what was learned, and as encouragement to make the next effort in spite of the risk of failure.

Let’s not sugarcoat things: failure hurts. No one likes it. However, by extracting the valuable learning available from failure, you will increase the chances of the next success. And by having the project team see their work translated into lessons that add value to the organization, you will increase their resilience and motiavation going into the next effort.

To allow such value to go uncaptured – or worse, to actively contribute to a team’s demoralizing sense of failure – is akin to sentencing them to join Sisyphus in yet another slog up that mythic hill, shoulder to boulder.

Featured Posts
Recent Posts
Search By Tags
Follow Us
  • Facebook Basic Square
  • Twitter Basic Square
  • Google+ Basic Square

© 2017 by Brad Barbera and Pi Innovation, LLC