Design by Steven Goeman | © 2021 GAPS BV

PROJECT MANAGEMENT MENTOR

PROJECT MANAGEMENT

MENTOR

PROJECT LESSONS LEARNED

THEY ARE NOT ONLY IMPORTANT AT THE END OF YOUR PROJECT !

PROJECT MANAGEMENT & LESSONS LEARNED…

… has already been discussed many times. And still on a lot of projects lessons learned are merely considered. Often project managers do not know what to do with project lessons learned, neither to they consider them at the most appropriate moment. Even project management educators most of the time handle them very briefly and often as part of project or project phase closure. Where it is actually put into a project management training program is not really important; it is already a good thing lessons learned are being discussed as topic! Where it is positioned in a training program is where it can best fit the storyline that is used. On the other hand, if on a project, lessons learned are only considered at the end of your project, during the project closure phase, it is already too late. If lucky, you can only capture some lessons learned from the last weeks, perhaps the last month if you and your project team have a good memory, but you will miss a lot of those useful lessons. Lessons learned are often only considered in the context of capturing them, but what is the use of only capturing when they are later on in the project not used?

WHAT ARE PROJECT LESSONS LEARNED THEN ?

Project Lessons learned are nothing more as the words state: it is about learning the lessons of the past. The learnings can be on anything, but obviously seen in the context of project management, it is about lessons we can learn from the past of our current and former projects. If you are looking for a more formal definition, the Guide to the Project Management Body of Knowledge (PMBOK-6th edition-p.709), published by the Project Management Institute, states that: “lessons learned is the knowledge gained during a project which shows how project events were addressed or should be addressed in the future for the purpose of improving future performance.” Lessons learned are important as they are a reflection moment on how things have been for now and to reflect about what we can do with them. As it is reflection, you need to foresee the time to do it. Rushing in lessons learned for the sake of it, is actually just a waste of time. Lessons learned are often seen as negative events and problems on the project, which is only partly true. Lessons learned should also, and perhaps by preference, focus on the positive events. Because those things that went well are perhaps more valuable to understand so we can surely apply them again on the future of our project(s). Lessons learned are not only about registering the positive or negative lesson. It is even more important to look at what actions were taken to resolve for example a problem and to assess if that actions has resolved the problem or not. That is actually the real lesson to be observed: did our management action deliver the results that we wanted to obtain. Whilst lessons learned are triggered and organized from the project management, lessons learned do not only relate to the management of the project. Also situations that occurred during for example the design process of the project product, or during the construction of the prototype, or lessons that can be observed out of the testing process, or on the interactions with a 3rd party contractor, are all valid considerations as part of the lessons learned capturing.

WHY ARE LESSONS LEARNED USEFUL ?

As already stated above, lessons learned are a reflection moment. If enough time is foreseen, it allows you as a project manager, but also the project team, to pause the daily hassle and build-in an useful rest moment. Useful because it will allow the project team to take a helicopter view on the project. Because we all get out of the details, new ideas will develop. That is just how the human mind works… Project lessons learned is also a form of self-criticism. Probably that is, next to the time stress that most projects today suffer from, one of the reasons why unfortunately so little attention is given to lessons learned during the project. Self-criticism and self-evaluation forms however the basis for self-improvement in personal development, but that principle is also true for projects. If you want your project (management) to improve for the current but also the future projects, this kind of evaluation is a crucial element.

LESSONS LEARNED IS A SYSTEMIC AND CONTINUOUS PROCESS !

Whilst in risk management, the continuous character is considered as evident, it seems that the repeating character throughout the project’s duration for lessons learned is less recognized. In a lot of cases, project lessons learned is considered as part of the project or project phase closing. But when we consider PMI’s PMBOK again, it is clear that the lessons learned is considered as part of the Executing process group, and we all know that the process groups are iterative over the project’s duration. More particularly, registering lessons learned are considered as part of the “Manage project knowledge” process, which in itself is a recurrent process. Capturing the lessons learned throughout the project, and not only at the end, has the great advantage to be able to use them right after they have been identified, therefore becoming extremely useful for the current project at hand. The question now is how the specific steps, as part of the above mentioned Manage project knowledge process can be modelled. One way to look at it is making use of my Lessons Learned Processing Method which I apply on all my projects. It is built around the project management lifecycle where lessons learned can be considered during the execution of a project phase, during the closing of a project phase, and during the start of a (next) project phase. During the execution of a project phase, whether is the initiating phase, implementation phase or even closing phase, as a project manager you should be continuously attentive to the identification of lessons learned. There are different channels through which lessons learned will reveal themselves. Some examples of lessons learned channels are: Your project monitoring & controlling activities; Issue management; Status meeting discussions; Specific (end of phase) lessons learned sessions; Project variance analysis; Individual team member concerns informally brought to you; Etc. The trick will be to find ways to capture them and register them in a so called lessons learned register, which can be as basic as a structured spreadsheet, a small self-developed database or even a full software solution. Step 1. Register Register the lessons learned in the so-called lessons learned register. Do not only mention the triggering situation, but also and especially consider the actions taken to mitigate or to stimulate the respectively negative or positive triggering situation. The lesson to be learned is after all to assess whether the actions taken were helpful in realizing the intended objective and/or result. To be able to that, it will be required to come back a second time to the initial registration after the taken actions have had some time to prove themselves. Step 2. Structure Once registered, it will be important to bring structure in the lessons learned. The structuring is very important to make the lessons learned searchable. For now this is not that important, but later on when our project lessons learned will be documented to be used on future projects, or simply to make them usable for the later stages of our current project, when lessons learned are not easily retrievable, the will just be stored but never used. That would be a petty of the time spend to it. You can invent a specific structure and categorization system specific for the project, but if the standing organization already has a lessons learned repository, it would be wise to copy or at least align with the existing structuration in that repository. Typical categorization items are: Project type (e.g. Engineering, Construction, ICT, etc.); Project phase (e.g. conceptualization, implementation, etc.); Product complexity (e.g. low-medium-high); Project magnitude values (e.g. time, budget, etc); Management domain (e.g. scope , communication, etc); Involved departments (how many departments were involved); Some free categories that will be set by the project stakeholders themselves; Etc. Step 3. Analyze Once the lessons learned have been captured, a detailed analysis is very useful. Whilst the capturing steps are throughout the project and a moment of capturing is not really plannable (exceptions do exist: for example a specific lessons learned capturing session can be planned) because the triggering events just happen, the analysis can be planned. Analyzing could be seen during the closing of a project phase, but in larger projects, with very long duration phases, it might be insufficient. Therefore, I like to align the lessons learned analysis with the preparations of the steering groups, which are in most cases organized in a monthly sequence. Doing so will have the additional benefit that the lessons learned themselves can be considered as an input to your steering group meetings. That is what we call catching two flies with one stroke! Step 4. Document In this step, by preference to be performed immediately after step 3, the analyzed and retained lessons learned are transferred to the lessons learned repository, maintained by the standing organization. A good lessons learned repository would already have the functionality of immediately registering project lessons learned. That would at least minimize the extra administration step into merely switching a flag as from “only available to the project” to “available to all organization”. Documenting the lessons learned in a centrally available and searchable database or repository is crucial if we want to assure that the lessons learned will become useful for other and future projects that will be ran in and by the organization. Step 5. Use During the closing of the project phase (or the project), the lessons learned related to this project can be retrieved to perform a retrospective, a reflection of the project team on the (corrective) performance of the project. During this retrospective, the focus should lay on the lessons learned that have a positive effect, in order to maintain the taken actions for the next phase of the project. As project planning and scheduling for the remainder of the project (high-level) and the next project phase (in detail) is typically reviewed with a rolling-wave planning system during the closure steps of the project phase, using the lessons learned will enable project success as it will be taken into account in the overall project approach. Step A. Search & Filter Especially at the start of a project in the pre-project phase or the initiating phase, it is a good idea to look into the organization’s lessons learned repository for lessons learned of former projects to be able to apply on the project at hand. The latter is also valid for the lessons learned related to all other project phases, but typically, the lessons learned repository is most useful at the start of a project. As the lessons learned repository grows as the organization performs more and more projects, there will be a lot of lessons learned that are less relevant to the unique context of the project you are currently working on. Therefore there is a need to have that repository searchable. It is a best practice to consider a fixed set of values per category, which will allow the filtering. When going through the central lessons learned repository, the user can then finetune which lessons learned will be displayed. Depending on the available categories could then filter in such way that for example only those project lessons learned are displayed that relate to: ICT projects; In the conceptualization phase; For the managing the scope; With a high complex project product; Making use of new never used before technology;

FOUR TIPS ON PERFORMING LESSONS LEARNED

To conclude the project management article, we love to give you some last recommendations/ tips when working with project lessons learned: 1. Firstly, do not only focus on the negative triggering situations and problems. In a lot of cases more valuable lessons can be learned from what went well and what is thus to keep for the next phases of your project. 2. When reflecting about the lessons, one should consider the situation which is the triggering event, but should even more consider the (management) action that was put against it. Consider the effect of that action and how it contributed to the success of the project or the change of the (negative) situation. 3. Implement lessons learned as part of your status meetings with the team. Just like considering the status on risks, scope changes, etc are a recurrent element of status meetings, you can put lessons learned as part of your status meeting and reporting. It is even a nice link when you discuss the status on project issues. But watch out when you link the lessons learned reflection with your issue management that the lessons learned are not solely focused on the negative situations or events. 4. Whilst capturing the lessons learned is often considered as the sole responsibility of the project manager, it is a good idea to make it a team effort. Assure to implement a simple lessons learned register that can be used by any directly involved stakeholder and have them to register the lessons learned themselves. It will be a good preparation for the analysis of the lessons learned and the registration workload is spread over different individuals. Many hands make light work… The Project Management Institute (PMI) and the Project Management Body of Knowledge (PMBOK) - guide are registered trademarks and copyrighted. You can find more information on the website: www.pmi.org.

ABOUT THE AUTHOR

Steven GOEMAN is a certified project management professional and a licensed Master of Neurolinguistic Programming with more than 20 years of project (management) experience. He is the creative mind behind the renowned brand “The Project Management Mentor”, enabling him to share his expertise on portfolio management, program management and project management as an empathic project management coach and project management mentor. Steven founded GAPS BV (https://www.gaps.be) in 2005 from which he successfully assisted many individuals and organizations with project management related mentoring, coaching and consulting services. How to reference this article: Goeman, S. (2021, 03 July). Project Lessons Learned. GAPS BV. https://www.gaps.be/Mentor/project- management-articles/2021/pmart202108-project-lessons-learned.htm .
· · · · · · · · · · · · · · · · · · · ·
Download this article

PROJECT MANAGEMENT MENTOR

PROJECT MANAGEMENT

MENTOR

Design by Steven Goeman | © 2021 GAPS BV

PROJECT LESSONS

LEARNED

THEY ARE NOT ONLY IMPORTANT AT THE END OF YOUR

PROJECT !

PROJECT MANAGEMENT &

LESSONS LEARNED…

… has already been discussed many times. And still on a lot of projects lessons learned are merely considered. Often project managers do not know what to do with project lessons learned, neither to they consider them at the most appropriate moment. Even project management educators most of the time handle them very briefly and often as part of project or project phase closure. Where it is actually put into a project management training program is not really important; it is already a good thing lessons learned are being discussed as topic! Where it is positioned in a training program is where it can best fit the storyline that is used. On the other hand, if on a project, lessons learned are only considered at the end of your project, during the project closure phase, it is already too late. If lucky, you can only capture some lessons learned from the last weeks, perhaps the last month if you and your project team have a good memory, but you will miss a lot of those useful lessons. Lessons learned are often only considered in the context of capturing them, but what is the use of only capturing when they are later on in the project not used?

WHAT ARE PROJECT LESSONS

LEARNED THEN ?

Project Lessons learned are nothing more as the words state: it is about learning the lessons of the past. The learnings can be on anything, but obviously seen in the context of project management, it is about lessons we can learn from the past of our current and former projects. If you are looking for a more formal definition, the Guide to the Project Management Body of Knowledge (PMBOK-6th edition-p.709), published by the Project Management Institute, states that: “lessons learned is the knowledge gained during a project which shows how project events were addressed or should be addressed in the future for the purpose of improving future performance.” Lessons learned are important as they are a reflection moment on how things have been for now and to reflect about what we can do with them. As it is reflection, you need to foresee the time to do it. Rushing in lessons learned for the sake of it, is actually just a waste of time. Lessons learned are often seen as negative events and problems on the project, which is only partly true. Lessons learned should also, and perhaps by preference, focus on the positive events. Because those things that went well are perhaps more valuable to understand so we can surely apply them again on the future of our project(s). Lessons learned are not only about registering the positive or negative lesson. It is even more important to look at what actions were taken to resolve for example a problem and to assess if that actions has resolved the problem or not. That is actually the real lesson to be observed: did our management action deliver the results that we wanted to obtain. Whilst lessons learned are triggered and organized from the project management, lessons learned do not only relate to the management of the project. Also situations that occurred during for example the design process of the project product, or during the construction of the prototype, or lessons that can be observed out of the testing process, or on the interactions with a 3rd party contractor, are all valid considerations as part of the lessons learned capturing.

WHY ARE LESSONS LEARNED

USEFUL ?

As already stated above, lessons learned are a reflection moment. If enough time is foreseen, it allows you as a project manager, but also the project team, to pause the daily hassle and build-in an useful rest moment. Useful because it will allow the project team to take a helicopter view on the project. Because we all get out of the details, new ideas will develop. That is just how the human mind works… Project lessons learned is also a form of self-criticism. Probably that is, next to the time stress that most projects today suffer from, one of the reasons why unfortunately so little attention is given to lessons learned during the project. Self-criticism and self-evaluation forms however the basis for self-improvement in personal development, but that principle is also true for projects. If you want your project (management) to improve for the current but also the future projects, this kind of evaluation is a crucial element.

LESSONS LEARNED IS A SYSTEMIC

AND CONTINUOUS PROCESS !

Whilst in risk management, the continuous character is considered as evident, it seems that the repeating character throughout the project’s duration for lessons learned is less recognized. In a lot of cases, project lessons learned is considered as part of the project or project phase closing. But when we consider PMI’s PMBOK again, it is clear that the lessons learned is considered as part of the Executing process group, and we all know that the process groups are iterative over the project’s duration. More particularly, registering lessons learned are considered as part of the “Manage project knowledge” process, which in itself is a recurrent process. Capturing the lessons learned throughout the project, and not only at the end, has the great advantage to be able to use them right after they have been identified, therefore becoming extremely useful for the current project at hand. The question now is how the specific steps, as part of the above mentioned Manage project knowledge process can be modelled. One way to look at it is making use of my Lessons Learned Processing Method which I apply on all my projects. It is built around the project management lifecycle where lessons learned can be considered during the execution of a project phase, during the closing of a project phase, and during the start of a (next) project phase. During the execution of a project phase, whether is the initiating phase, implementation phase or even closing phase, as a project manager you should be continuously attentive to the identification of lessons learned. There are different channels through which lessons learned will reveal themselves. Some examples of lessons learned channels are: Your project monitoring & controlling activities; Issue management; Status meeting discussions; Specific (end of phase) lessons learned sessions; Project variance analysis; Individual team member concerns informally brought to you; Etc. The trick will be to find ways to capture them and register them in a so called lessons learned register, which can be as basic as a structured spreadsheet, a small self-developed database or even a full software solution. Step 1. Register Register the lessons learned in the so-called lessons learned register. Do not only mention the triggering situation, but also and especially consider the actions taken to mitigate or to stimulate the respectively negative or positive triggering situation. The lesson to be learned is after all to assess whether the actions taken were helpful in realizing the intended objective and/or result. To be able to that, it will be required to come back a second time to the initial registration after the taken actions have had some time to prove themselves. Step 2. Structure Once registered, it will be important to bring structure in the lessons learned. The structuring is very important to make the lessons learned searchable. For now this is not that important, but later on when our project lessons learned will be documented to be used on future projects, or simply to make them usable for the later stages of our current project, when lessons learned are not easily retrievable, the will just be stored but never used. That would be a petty of the time spend to it. You can invent a specific structure and categorization system specific for the project, but if the standing organization already has a lessons learned repository, it would be wise to copy or at least align with the existing structuration in that repository. Typical categorization items are: Project type (e.g. Engineering, Construction, ICT, etc.); Project phase (e.g. conceptualization, implementation, etc.); Product complexity (e.g. low-medium-high); Project magnitude values (e.g. time, budget, etc); Management domain (e.g. scope , communication, etc); Involved departments (how many departments were involved); Some free categories that will be set by the project stakeholders themselves; Etc. Step 3. Analyze Once the lessons learned have been captured, a detailed analysis is very useful. Whilst the capturing steps are throughout the project and a moment of capturing is not really plannable (exceptions do exist: for example a specific lessons learned capturing session can be planned) because the triggering events just happen, the analysis can be planned. Analyzing could be seen during the closing of a project phase, but in larger projects, with very long duration phases, it might be insufficient. Therefore, I like to align the lessons learned analysis with the preparations of the steering groups, which are in most cases organized in a monthly sequence. Doing so will have the additional benefit that the lessons learned themselves can be considered as an input to your steering group meetings. That is what we call catching two flies with one stroke! Step 4. Document In this step, by preference to be performed immediately after step 3, the analyzed and retained lessons learned are transferred to the lessons learned repository, maintained by the standing organization. A good lessons learned repository would already have the functionality of immediately registering project lessons learned. That would at least minimize the extra administration step into merely switching a flag as from “only available to the project” to “available to all organization”. Documenting the lessons learned in a centrally available and searchable database or repository is crucial if we want to assure that the lessons learned will become useful for other and future projects that will be ran in and by the organization. Step 5. Use During the closing of the project phase (or the project), the lessons learned related to this project can be retrieved to perform a retrospective, a reflection of the project team on the (corrective) performance of the project. During this retrospective, the focus should lay on the lessons learned that have a positive effect, in order to maintain the taken actions for the next phase of the project. As project planning and scheduling for the remainder of the project (high-level) and the next project phase (in detail) is typically reviewed with a rolling-wave planning system during the closure steps of the project phase, using the lessons learned will enable project success as it will be taken into account in the overall project approach. Step A. Search & Filter Especially at the start of a project in the pre-project phase or the initiating phase, it is a good idea to look into the organization’s lessons learned repository for lessons learned of former projects to be able to apply on the project at hand. The latter is also valid for the lessons learned related to all other project phases, but typically, the lessons learned repository is most useful at the start of a project. As the lessons learned repository grows as the organization performs more and more projects, there will be a lot of lessons learned that are less relevant to the unique context of the project you are currently working on. Therefore there is a need to have that repository searchable. It is a best practice to consider a fixed set of values per category, which will allow the filtering. When going through the central lessons learned repository, the user can then finetune which lessons learned will be displayed. Depending on the available categories could then filter in such way that for example only those project lessons learned are displayed that relate to: ICT projects; In the conceptualization phase; For the managing the scope; With a high complex project product; Making use of new never used before technology;

FOUR TIPS ON PERFORMING

LESSONS LEARNED

To conclude the project management article, we love to give you some last recommendations/ tips when working with project lessons learned: 1. Firstly, do not only focus on the negative triggering situations and problems. In a lot of cases more valuable lessons can be learned from what went well and what is thus to keep for the next phases of your project. 2. When reflecting about the lessons, one should consider the situation which is the triggering event, but should even more consider the (management) action that was put against it. Consider the effect of that action and how it contributed to the success of the project or the change of the (negative) situation. 3. Implement lessons learned as part of your status meetings with the team. Just like considering the status on risks, scope changes, etc are a recurrent element of status meetings, you can put lessons learned as part of your status meeting and reporting. It is even a nice link when you discuss the status on project issues. But watch out when you link the lessons learned reflection with your issue management that the lessons learned are not solely focused on the negative situations or events. 4. Whilst capturing the lessons learned is often considered as the sole responsibility of the project manager, it is a good idea to make it a team effort. Assure to implement a simple lessons learned register that can be used by any directly involved stakeholder and have them to register the lessons learned themselves. It will be a good preparation for the analysis of the lessons learned and the registration workload is spread over different individuals. Many hands make light work… The Project Management Institute (PMI) and the Project Management Body of Knowledge (PMBOK) - guide are registered trademarks and copyrighted. You can find more information on the website: www.pmi.org.

ABOUT THE AUTHOR

Steven GOEMAN is a certified project management professional and a licensed Master of Neurolinguistic Programming with more than 20 years of project (management) experience. He is the creative mind behind the renowned brand “The Project Management Mentor”, enabling him to share his expertise on portfolio management, program management and project management as an empathic project management coach and project management mentor. Steven founded GAPS BV (https://www.gaps.be) in 2005 from which he successfully assisted many individuals and organizations with project management related mentoring, coaching and consulting services. How to reference this article: Goeman, S. (2021, 03 July). Project Lessons Learned. GAPS BV. https://www.gaps.be/Mentor/project- management-articles/2021/pmart202108-project- lessons-learned.htm .
· · · · · · · · · · · · · · · · · · · ·
Download this article