Shut it down: lessons from failed projects
So your project is a mess. What are you going to do with the rest of your life?
Shutting down struggling, underperforming, or just plain broken projects is a fact of life for managers and leaders. But simply imploding the building and walking away won’t avoid future failures. Neither will finding a convenient scapegoat and glossing over the rest of the details.
Instead of going down in flames or sticking your head in the sand, find ways to learn from the failure to launch.
It could have been worse
Did you fail, or did you shut down the project just in time? There’s a crucial difference. Cutting off a project feels like failure, but letting it die a slow, lingering death—or having it abruptly terminated by the customer—can be far worse.
“The real failures are projects that go on for too long, to the organization’s detriment,” says Meredith Rousseau, head of strategic portfolio delivery at TD Bank. “Closing down a project in a successful way actually benefits the organization.”
For example, Rousseau was involved with a project in which, mid-stream, it became clear that the assumed productivity benefits were far off the mark. In one instance, a gain had been double-counted; in another, an unrealistic assumption had been made.
These discoveries did not threaten the ability to continue to deliver milestones and bring the project to completion, but completion in this case would not have delivered the sought-after success and benefits. In the end, Rousseau went to the steering committee and the project was closed down. “That’s an example of a good failure. We didn’t see the full scope of work through to fruition, but the team and stakeholders were transparent and honest,” she says. “The benefits we thought we were going to realize just weren’t there.”
Under-delivering starts with over-promising
“One of the primary causes of failure is an absolutely inappropriate schedule for the scope of the work,” says Larry Putnam Jr, co-CEO of QSM.
Those unreasonable schedules are very often locked in before the project even begins in earnest. “Project timelines tend to be locked in by what the customer or stakeholder wants and their notion of how long they’re willing to wait, but we have to understand that’s just their desire,” he says. “You have to marry that with the real capabilities of the delivering organization.”
What looks like a failure to execute may have been a no-win scenario. “When you measure the productivity of what the team actually did and compare it with industry averages, often you’ll see that the performance was pretty decent,” Putnam says. “What they were being asked to do in terms of time and budget was out of alignment.”
A quick failure checklist
Be honest: did you try to bail out the failed project with a human wave? It’s a maneuver which tempts the best of us, even though it so seldom leads to good outcomes.
“The knee-jerk reaction is to add people, but that probably has the least impact on schedule reduction, adds tremendously to the cost of a project, and you generally run into quality problems,” Putnam says.
Did you have a plan for anything other than total success? “The process for exiting a project should be understood so in the event it fails, it can be closed down quickly and funding reinvested elsewhere,” Rousseau says.
Were you willing to use frank language, including four-letter words like “can’t” and “won’t” with respect to your client’s initial expectations? “It’s never satisfying when the customer expects to get everything but you can only deliver on 50-60% of the capability they wanted,” Putnam says. “But the earlier you negotiate alternatives, the less locked-in people are on the cost and schedule numbers.”