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
ancient Greek gods, provides one such example. For his crimes against
the inhabitants of Mount Olympus, 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, and so on. 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 go 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 important
consideration in mind: howprojects
are killed is just as important as whether they
are killed.
An
innovation leader must create meaning from killed projects. To do so,
leaders must drive systematic learning from the experience, and then
institutionalize that learning. This simple and effective step
maximizes both individual motivation and institutional gain, killing
two birds with the stone that would otherwise roll frustratingly back
downhill.
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. Note that the value of the AAR is not limited just to
cancelled projects, but to successfully launched projects as well.
Operationalizing
what is learned in the review 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.
by
Brad Barbera, Pi Innovation LLC
No comments:
Post a Comment