"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...
Lessons Learned are not only about mistakes you made or solutions you found to different problems. But it is also about good practices you followed which worked. Moreover, lessons learned are not for you only, it's for the organization. Let's assume I join your organization and I don't have any experience in setting up a website on IIS, now if you or some other experienced person have had those lessons learned documented, I will first go through them before I even start. And that's where the benefits of lessons learned come in to play. Saving Changes...
Anton OosthuizenSenior Business Analyst / Project Manager| Self EmployedPretoria, Gauteng, South Africa
Lessons learned is important but my take on it is that any lesson learned should be implemented immediately as it is documented, and not only in your current project but also in the generic process that means it will be applied to all projects that follow by default i.e. you should not have to consult lessons learned documentation to ensure that the same mistakes are not made again. This sounds like common sense but believe me I've worked in an environment where people never had time to fix the problem now, we'll document it and come back to it. Guess what? Saving Changes...
It is very valuable and makes our life easier Saving Changes...
Sanjeev NawaniGlobal Digital Services Leader for all Portfolio Companies | Public Investment Fund, RiyadhPune, Maharastra, India
Good Discussion...
Now it depends on organizations project management methodology , what importance they provide to 'lesson learnt '. In my viewpoint, after completion of each project stage this step is important , this helps to motivate teams members from employee engagement view point and from risk management from organization sustainability viewpoint...
Both are important but depends on process / organization maturity how they balance it ...
Thanks, Saving Changes...
NITIN MITTALSr. Project Manager - Professional Services| USADenver, Co, United States
Some times not valuable much. Lessons learned attributes are earned from certain market conditions, business conditions and environment, which keep on changing pretty fast due to global and local impacts. It should be considered as reference for better results. Saving Changes...
ABHIJEET GANGULYPM Consultant| SAP India Pvt LtdBangalore, Karnataka, India
Documenting Lessons learned is a good practice to look back at the problems faced during project life cycle. Although practically almost 80% of the time, problems faced in a project are a bit different any other project. But that doesn't undermine the importance of documenting the same. Saving Changes...
RAJESH K LProject Manager, PMP| Bharat Electronics, Bengaluru, IndiaBengaluru, Karnataka, India
Lessons learnt document should be maintained and it should be made available to all concerned on need basis Saving Changes...
The biggest problem with Lessons Learned documents is no one reads them. Saving Changes...
Pier Luigi CalabriaProject Manager| INFORM Institut für Operations Research und Management GmbH, Aachen, GermanyAachen, Germany
Lessons Learned docs are valuable.
The issue is to find them once they are stored somewhere in a database, there should be a tagging or search engine that should help the potential readers to get the right cases to read. Saving Changes...
