The Professional Project Manager

When I am teaching project management and we get to the subject of lessons learned I often make a joke that if people did lessons learned properly that consultants like me would go out of business – In truth, I’m only half joking. But the point I am making in jest is that if companies fully committed to gathering and learning from lessons they wouldn’t need half the advice that consultants bring to the table.

But here’s the thing, there are 3 important steps on the lessons learned process and if you aren’t doing all three you may as well not do any of them.

Here are the 3 steps:

Step 1: Lessons Gathered

This should be a continual effort throughout the life of the project and not just done at the end. You should be regularly asking team members and stakeholders, regularly collecting data and analysing it, regularly holding formal and information sessions all focused on gathering lessons.

Don’t forget that you should be gathering both the good and the bad. Too many people focus on gathering lessons about what went wrong and make the assumption that if you find out what went wrong and do the opposite in the future that somehow you will be doing what’s right – this logic simply doesn’t stack up. Learn to avoid the bad, not do the opposite of it. Learn about the positives and what worked and replicate that in future. Gathering lessons learned should be an accepted and expected practice throughout your entire project lifecycle.

Step 2: Lessons Stored

If you gather the lessons learned and don’t store them, or don’t store them where people can access them, there is no point in gathering them. You need to be able to store them somewhere highly visible where everyone who needs to see them can easily find them, search them filter them and actually learn from them. I’ve seen companies using Excel for this very well, and I’ve seen specialist pieces of software that allow filters, and meta tags, and keyword searches as well.

But I’ve also seen companies gather lessons learned and then store them deep in a sub-folder in the project folder where no one will ever know about their existence. This is pointless and they could’ve just avoided gathering them for the benefit they will bring.

So, please, make sure you have an easily accessible and searchable repository for your lessons learned.

Step 3: Lessons Learned

If you do steps 1 and 2 and don’t actually learn from the lessons then there is no point in doing the first two steps. Learning the lessons and applying them in the future is the key to getting better.

You may have the opportunity to apply lessons learned on the current project to improve its future prospects. You will definitely have the opportunity to learn from the past on future projects and you need to make sure you are actually doing this. Here are some tips to make sure that you apply the lessons learned and reap the benefits:

1.    Insert a section into your project initiation documents that ask “what have you learned from recent similar projects, and how will you apply these lessons to this project?”. This means that right at the beginning that the database has to be consulted and lessons applied to the current project.

2.    Make it a standing item on governance groups agendas. Ask about lessons gathered, stored and how they have been applied to the current project.

3.    Get people to regularly present to others to share the knowledge or put up posters each month showing valuable lesson learned.

4.    Do some data analysis, such as Pareto analysis, to determine which lessons provide the greatest value.

5.    Prize and reward continual improvement and value the time, money and effort spent in gaining individual and organisational wisdom through lessons learned.

So, make sure you are gathering AND storing AND learning from experience to get the full benefits.

On a final note, I can guarantee you that if you do gather, store, and learn from experience you will get better at delivering your portfolios, programmes, and projects.

Survivorship bias is a logical error that focuses on the survivors of a particular process, while overlooking those that didn’t make it. In the context of project management, this can lead to misguided conclusions about what it truly takes for a project to succeed.

The term "survivorship bias" originates from wartime observations when aviation experts examined planes that returned from battle in WWII to identify where they had taken the most damage. They mapped where all the damage was found and then with this information they considered reinforcing these areas to make the planes more resilient. However, a statistician named Abraham Wald pointed out a flaw in this approach. The planes they were examining had survived, despite their obvious damage. It was the planes that didn't return—those hit in other critical areas—that needed to be studied. By only looking at the survivors, they were missing vital data on the planes' vulnerabilities and in fact had they gone ahead they would’ve reinforced areas of the planes that didn’t need reinforcing, and not reinforced areas that did.

How does this relate to project management?

Imagine you want to discover the secret to successful project management (and who doesn’t?). You might be tempted to analyse only successful projects and identify common factors in them (like mapping damage to aircraft that made it back). You then describe successful project management according to these traits of these particular projects and focus your training on these processes, tools, techniques or competencies. On the surface, this seems logical right?

But here's the catch: by only looking at successes, you're missing out on a vast amount of data from projects that failed (the planes that didn’t return, and the reasons they didn’t return). These failures can offer crucial insights into pitfalls and challenges that successful projects either avoided or overcame (sometimes by dumb luck!).

Fortunately for us the world of project management is littered with failures. In fact, it could be argued that the ‘norm’ in project management is failure – after all, most projects are somewhat unique, and subject to a myriad of constraints and risks. I’ve never shocked at those oft repeated statistics that 60-70% of projects fail, often used by people to ask what is the point of professional project management when this figure hasn’t changed over 10 or 20 years. I always think that the number is a constant because that’s just what projects are – failure magnets – and yes, that’s a topic for another post but chime in on this if you want.

Success is not just a product of hard work, planning, and strategy. Sometimes, it's also about being in the right place at the right time – plain old dumb luck. Recognizing the role of luck in project success is essential. Also, don’t discount the role of external factors beyond the control of the project manager. Two projects could be managed similarly, but external factors, timing, or sheer coincidence could lead one to thrive and the other to flounder.

For instance, a company might initiate a project to launch a product just when there's a sudden surge in demand due to unforeseen circumstances, making the project seem brilliantly managed and executed. Another similar project might face unexpected competition or market changes. Is it fair to label one as superior management and the other as lacking, without considering the impact of luck, coincidence, or external factors?

And that’s why it’s important to analyse and learn from success AND failure. So yes, I’m saying celebrate failure as a learning opportunity. I’m not saying throw a party, give bonus’s and promotions, and advertise to your clients how wonderful you are at project failure. I’m saying, treat them as real opportunities to learn something that will help you be more successful in the future.

So don’t fall into the trap of survivorship bias. We all want to be more successful at delivering projects but to truly understand project management the factors that contribute to project success, we have to consider both the winners and the losers. So, maybe at your next monthly community of practice meeting, or your next post implementation review, or your next portfolio planning session, take time to have someone present about failures and what they learned from them. Do this without judgment, compare it to what you learn from successes, and you are probably on your way to discovering what makes your projects successful (oh, and please take time to really define project success and how you will measure it – again, that’s a topic for another blog, but chime in on this if you want).

Why do people insist on making the same mistakes over and over again? Why do project managers not take the time to learn from the experience of others and also to record their own experiences for the future?

This blog is all about the value of documenting and using lessons learned.

I dream of a perfect project management world where every time a project manager is given a new project to work, they spend those first few hours, or first day, sitting somewhere reading lessons learned from past projects learning what the previous project manager of the team did well and also learning but they didn't do so well. Imagine a world where you can then repeat their successes and avoid their failures. These lessons learned could be stored in a central database or library and be available as hard copy or a searchable electronic version.

Imagine reading about the experience of others in relation to choosing the right projects, getting the right project team members, defining risks on a project, accurate time and cost estimating, dealing with stakeholders, quality issues and any other aspect of the project. You would learn a lot and also get a real head start on project planning. If you don’t do it, you are condemned to reinventing the wheel again and again.

Gathering lessons learned as a relatively easy process. You can start to do it at any point in a project; you don't need to wait for the end. You can do it formally through structured interviews, surveys and feedback sessions. You can also do it informally through your own observations. Obviously in order to do it successfully you need to plan to do it along with all your other project activities, and as such you need to have time, and perhaps money, set aside to carry out the work associated with gathering, documenting and storing these gems. The cost to any project of doing this work is easily offset by the direct savings and efficiencies gained on both future projects and an overall increase in organizational knowledge, wisdom and efficiency.

In addition to the lessons learned gathered during and at the completion of the project, one of the most underrated pieces of lessons learned is the post implementation review which in my experience is just not done often enough. The real value in completing a post-implementation review is to revisit the project some time after it's been completed and you check whether it did it achieve the things that you thought it would achieve. Too many people make the assumption that delivering the intended project output results in the planned outcomes. A simple post implementation review conducted 6 months later will reveal whether it did or not, and contribute to your future project selection, planning and execution.

So, start recording your lessons learned right now. Sit down and start a document and add to it over the course of your project. Encourage your colleagues to do the same and over time you will build up an impressive collection of data that will help increase the chances of project success.