Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with--or even disagree with--leave a comment.
What lessons do we learn from projects? What do we look for from the lessons, both as individuals and organizations? What value do lessons learned deliver in future projects?
Lessons that we choose to learn from our projects are based on the purpose that is set for the project. Purpose is the key. In the project postmortem review, we need to focus on what was or wasn't met as a goal. What worked or didn't work in the use of the methodology and resources? What worked and didn't work within the project team and its members?
To understand what can be improved on a project, it's essential to always look at the original goal or objective, the initial assumptions and the project management plan. Looking solely at the end result with a narrow view of the cause-and-effect elements can lead to a long report with no actionable improvements to positively impact the organization's future.
A lessons-learned review is effective based on the questions asked about the project results, the purpose for the postmortem and the implementation of the review findings into the organization. An effectual review could be the key factor to the success of future projects and organizational improvements.
How do you successfully use a lessons-learned review?
You got the point I thought over the last time :-)
In my opinion, project review should be done in sake of internal improvements in:
1) corporate PM methodology (here we determine an efficiency of our tools' usage, then update them)
2) corporate product strategy (here we determine an effectiveness of our deliverables - including products we deploy through projects, then update the product matrix)
3) corporate CRM (here we analyse project stakeholders' behavior and update their profiles in sake of maximum fit of their work practice in following projects, then update the clients policy)
Also project reviews - in case of standardizing of their collection process - can be used for improving public PM bodies of knowledge (sure it fully applies to 1) due to commonly used confidential and commercial information restrictions.
Christopher Jackson, PMP
In my own experience, I support a projectized workload in a functional organization that, for my workload, typically has a long repair cycle time (12-14 months per iteration). The individual assets that make up the workload have never been through a "cradle to grave" overhaul process before, each asset has received varying degrees of "field fixes" and application of modifications, so each asset that comes into my organization can have wildly varying degrees of requirements. To make matters worse, we historically only see one asset at a time, so the repair cycle time alone can be a big enemy to us. I'm a project expediter rather than a project coordinator (or even true PM), and we have found lessons learned to provide the following benefits:
1. We base some of our lessons learned based on documenting where schedule bottlenecks REALLY are (instead of allowing the blame game that often plagues functional organizations). We use MS Project to track schedules, and we date the various iterations, so we use these files as our lessons learned discussion points. Color-coding allows us to identify new scope, whether through decomposition or as the result of scope creep. This allows us to better manage customer expectations regarding project completion (when the asset is returned for use).
2. Another tool we use is meeting minutes from our project status meetings. Sometimes during open discussion at the end of the normal agenda, new things come up that allow us to tweak a process here or there -- something that will help us remember something important in the future.
3. We also regularly use action registers, and the PM team is constantly reviewing these registers for items that were initially intended for a specific past asset to see if it applies to a current asset (or even potential future assets) that come in for overhaul. Our "lessons learned" master document is even an action register of sorts, except that it's organized by component or phase instead of due date. These activities have helped us to build continuity of knowledge in both the rank and file and management echelons -- in essence, ALL of the stakeholders. Not all stakeholders know how to use MS Project, and not all of the stakeholders (especially upper management echelons) come to the weekly meetings.