Your monthly dose of insightful Project Management articles

Your monthly dose of Project Management articles.

Lessons (Un)Learned: How Project Managers can learn from their mistakes - A closer look into the Aircraft industry example

Mistakes are part of our daily lives. They are unavoidable, thanks to our human nature. But, we can learn a lot from them. Lets take a look on an industry that take lessons from tragedies and strives for excellence every day: The aircraft industry

“Oh yes, the past can hurt. But from the way I see it, you can either run from it, or learn from it.” – Rafiki, The Lion King (Walt Disney Studios)

1. The myth of an "Error Free"environment

When you deal with complex tasks, like projects for example, it is probable that you are dealing with lots of variables, since technical ones to human related issues. Conciliate all these variables and make them work in a way that favors the project and not specific stakeholders may be a giant challenge, which creates the proper environment for erros and misunderstandings.

The first thing to keep in mind is that is impossible to have an "error free" project. Except, of course, if you are working on a very simple project. But, as we know, each time we add a new feature, component or person to the project, the complexity of it will raise - and there is nothing you can do about it - unless accepting the only possible option you have: Raising your awareness and register the significant problems that starts to pop-up.

2. The Pressure factor

As responsible for a project, you will be forced to deliver it as faster, cheaper and more complete as you can. In the most part of the times, you will need to sacrifice something on the way to achieve your goal (the dillema of the triple constraints). This will necessarely have a consequency after the delivery of the project: Something will not work as expected, the results may be worse than the planned, money may be wasted and stakeholders may get disappointed.

I use to say that, while we are only losing money, it is not the end of the world. Why? Because, in the end, every project aims to increase market share, profits, introduce tendencies and so on. But, some projects do this having the human life as the primary source for achieving their profits. And, when we add human lives as a medium to achieve our goals, things get more complicated.

3. The Aircraft Industry

Lets take a look in the aircraft industry: A multi-millionaire, high technological, precise and methodical industry where the error margin must be very close to zero (close, but not zero, because as I mentioned before, it is impossible).

All the caution and controls, contingencies, backups, "B" plans sometimes are not enough to avoid mistakes. And, a mistake here may lead to hundreds of lives lost.

But, as we see during the history of aviation, this industry is always evolving: If we compare the number of accidents over the years, we will see that the numbers fall every year and each every new plane project.

Aircraft accidents per million departures - From 1960 to 2014 - Source: The Guardian (click to read the full article)

As we can see, despite of the more complex systems onborded on the modern aircrafts and the higher flight authonomy and reach of the new models, the number of accidents is descending over the years. Of course, the technology has improved, which makes the aircraft safer. But, also makes the complexity of the projects increase.

Still, there are accidents. But, if we analyze how many planes depart and arrive around the world daily, we can consider that the crash numbers are very low. Flying is the safest way to commute from one point to another.

But, how did this industry could achieve so reduced indexes of accidents? Lots of this are related to the new technologies onboarded and very strict processes but, in my very humble opinion, lessons learned and detailed investigations have a huhe contribution on those figures.

4. Evolutions from Tragedies

The aircraft industry have a very disciplined and strong culture of processes and measurement, typical of any area that is reigned by the enginnering. Every single screw or piece of plastic are exhaustevely tested and measured. Full operating prototypes are built to test all the systems, mechanical parts, fusellage, engines in the most diffent conditions. After concluded, a new model may still take some years until get into commercial operation.

But, after getting into service, companies continue to monitor their aircraft, in close cooperation with their clients (the airlines). Also, the strong regulated aircraft industry, that counts with a complex network of airlines operators, governamental departments, International independent organizations that collaborates with each other, creates a culture of continuous improvent.

Many of the technologies that we rely today, when boarding into a brand new Airbus A350-900XWB or Boeing 787-9 Dreamliner came up after hundreds of lives lost. Unfortunatelly, on a mission-critic industry, the progress and learning come, sometimes, from bad results. In this case, fatal crashes.

But, what does it have to do with Lessons Learned?

Lessons learned is a process that must be started from the first day of the project. One of the biggest mistakes a Project Manager do is to consider that the Lessons Learned should start in the end of a milestone or in the end of the project.

Aircraft industries conduct reviews at every step of a process, since the conception to the whole lifecycle of the aircraft. From the first draft of the design to the last airplane delivered, the industries are monitoring their planes, receiving constante feedbacks from their clients (the airlines) reports from regulators

But, the aircarft industry goes beyond that. When the worst happens (and, in this case, when a plane crashes), a team of investigators and specalists is dispatched to the accident site to understand what went wrong. An extensive, detailed, in-depth and long analysis process of investigation will start and pursue every single detail from the moment of the departure to the crash. It is much more detailed than a "Lesson Learned" process but, if we take a close look on how it is conducted, it should be considered as part of the Lessons Learned - for the project of the specific accidented aircraft and for the whole industry.

But... it happens during the production, not during the project

Indeed. Of course, during the construction, the project team interacts with each other sharing their experiences and things that went wrong in order to avoid them to happen in the next delivery gate and, also, to do not happen in the next project. And, if something very critical happens, the team will raise their hands and correct the problem before move on to the next deliverable.

But, although an aircraft is intensivelly tested during the project lifecycle and the homologation phase, the most though situations that an aircraft will face is during its operation. Unexpected climate conditions, operations constraints, emergencies on board... all those things can start a chain reaction in some systems of an aircraft that can trigger a small detail that was not thought during the design phase. Or, if it was, some specific and rare condition may happen, leading to an undesired result.

Bringing The Example to our Reality: Lessons learned as a Cultural Behaviour

Aircrafts accidents reports and lessons learned processes are exceptionally complex due to the mission critical nature of their purposes. But, we can "lower down" the expectations to fit them to a reality that can be compatible with our daily lives

Establish a Lesson Learned culture is, in my opinion, a role of the PMO. Many PMO's, to reduce the delivery time, includes the Lessons learned process as something optional in their framework. Or, simply conduct it for the sake of document fulfilling and audit compliance.

The Project Manager is the agent of implementation of this process. He must be the "evangelist", stressing out the importance of this process in the improvement of the next projects and in the next deliveries.

Also, he must be the responsible to gather all the feedbacks from other team members and register it.

Sponsorship of the Head of the PMO is also essential for the success of the process. The PMO head must use his influence to convince the C-Level that the participation of their subordinates in the Lessons learned process is essential to avoid future mistakes and rework.

The excuse of "lack of proper tools"

Many Project managers states that the Lessons Learned process is not carried out due to the lack of a proper tool

Although having a proper tool to register ther lessons learned and facilitate the retrival of those information in the future is a differential, it is not essential to diffuse the process.

Microsoft Word or Microsoft Excel have all the features required to develop a template to register the lessons learned properly. Lots of templates ideas are scattered over the Internet. Look after some of them and adapt your own model.

This process is a clear example where the discipline overcomes the technology. You just need to insist to implement this

Lessons learned as a Continuous improvement Process

As mentioned before, in the example of the Aircraft industry, Lessons Learned process go on after the planes get in service. This is common on industries where the final product will last for a long time and, usually, works for mission critics environments (cars, trucks, airplanes, heavy machinery, etc).

Receiving feedback from the customers is a way that the manufacturers can improve the next versions and provide patches and improvement for the current versions of their products.

But, more than this, those feedbacks sometimes helps to change products drastically - or even discontinue some of them.

One suggestion is to promote a more integrated work between the PMO and Operations area. Regular meetings to present the results of the project delivered to the business areas may improve the future work of the PMO and project teams.

Some companies have a Continuous Improvement area (Quality / Processes Improvement / Total Quality Management, etc.) that may serve as a mediator between the PMO and Business areas. Normally, those areas have tools and techniques that can help both PMO and business on improving their work.

This is, in a very smaller proportion, what happens in the aviation industry: A network of organs, areas and companies that share information constantly to improve the quality of the work

It adds complexity!! I cannot deal with all those things!

Believe me, the complexity it will add will be much lower than the rework and the money spent in future projects.

The first thing to know is that Lessons Learned process is included in the job description of the Project Manager and is one of the resources that should be implemented in a Project Management Framework. And it can be easily integrated to the daily tasks of a project manager. Writing down what he thinks that could be done better and how problems were solved is a great way to keep track of the bad things that happened along the way

A template form can be created, also, to keep track of the details of each problem. Date, triggers, detailed descriptions, contingency plans, etc. It should be created to be adherent to the needs of YOUR company and YOUR projects. Like all other forms, it is recommended often reviews of the document to ensure that it is evolving as the project management maturity evolves.

Keeping constant contact with the user area is a great way to observe the progression of the project and their pitfalls. With this in hands, you can try to associate the problems during the running life of the project with the problems you've registered during the project management. It can really add value to the next projects.

Again, I insist, it should not add extra complexity. All the things I've mentioned above are already part of the project manager job. Maybe, creating a follow-up culture with the production areas is something to work on. But, again, due to the capilarity of the PMO, it should not be something too complex.

Start Slowly

This is a process that should be implemented slowly, constantly and demands discipline, insistence and monitoring.

I suggest that you start with small projects, registering the problems you find in a way that can be easy to insert into an spreadsheet or PPM system.

Register the things that you think that could be improved and ask to the members of the teams what they think that could be improved in the future. It will create a database of ideas and suggestions that can be implemented in other projects or in other phases of this same project.

Also, if you identify one error try to find out the root cause of it and, while you and the responsible teams work on the definitive solution, map the temporary work-arounds to keep the project going. Also, escalate the problems to the right persons with the correct authority level to speed-up the solution.

It is important to monitor how much time the team has taken to achieve the definitive solution, the main issues during the process and how they were solved.

All of this must be kept with the documentation of the project and, in case of you do not having a PPM tool available to consolidate the lessons learned in one only tool, you can create a network repository, a Sharepoint site or any other solution that your company allows you to use.

Just Start!

If you, as a Project Manager, don't have the support of your superiors to establish this as a formal process, you still can do it by yourself. It won't take much more of your time and will add much value to your project and for the next ones. And, as soon as your peers start to see what you are doing, it can be spreaded. If you are committed with the quality of your projects, you can bet it will be a great tool for you.

Exclusive 💬

Yuri Ficher

About author

Chief Administrative Officer – Central Europe Technologies

High-seasoned Project Management executive with more than 10 years of experience, acting in several different large organizations in different market segments (aviation, software development, IT infrastructure, government and financial institutions) always focusing in IT projects. Has successfully implemented project management frameworks and PMO’s and leaded mission-critical and strategic projects, always trying to find the right balance between control and agility. Based in Bucharest, Romania currently managing IT, Security and PMO areas and sensitive projects in a Software development Shared Service Center.
View all articles