"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...
Nicholas TufaroCEO| Tufaro Information SystemsHudson, Fl, United States
Way back when, my colleagues and I created this acronym...WORN... as in WORN Technology. It was created in a tongue in cheek response to WORM Technology. WORM stands for Write Once, Read Many. While WORN stands for Write Once, Read Never.
Unfortunately, this may be the situation with Lessons Learned, that it is WORN Technology. Perhaps there needs to be a standard set on the summary statement of a specific lesson learned. Do we write it in the active voice or the passive voice? For example, do we write “EXCEL Add-In for Exporting to HP ALM Doesn’t Work” or do we write “HP ALM Import using EXCEL Add-In doesn’t work”? Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
PMBoK ed6 introduces a new key process and puts much more emphasis on handling knowledge, not only at the end of the project but ongoing. One leadership competency is continuous learning, this includes digesting lessons learned, books, conferences, trainings, networks, war stories etc. The best project managers contribute to this from the feeding side and they adapt their style if nobody listens. Saving Changes...
Lessons learned may be time consuming, but they are valuable organizational process asset for current and future projects. The key is to document the lessons learned throughout the project in a succinct and gradual manner with optimal information, instead of cramming all or majority of details at the project conclusion. Saving Changes...
Loay MohamedSenior Program Manager - PMO| GovernmentRiyadh, Saudi Arabia
Great Points. Indeed Lessons Learned are very valuable, also it depend on how you manage your documentation system so you can easily track and get the learned lessons based on project type sometime by discipline. Saving Changes...
In my opinion, what you get out of Lessons Learned is driven by what you put into it.
In many orgs I've worked in, it's often given lip service only. It's part of a process, most don't believe in it, there's no emphasis on doing more than dotting an "i". If that's the approach your org takes (took), then you're right, it'll go badly.
On the other side of the spectrum, if the org really emphasizes lessons learned, provides training to all on how to do them effectively, stores lessons in an easily accessible and searchable location, emphasizes referencing them at the start of every project, pushes for the lessons to improve current processes, etc, etc, etc, then you're wrong, it'll go great. For the org, at least.
Lessons Learned is just a tool - one that can be used poorly or well. To some degree, you get to choose how well you use it, regardless of how the org does.
The best outcome of lessons learned is a mindset hell bent on doing better..
Good luck. Saving Changes...
Ravi DubeyVice President Engineering| Truminds Software SystemsNew Delhi, Delhi, India
Absolutely. They are very useful, but like other documents and initiatives, they would be useful for future projects, IF and ONLY if, there is considerable focus and drive to go through these with a great sense of conviction and trust that "All of us don't need to commit the same mistakes to learn the same things".
Likewise for AGILE principles projects (and now SAFe), which may be spread across multiple releases / PI, it is imperative to have a Lessons Learnt (something like what we do in the RETRO). This would be helpful for new joinees in teams as well as Ready reckoners for other teams who are associated in whatever form Saving Changes...
Even the good and well-designed systems may be implemented incorrectly. This has nothing to do with the concept of Knowledge Management and/or documenting Lessons Learned. What we generally accept as science is an outcome of systematic documentation of "lessons learned". Saving Changes...
I also think lessons learnt documents will probably never be read after the project. However, the lessons learnt session and creating the document has already a value on its own: participants will rethink the project and will learn from sharing the insights. Summarizing the lessons learnt session was always helping myself to reflect my PM skills, too. So, the organisation will gain value from each person's learning. Saving Changes...
Pamela ZinkDirector, Program Management Office Health Care| Atos IT Services & Solutions, Inc.Cincinnati, Oh, United States
Lessons learned individual documents are important to the team. The sooner you start the process within the project, the better. It should be a WIP throughout the life cycle so it's not an "event" at the end.
Lastly, unless lessons learned are aggregated into a database to provide horizontal views across your programs then their power will never be fully recognized or helpful. No one has time to drill down and read everything.
