What to Do If Your Project Bombs

Posted on
Like what you see? Share it.Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone

I have every right to give this advice. I should: I’ve seen more projects bomb than any person I know, and some of them were a result of my own failures.

If that kind of stark admission turns you off, bear in mind that people who admit their mistakes can (and do) fix them. People who don’t simply lie to themselves, indulging in flawed delusions of their own perfection. The same goes for teams, which all too often ignore their errors in an effort to whitewash failures.

Yet even the best-intentioned teams can lose their way, leaving projects to fail and leaving not only a mess but potential career damage in their wake. As far back as 1994, the Standish Group, authors of the well-known Chaos Report, claimed that 31.1 percent of IT projects are cancelled before they hit the finish line, and a whopping 52.7 percent of IT projects will cost 189 percent of their initial estimates.

So if you have an out-and-out bomb on your hands, you’re not alone. What makes you distinctive is not the presence of failure, but the way you deal with it.

Admit It
It’s hard, and it hurts, but it has to be done. First, admit the failure itself, and admit your part in it (if you had one). If the project failed due to your own lack of vision, planning or action, say it, both to yourself and others. Don’t flail yourself or search for a gallows. Just be honest and demand that others do the same. To my knowledge, no one (and no team) has ever crossed the finish line wearing a blindfold.

Take Heart
Second, relax. Yes, you’re embarrassed. Yes, you might have lost the trust of your client, manager or team. And no, this will not look good on a resume. But so what? A life without mistakes—and by extension, a career without mistakes—is no life at all. And no less a success than Churchill said, “Kites rise highest against the wind, not with it.”

Pinpoint the Problem(s)
Now take action. Determine exactly what happened and where the fault points lie. Don’t settle for vague generalities. Note the date, time, actions, decisions or lack thereof that caused your project to fail.

If you’re looking for common problems, try these:

1. Was there a lack of planning? If so, what kind? When? Why? Remember an old, acerbic dictum among project managers: “First, dive in. Then take heart when things go badly. Then admit defeat. Then blame the innocent. Then start to plan.” I suggest you do none of those, at least not in that order.

2. If you did engage in formal planning, was it enough? Did you cover the details? In 1986, Alfred Spector, then-head of Transarc Corporation, compared the process of building a bridge to writing software. Bridges get built on time, on budget and don’t fall. Software, in contrast, is late, costly and only works partially. Where’s the difference? Engineers plan a bridge down to the last nut and bolt. They use a level of precision that software designers not only ignore, but often execrate.

3. Was there scope creep? It’s the project manager’s term for the way that projects grow bit by bit, with a feature here, a feature there, until they’re twice as large as when they began. To fight scope creep, use a rock-solid change-control system, one that documents each addition to the project’s scope and alters the budget and timeline accordingly.

4. Was there time for testing, debugging and user training? Some experts claim it takes twice as much time to test your code (or your network, or your new server) as it takes to to set it up. And without user training, users will commit all kinds of gaffes (“Can I use the CD player to hold my coffee cup?”) that will affect their opinion of your project for the worse.

Change
Last, avoid your past mistakes. It’s easy to say but hard to do. After all, action is always harder than talk.

You can start with a good risk-management plan for your next project. There are plenty of risk-management techniques, but if you need a bare-bones model, try this: List your risks and the time or dollar impact of each (that is, how much time or money you’ll lose if the risk becomes real). Then rank your risks by impact, and plan a way to avoid them, giving the most time, money and attention to the risks with the biggest impact. The mere fact of writing this down will force you to analyze risks—and your hedge against them—with more care than you’re used to.

Sue Young, CEO of ANDA Consulting, has an even better way of tackling risk. She counsels her clients, (which include luminaries such as Wells Fargo, Paramount, Pepsi and IBM), to try “failure prevention,” in which you not only look at what could harm your project, but what will. Young believes that all projects have certain risk factors that are death knells, pure and simple. Talking about toxins such as these takes a strong gut, but if you expect your next project to work, you’ll need exactly that.

In the end, that’s perhaps the best advice on dealing with project bombs. Endurance has a funny way of breeding winners. Or, to quote Churchill again (a man who knew how to reduce words to their simplest, most vital aspects), “Never, never, never, never give up.”

Enough said.

David Garrett is a Web designer and former IT director, as well as the author of “Herding Chickens: Innovative Techniques in Project Management.” He can be reached at dgarrett@certmag.com.

Like what you see? Share it.Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone
cmadmin

ABOUT THE AUTHOR

Posted in Archive|

Comment: