Voices on Project Management

> Back to Voices Home

Lessons Learned: The Key to Project Success

| | Comments (2) | TrackBacks (0)
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?

 

Bookmark and Share

 

The views expressed within the PMI Voices on Project Management blog are contributed from external sources and do not necessarily reflect the views and opinions of PMI.

0 TrackBacks

Listed below are links to blogs that reference this entry: Lessons Learned: The Key to Project Success.

TrackBack URL for this entry: http://blogs.pmi.org/mt-tb.cgi/661

Leave a comment

All comments are reviewed by our moderators, and will not appear on this blog unless they have been approved. Comments that do not relate directly to the blog entry's contents, are commercial in nature, contain objectionable or inappropriate material, or otherwise violate our User Agreement or Privacy Policy, will not be approved. For general inquiries not related to this blog, please contact Customer Service. Please read the Comments -- Question and Answers.

2 Comments

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.

This is my own experience. Hope it helps.

Dmitri,
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.

About This Blog

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.

All posts represent the opinions of the bloggers.

Follow PMvoices on Twitter

About Bloggers

Keep checking back because the voices for this blog will continue to grow and change to represent a variety of regions, industries and opinions.

Read blogger profiles

Voices Poll

Categories