Note that the question above says the “best time” and not the “most convenient” time.
The “best time” should be that time which will allow for reflection, feedback and adjustment of any project assumptions or other parameters which would contribute to project success. It should be that time which will allow win-win solutions to be identified from issues with different viewpoints, as opposed to the compromise solutions which often occur in projects when a full “look back” and “analysis” has not been conducted.
In the past, project lessons learned were often modeled after the “After Action Reviews (AAR)” from the military, in which a review session would be conducted after a military operation in order to capture lessons learned and positively impact the behavior of the team in future exercises. This was a convenient time for such reviews.
The “After Action Review” methodology was carried over to modern project management much as other practices are carried over from one discipline to another….without proper regard to what contributes the most to success in the future endeavors or in the current project at hand.
Instead of waiting until the end of your project, I suggest that you select intervals during the project for such reviews. These could correspond to “stage gates” if your project is organized in such a way, or they could occur at natural or major breakpoints in activities in the project schedule.
Documenting lessons learned at multiple points during a project allows a look back at the assumptions versus reality of the project, and affords the opportunity to define new assumptions for the remaining portions of the project. Also, it allows time for “reframing” or asking the question “What problem are we trying to solve?” with this project.
How many projects have you seen completed where the project team, in looking back at what was accomplished, realized that they had addressed or answered the wrong question? “Framing” and “reframing” the major issues in the project is facilitated by conducting project lessons learned at intervals throughout the project.
Now that you’ve decided to conduct your project review at intervals throughout the project, the next question becomes “What framework should I use for conducting a project lessons learned session?”
The usual questions asked in a Project Lessons Learned exercise are as follows:
- What was the expected result?
- What was the actual result?
- What is the deviation of actual from expected?
- What is the Lesson Learned?
While this is a good starting point for capturing and documenting lessons learned, let’s take this one step further.
I would recommend you look at the work of Roger Martin, Dean of The Rotman School of Management at The University of Toronto, to find a good framework for examining project lessons learned during the course of the project.
Over the course of about fifteen years, Roger Martin studied how successful leaders think. Leaders from many different fields were interviewed and a thought pattern was discerned. Roger Martin termed this “Integrative Thinking” because it differs from “Conventional Thinking.”
Among the features of “Integrative Thinking” which makes it a good methodology for examining project lessons learned are the following:
- Examination of more salient features of the project which might not have been considered when the original project was “framed.”
- An integrative look at other issues which might impact the project so that a holistc view of the project, and its impact on all stakeholders and the environment is considered.
- An attention to architecture of the project and its major issues which give a good overall view of the systems dynamics involved in the project. This also provides clues to “dependencies” between your project’s deliverables and those of other projects, i.e. the fact that projects “give” and “get” information and deliverables during the course of the project life.
- A consideration of opposing viewpoints which does not acquiesce or dominate other viewpoints but which takes into account the valuable features which contribute to a win-win situation rather than a compromise situation.
Let’s take a simple example now.
Suppose your project has four distinct phases, each succeeding phase beginning at the completion of the previous phase in a linear fashion. Also suppose you want to conduct a “project lessons learned” session at the end of phase one.
The sequence of activities you might follow in conducting this lessons learned exercise might be as follows:
- Look at results from Phase One. Are there any assumptions that require revision prior to going into Phase Two based on the results of Phase One? Have you correctly “framed” the problem in this project based on the results from Phase One? Are there any other salient features that should have been considered in the project during Phase One that were not considered?
- From a holistic standpoint and anticipating activities in Phase Two, have we learned anything in Phase One which would impact how we handle Phase Two (or for that matter, any later Phase) activities?
- Have we correctly planned the architecture of the project so that “cause” and “effect” of decisions and actions taken in Phase One can be clearly discerned in Phase Two and later Phases? Are we certain of the “dependencies” between project s and the key “gives” and “gets” between or among projects?
- How are opposing viewpoints concerning decisions and actions in Phase One being addressed? Are we taking the best features of opposing viewpoints to find the final solution or do we still seek compromise when opposing viewpoints clash? How will we proceed to a win-win solution for the project outcomes so that stakeholders are satisfied with the project outcomes?
In conclusion, look for opportunities to conduct project lessons learned sessions and to document the lessons when it makes sense to conduct them.
The real value of project management is when lessons learned are fed back into project schedules and plans, and positively impact project team behavior and resulting project decisions. Success of projects is more assured if lessons learned are taken seriously and every team member takes ownership of both the identification and sharing of project lessons learned.
Jim Atkins says
Mel…..we tried to do a Lessons Learned on the Turgai Project this week.
It was chaired by Anwar Bashir…Phil Schapansky participated….as did Don Ellis via telecon. We spent about 3 hours talking about minute items and did not cover 1 of the 6 pages we were to have covered. When I pointed out that what we were discussing amounted to peanuts relative to the amount of money lost on the project, it fell on deaf ears.
Don’t you think impact items should be prioritized and discussed in that order…..some small things being discussed never change, occur on every job and have no major impact…..
admin says
Yes, Jim, it is important to prioritize the topics for Lessons Learned but, at thesame time, there is no rule that says you have to complete all the Lessons Learned in one meeting. It may take several meetings with different agendas covering different priorities to fully develop and document your Lessons Learned.
As you know, the quality of the Lessons Learned depends a great deal on the capability of the facilitator to bring the discussions to a conclusion on major points at the right time. Continue to develop your facilitators and you will see improvement in the quality of the Lessons Learned.
I encourage you to continue developing Lessons Learned for various projects and you will see a maturity over time in how your project groups handle the process if they gain some experience in the discussion of prioritized issues. Let me know what you think after several more sessions.