"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...
You're certainly right about problems that are more cerebral and have multiple possible or hidden solutions. A lessons learned document would be helpful in that sort of situation. Saving Changes...
Denathayalan RamasamyChief Technology Officer| Atal Incubation Centre -CIICChennai, Tamilnadu, India
Templates are used most of the times. Only 10-20% PMs are really looking into it and extract the most useful information irrespective of documents maturity. Others just blame those documents were not useful to cover their inefficiency Saving Changes...
I'm coming at this from a quality & ISO 9001 audit angle, I'm not an IT person but I hope this perspective helps:
If your company is ISO certified, you *have* to document corrective actions. Companies are expected to review their performance data and then implement improvements. Plan-Do-Check-Act.
As the process matures through the lessons learned cycle, issues should settle over time. If the issues you face only happen once, and you fix them, great. I'd look out to see if there's a trend of that issue recurring, and whether corrective or preventative actions were performed or not. Did someone check those actions were effective or not, if not, what did they try? Even reducing the frequency of the issue is ok, if you can't eliminate the issue completely. To loop this back into Agile/PMP, you would take that lesson learned, and update your risk register or issue log.
Long-term, I would be asking management about capturing institutional knowledge. If you were to resign today, can a new person look at your process/project documentation and do what you did. Saving Changes...
