You know and love our Must-Read IT Blogs lists, but now, say hello to the nonprofit side.
Since 1994, 13 football teams have earned the dubious honor of losing the biggest football game of the year: the Super Bowl. Did losing the Super Bowl affect the following season? Does failure at peak moments improve a team or tear it apart?
If you guessed that Super Bowl losers come back ready to rumble, you don’t watch football. Of the past 13 non-trophy-getters, only six made the playoffs the following year, and only three of them won at least one playoff game. Many collapsed dramatically, dropping from the top ranks of the National Football League to rock bottom.
Take the 2003 Oakland Raiders, for example. The Raiders went from winning 11 games in the run-up to their Super Bowl defeat — where they lost to Tampa Bay Buccaneers by 27 points — to losing 12 games the following season.
It would appear that losing the Big Game might just be the worst thing that could happen to a football team. The losers tend to experience staff changes, reduced productivity and greater player injuries than their non-Super Bowl-losing counterparts. This problem even has a name — the Super Bowl Hangover.
Your technology project might not be the Super Bowl, but if it ends in failure you can expect a reaction similar to the Super Bowl Hangover. Your project team members might not suffer physical injury or sport egos as large as their salaries, but they may experience a productivity dip after a large project failure.
Good managers, like good coaches, will help a project team that has failed get over the bad experience and move on as quickly as possible. Here are six tips for helping your team recover from making it to the big game and then falling short.
Projects don’t fail without project managers making mistakes. At the root of every failed project is a manager who ignored critical feedback, held unrealistic expectations unrefined by experience or structured a project poorly. Don’t try to revise history. Explain the mistake you made and take that to the project team.
A while back, I managed a project that went from going live one month early to dragging in one week late. The problem? I had ignored feedback from the technical team that the volume of test cases being generated was not enough to evaluate a critical aspect of the system. My error not only caused us to lose the substantial lead we had created by executing the development portion of the project perfectly, but it also caused us to miss our original schedule and resulted in a very large budget overrun.
Everybody on the team knew I had screwed up, including me, but no one would say it. As a result, everyone was tense and communication was terse and unproductive. So I told the truth — not just to my project team, but also to my manager and his boss — in a project-status meeting attended by every project manager in our business unit. It sounds humiliating, but it wasn’t. I was frank and honest, and afterwards I received numerous compliments on my handling of the failure.
When projects fail, there’s usually a step that was omitted in the process or shortcut to shave time off the rollout or cut costs. Sometimes you can survive skipping these steps. In most situations, you can’t. A post-mortem can help reveal what steps were missed and ensure that the whole team understands their importance going forward. It can also help you understand a critical missed step and add it to your project-process checklist.
Different types of people cope with failure differently. Introverts, like myself, either want to be alone or be productive, while extroverts appreciate joining a more social team. Either way, provide team members like me a chance to be an “individual contributor” on a project with few dependencies and concrete deliverables; find a group effort for others on a successful team. Either way, ensure that the new work is driven by clearly defined deliverables.
Sometimes project managers who have worked on a failed project will try to spin the failure unproductively. Football teams that lose the Super Bowl know it doesn’t matter how good their own defense was, or how tough the opponent fought. They know the only thing that matters is hoisting the trophy over their heads and celebrating in the locker room. Winning is what matters.
There is a time and a place for perspective. People will talk about things they learned and ways the failure helped them grow. This is natural and helpful, as long as it is something that isn’t forced. Trying to force perspective on a project team that has failed is counterproductive — it will make you look desperate and insecure. It is better to wait and let the introspection occur in its own time.
If, on the other hand, your project did deliver something of business value before it was cancelled, say so — but be careful. Interim deliverables, such as requirements documents or design specifications, are nothing to be proud of, not if the project was cancelled. They have no business value and are not likely to be reused by future teams. Don’t make the mistake of waving an interim deliverable around, declaring that your team might have failed, but at least they delivered the best darn requirements document you ever saw. This will only further the discouraging perception that your project accomplished nothing of value, in spite of the expenditure of valuable time and effort.
It’s easy in the throes of failure to forget all the effort that went into attempts to save the project. I’ve never seen a project fail that wasn’t also accompanied by a near-heroic effort by one or more individuals to correct and fix the problems that plagued it. This effort, though ultimately futile, should not be ignored. Never speak disrespectfully of the effort these team members made to try to salvage the project, even though their task was akin to boiling the ocean.
Instead, talk admirably about any superhuman efforts you observed with your colleagues on the periphery of the project. Let them know about the emerging, growing leadership that developed on your team, in spite of its ultimate failure. Don’t make anything up or grasp at straws to find something positive to say (see the previous tip), but don’t wallow in abject negativity if you did in fact discover one or more diamonds in the rough in the process.
Failing stinks. Unfortunately, if you manage projects long enough, it’s inevitable you will fail. How you deal with failure is likely to have a powerful impact on the path of your career and could be the difference between washing out as an IT manager or allowing a failure to push your skills to a higher level. IT leaders who admit and learn from their mistakes can help the organization learn from the failure, and most importantly, offer a powerful advantage over their counterparts who may not have the confidence or tenacity to address failure in a healthy, productive way.