In May 2000, events overwhelmed a fire crew working to burn out an overgrown 300-acre area at the Bandelier National Monument in New Mexico. A tiny patch of flame, which kept flaring up every time firefighters thought they had put it out, eventually escaped and grew into the Cerro Grande wildfire, one of the most devastating in our nation’s history and the cause of $1 billion in damages to the city of Los Alamos and the adjacent Los Alamos National Laboratories. Eighteen thousand people were evacuated; and two weeks later, by the time the fire was finally stopped, some 47,000 acres had been consumed and 300 homes and laboratory buildings destroyed.1
Like most disasters, many factors contributed to Cerro Grande. But an important one was what we call “dysfunctional momentum,” which occurs when people continue to work toward an original goal without pausing to recalibrate or reexamine their processes, even in the face of cues that suggest they should change course. What happened to the firefighters in New Mexico is not unusual. Dysfunctional momentum arises daily in organizations, and sometimes with dreadful results. The members of a project that spiraled out of control look back and wonder: How did we get there? How did we miss the cues that might have signaled huge problems ahead? Or, if they did see the cues: Why didn’t we change course?
The Leading Question
How does dysfunctional momentum come about and what can managers do to prevent it?
Findings
- When engrossed in an action, we tend not to notice small problems that may grow into large ones.
- To overcome dysfunctional momentum, we have to be interrupted or create an interruption ourselves.
- Practice ‘‘situated humility.” As no one person can solve the problem alone, diverse input is essential.
Business disasters, like many wildfires, often start out small, with little problems that managers notice but don’t worry about too much. But what happens when small “fires” start to accumulate, grow or change direction? The fact is that when we’re in the middle of the action, we often get so engrossed in what we’re doing we don’t notice that things have changed, or we ignore signals suggesting we should alter our course. And the next thing we know, we’re faced with a full-fledged calamity.
Company managers can learn a lot about preventing dysfunctional momentum, and ultimately
Get Premium Already a Premium Subscriber? Sign In
Purchase
Buy this article
Purchase one or more copies as a PDF
Copyright © Massachusetts Institute of Technology, 1977-2011. All rights reserved.
This article elegantly captures a fact we often see in complex projects – teams dedicated to deliver to plan, whilst missing key evidence that the plan needs to change. The best teams build in the ‘interruptions’ described in the article, or opportunities to step back and evaluate progress against the current environment, rather than the original plan.
More value can be gained from the interruptions by using an independent/objective evaluation at key points in the delivery cycle.
This article provides many interesting insights into dysfunctional momentum. Having been involved with the rescue of many high-visibility business initiatives, I would like to offer a few observations along the same line of reasoning. Usually there are multiple reasons that business failures occur including, poor communications, poor planning, refusal to abandon a poor plan, unrealistic expectations, myopic leadership, and ignoring the warning signs. There are always warning signs: budget overruns, missed schedule milestones, people bailing out….
Having rescued many technical projects, I find that technical managers are generally poor communicators and place technical excellence above managerial excellence. And, compounding this, the company or client may have unrealistic expectations about when a product can be delivered and at what cost. Teams many times tend to be overly-optimistic about what can be accomplished in a give time and scope. And, finally, I cannot stress enough the importance of planning. Too many times, people want to start implementing with the concept. However, it has been my experience that time spent planning is usually recovered during implementation–it is well worth the time spent. And, lastly, I find that teams tend to ignore or minimize potential problems. Many times, teams can learn to anticipate problems and develop mitigating solutions rather than wait for those end-of-project surprises. Hope this helps.
David Tennant
Atlanta
> Too many times, people want to start implementing with the concept. However, it has been my experience that time spent planning is usually recovered during implementation–it is well worth the time spent.
@David Tennant: Too right. I’ve been part of a few tech projects that needed rescuing and the problem is usually planning, and being too keen to get the coding (or other implementation) done before the project has been properly analysed and scoped.
Great article by the way.
David