When you run a project, there are a lot of components that need to be managed together: information, people, time, as well as specific challenges and threats. Speaking of threats – even if you’re a seasoned professional with extensive experience, you’re never immune to the smaller or bigger dangers of project failure. If you browse blogs and online communities, as well as glance at the agenda of offline events, you’ll see what a stirring discussion it brings up in the PM space. It’s usually analyzed from the “why” side – i.e., what are the reasons for project failure? But there is another equally important question that seems to be rarely discussed: How do we learn from it?
When you run a project, there are a lot of components that need to be managed together: information, people, time, as well as specific challenges and threats. Speaking of threats – even if you’re a seasoned professional with extensive experience, you’re never immune to the smaller or bigger dangers of project failure. If you browse blogs and online communities, as well as glance at the agenda of offline events, you’ll see what a stirring discussion it brings up in the PM space. It’s usually analyzed from the “why” side – i.e., what are the reasons for project failure? But there is another equally important question that seems to be rarely discussed: How do we learn from it?
Back in the 19th century, a Scottish reformer named Samuel Smiles said something that still holds true: “We learn wisdom from failure much more than from success. We often discover what will do by finding out what will not do; and probably he who never made a mistake never made a discovery.” So, what discoveries should we make, and what’s the wisdom in project failure? To find the answers, I invited fellow project managers to outline one key practical lesson they’d recommend taking from such a situation.
Lesson 1: Understand your stakeholders
Bob Tarne, the voice behind the “Zen, Project Management and Life” blog and currently executive project manager at IBM, shared a valuable lesson on avoiding failure caused by misunderstandings with project stakeholders:
“I thought of an example where I didn't take the impact of change on my stakeholders and ran into a roadblock. My project had executive support, so I was moving forward with the implementation. However, one stakeholder group wasn't on board. At first, I didn't take the time to understand their concerns... I tried to push the work through, but they kept resisting. I finally took the time to understand their particular concerns and was able to work out a way to meet their specific needs. So the lesson was that, even when you have executive support, you still need to take the time to understand all of your stakeholders.”
Lesson 2: Ensure constant communication
The lesson from Terri Griffith, Professor of Management and the author of “The Plugged-in Manager,” covered the communicative risks that may lead to project failure:
“My key lesson is – ensure constant communication to avoid poor situational awareness. People want to do a good job and sync with other aspects of their project, but if they don't have situational awareness, then those good intentions are just intentions. At extremes, the lack of communication then results in misinterpretations of why things aren't syncing – Psych 101 teaches that if something is going wrong, it's the other person's fault; if it's going well, it's to my credit. With poor communication, root causes can be misunderstood, adding to a downward spiral.”
Lesson 3: Share
Elizabeth Harrin, who regularly shares her PM wisdom in A Girl’s Guide to Project Management, highlights how important your experience might be for fellow project managers:
“My lesson would be: share. There is no point in not sharing. It is better for everyone if you are honest about the failure and what happened, and tell as many people as you can. Often we don't institutionalize lessons about project failure, and the same mistakes are made time and time again.”
Lesson 4: There should be no project failure
As for Peter Taylor, best known for his bestseller “The Lazy Project Manager,” the advice dives deeper into organizational reasons of project failure and gives a good deal of motivation:
“I think the one, big lesson we should all learn from project failure is that there should be no such thing as project failure! Projects should deliver. Now they may not deliver what was intended originally, but they should follow one of three clear paths:
- Deliver the expected business benefits,
- Be adjusted to deliver some business benefits, or
- Be stopped because they are not expected to deliver the business benefits originally intended, at any level of success, or they are focused on business benefits that are no longer relevant.
So project failure has nothing to do with individual projects not delivering, but more an indictment of the organization that allows such projects to ‘just keep going until the bitter end’ for some business reason.”
Lesson 5: Discussion -> Root causes -> Actions -> Codification
When I asked the question myself – there is something to learn in any failure. There are actions to take to prevent it from happening again, and as Terri and Elizabeth brought up, there’s a lot to communicate. Here’s how I’d put it into a simple, four-step process:
- Have an open and constructive discussion within the team about the failure. That serves both to communicate the lessons and leverage their collective intelligence.
- Analyze root causes together.
- Work out an immediate action plan to minimize the impact of the project failure.
- Codify the lessons learned into processes and practices: “The next time this happens, we do that.” This could be viewed as a long-term form of communication.
We could call it DRAC for fun. :-) Discuss – Root causes – Actions – Codify. If you’re in the mood for creating acronyms, feel free to come up with your own.
If you thoroughly analyze the mistakes, make conclusions and take lessons for your onward journey, a failure in one project might become a step toward much better results on your next one. Project failure is an abundant source of professional wisdom, albeit an expensive one. You can get a good discount on that price, if you carefully manage your risks through prototyping, pilot projects, smaller iterations, and studies specifically built to prove or disprove your key assumptions. Something that is a failure if it breaks an operational assumption of a big project instead becomes a data point if it’s an experiment by design. To wind it up with another great quote: Malcolm Forbes wisely noted that “Failure is success if we learn from it.”
Big thanks to Elizabeth, Terri, Bob and Peter for sharing their great lessons.
