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.
If you are not having project reviews and meetings to address lessons learned, it may be that your project sponsors do not count these as valuable activities.
You know better, but how do you make a convincing argument to have project reviews?
You must take the discussion with your project sponsor to a different level. It's not "we just need to know what happened." It's "we want to take action and get better results the next time around."
The lessons learned meeting could make you aware of changes that may be needed to turn business from being bleak to being more successful. Give your sponsors succinct reasons to pursue assessing projects to make improvements.
Consider these tips to influence your supporters:
Gather statistics and determine what you need to measure. If your company is concerned about quality, chart examples of projects where quality was lacking. If ROI for projects has not been good, share those examples.
Share success stories. Bring up achievements that occurred because of the attention on improvement. Discuss the situations that will make a difference to the bottom line.
Make a plan. As a project manager, you already know that planning is important. Prepare a well thought-out plan for gathering and presenting the lessons learned. Then use the newly acquired knowledge.
How have you built a business case for lessons learned and project reviews?
I like the idea of capturing Lessons Learned during Project Execution and applying them IMMEDIATELY to the current project.
This gives a very quick payoff and visible value to the capturing of Lessons...
Bill hit the nail on the head about immediacy of impact!
The challenge typically is in bringing all those lessons to the PM at the right time! When planning initially and then planning during the course of the project, responding to risks and issues.
There has to be a compelling way of drawing attention to the relevant lessons and a motivation by the PM to keep learning and improving to get the value from the effort of documenting lessons and avoiding them becoming "lessons repeated".
In my opinion, I find conducting weekly retrospective meetings as the best means to gather the lessons learned.
In this meeting, the team discusses on two major factors - "What went well" and "What went wrong". The team comes up with their views on each of these factors by writing down on the sticky papers.
The papers are grouped together by some means of logical classification and then the team discusses on each of the points highlighted and provide their views. This is a perfect brainstorming which results in identifying valid improvement areas under "what went wrong" and best practises to be continued under "what went well".
For the improvement factors, an owner or a driver is voluntarily selected who will ensure to bring that to the next phase of improvement until it moves to "what went well" list.
This triggers entire team's participation and they get empowered of their job thereby increasing the productivity and resulting in successful project outcome.
The official project review process isn't necessarily the most appropriate place for lessons learned. I'm struggling with this, trying to embed effective knowledge management processes within the project life cycle.
In the organization I work with, the review processes are very well established, but "lessons learned" are perceived as a separate process (somewhat ignored). The key to building a business case for lessons learned is to make sure that the process brings value to the project itself and not perceived as "lessons for future projects."
For this to work, the lessons learned processes -- I prefer to refer to them as "project learning" processes -- need to be embedded within the project life cycle, just like any other iterative project management process.
At the end of each project phase, there should be a set of project learning activities to articulate and capture lessons, most of which will be useful to the project moving forward, not just to future projects.
A good discussion on PM lessons learned.
From my perspective, we Project Managers seem to do well in identification and capturing of lessons learned. I would agree that it works better when the lessons identified are part of the weekly PM process.
Where we fail to get traction is with the dissemination and application of lessons learned. Regards, Stephen
Bernadine Douglas, PMP
Some organizations do consider the lessons at the end of each phase, some at the end of the project, and then some at the end of a number of similar projects. I cannot dictate which is best.
Building the business case would best be tailored for just what you said, making sure that the process brings value, and if that means to the projects at hand vs. future projects, that is great.
I do think, however, the lessons will no doubt impact the future projects as well. So, I would agree that your continuing to use the project learnings at the end of each phase is a good option. It seems to be working well for your organization.
Thanks for sharing.
The weekly retrospectives are working for your team. That is great. It sounds that being empowered to move something to a â€œwhat went wellâ€ list has to also be helping them to be mindful to doing things for the success of the project as the project continues to move forward.
Just remember, that not all organizations may have time to do additional weekly meetings. However, getting to â€œwhat went wrongâ€ to â€œwhat went wellâ€ is going to be a benefit in just applying some attention at all.
Just remember the lessons are not just for the PM. Teams, management, and other stakeholders are benefiting as well.
You make a very good point about the value of using the lessons immediately. Thanks for sharing.
Thank you all for your comments!
Every 6 months, we generate a new Release of DMS. We have the following steps before new release is goes out:
Internal test, automation test and testing pilot customers.
When an error of the programme occured, this is only a punctual effect.This occurred in this release, and never after.
So, the question is: What can I learn with this lesson?
Bernadine Douglas, PMP
Thank you for your question. I do not want to get into prescribing what outcomes should arise from lessons learned. Especially, in your particular situation I would not be able to do this at this point, because I do not know your organization well enough, nor your project team. Not knowing the environment, the various tests you are conducting seem adequate.
However, you may want to start with the team and discuss this release in comparison to previous releases. You may want to have a review of the customer feedback and the test results as part of the discussion. Other inputs seem important as well, such as the testing software, and maybe quality control. I would suggest these factors at a minimum should highlight some lessons you may be able to gain.
"This planet has - or rather had - a problem, which was this: most of the people living on it were unhappy for pretty much of the time. Many solutions were suggested for this problem, but most of these were largely concerned with the movements of small green pieces of paper, which is odd because on the whole it wasn't the small green pieces of paper that were unhappy."