"Oh, you've had a problem during execution of a project? Let's start a 'Lessons Learned' document about each type of process so the next time we come across that same issue, we will have the answer already there!"
Certain folks in an IT department will occasionally come up with this idea that sounds good on paper to the layman. I've never done this before, but as someone in the weeds who spends his time fixing problems every day, scouring stack overflow questions, forums, and the like, I have this gut feeling that this would turn out to be more of a time drain than a benefit. I can see the merit of the idea here. But isn't that the point of sites like Stack Overflow? To collect problems that folks have had in the past so that people in the future can look up and solve their problems more easily in the future?
My company is considering doing this. My gut tells me it's going to go very badly, and I'm not sure about whether to speak up or just let it happen.
Take standing up a website on IIS for example. I can think of a dozen issues off the top of my head that can come up when you try to set up an IIS site. I've been setting up sites using IIS for almost 10 years now, and I've seen a lot of stuff. Issues with IIS site deployment can run the gambit from DLL issues, .NET versions, plugins, corrupted files, firewalls, hard drive space limitations, user rights, windows services, viruses, SSL certs, Databases, Connection strings, URL paths, session state issues, server names that have an underscore in them, site bindings, DNS issues, etc...
If I had a document from the beginning of my career that outlined every problem I've had standing up IIS sites and how to fix them, then first of all it would be huge. Second, I don't think I see most of the issues I come across a 2nd time. Third, even 10 years later, I still come across new issues that I've never seen before on a regular basis. In fact, I'd say that at least 40% of issues that come up when standing up an IIS site are issues that I've never seen before and I would need to google anyway. As to the 60% that I come across a 2nd time, I remember the solutions that I did to correct those about 80% of the time, and I wouldn't refer to such a document anyway. That leaves only 12% of issues that I come across with an IIS stand-up that I would refer to that document for.
Am I totally off base here? or are my arguments valid? Are there any more points to this argument that I am not considering either way? Saving Changes...
Mark StewardDirector| Arrow Zee AustraliaSydney, Nsw, Australia
Reviewing an organisations lessons learnt from previous projects should be one of the first things a PM undertakes when starting a new project. Where I have seen this process fall down is when organisations do not maintain an accessible, searchable, centralised repository for this information. If it is left to languish in individual project files the value is lost. The PMO should take responsibility for managing this. Saving Changes...
Mark GrayPM Consultant, Coach, Trainer and more| Self EmployedParis, France
A good question - and a challenging situation.
Here's my penny's worth:
Many organisations implement a so-called "lessons learned" process. The problem is that in most cases it's more like a "lessons captured" (closely related to "lessons archived" which is the prettier cousin of "lessons forgotten")
Don't get me wrong, having the discipline to pause, analyse the problem and the (possible) solutions and then document these is a good practice. If nothing else it structures the analytical and problem-solving process. If these are then collated in a database it starts to look like a library of WWW (what went well / what went wrong)
Problem is these lessons don't get applied - and we run the risk of repeating the mistakes of the past
What's needed? A mechanism (database?) that can capture the essential information (see the comment from Thomas, have a look at the NASA LLIS) but even more importantly is a process that supports the transfer of the knowledge from one project (manager) to the next. This can be in the form of a KM team, a Community of Practice, or a forum like this one here. That way we might actually succeed in turning Lessons TO BE Learned into Lessons Actually Learned.
If you are interested in a (slightly academic but grounded in experience) paper on the topic, contact me direct and I'll send what I wrote for PMI a few years ago :)
Here's my penny's worth:
Many organisations implement a so-called "lessons learned" process. The problem is that in most cases it's more like a "lessons captured" (closely related to "lessons archived" which is the prettier cousin of "lessons forgotten")
Don't get me wrong, having the discipline to pause, analyse the problem and the (possible) solutions and then document these is a good practice. If nothing else it structures the analytical and problem-solving process. If these are then collated in a database it starts to look like a library of WWW (what went well / what went wrong)
Problem is these lessons don't get applied - and we run the risk of repeating the mistakes of the past
What's needed? A mechanism (database?) that can capture the essential information (see the comment from Thomas, have a look at the NASA LLIS) but even more importantly is a process that supports the transfer of the knowledge from one project (manager) to the next. This can be in the form of a KM team, a Community of Practice, or a forum like this one here. That way we might actually succeed in turning Lessons TO BE Learned into Lessons Actually Learned.
If you are interested in a (slightly academic but grounded in experience) paper on the topic, contact me direct and I'll send what I wrote for PMI a few years ago :)
From my point of view they are very valuable.
A smart person always learns from the mistakes someone else did.
We are a community and should share our insights and learnings. Saving Changes...
Gaurav VashisthTeam Lead| BombardierGurugram, Haryana, India
I can say one thing that after each project if you create a lesson learned document it will have a good amount of information similar to last project ( at-least the root cause) . The important part is , how we use the lesson learned document?. Is it for the documentation or are we incorporating these improvements in the next project ( Through processes/tools)?
Agile gives us an opportunity to have the Sprint retrospective. The outcome of these retrospectives incorporated in to next Sprint which create a culture of continuous improvement.
I completely agree with you , each project is different ( dynamics and set of people) and need a different solution. Saving Changes...
Hector RiveraHealthcare Operations Manager | Security Manager| U.S. ArmyHarker Heights, Tx, United States
John,
Having spent the last 26 years as an active U.S. Army Soldier, I can tell you that I have spent countless hours collenting lessons learned or AARs (active action reviews). A few things I have notices are:
1- lessons learned are only as good as the data gathered. Meaning, you must ensure that you are looking at the big ticket items and eliminating the minutia.
2- most times, they help someone working the same project at a later time. So many activities in the Army are repetitive, that you are guaranteed to participate in multiple iterations. As a leader, once one of my direct reports mastered an actvity, I would move on to someone else, using the "masters" as coaches for the less experienced.
3- you can learn about things you would miss, especially when working abroad. Part of our traininig in preparation for combat missions would consist of learning the challenges our predecessors faced when entering the area of operations. Saving Changes...
Greg FabianRetired IT Project/Program Manager and Technology Strategist| RetiredFairfax Station, Va, United States
I think the example you give of lessons learned - like setting up a web server or installing a software product - can be covered by a web site like Stack Overflow. However, for more complex projects (like an enterprise software acquisition project), Stack Overflow isn't going to help.
Most of the lessons learned documentation I've seen regarding more complex projects were of no, if any, help in planning a new project or managing an in-flight project. That's because it takes a certain amount of organizational honesty to really home in on what the issues were, how they were overcome, and the strategy to avoid or mitigate the issue for future projects. A lot of organizations have a low tolerance for self-examination despite what they say. If you're not sure where your organization stands, a project lessons learned effort will be give a good indication of organizational honesty. Saving Changes...
Ravi Kishan PaliwalProject Manager - UKI| IBM India Pvt LtdNew Delhi, Delhi, India
Yes, lesson learn helps a lot it will avoid other colleagues avoiding mistake which you have faced in the project. Saving Changes...
