"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...
IMO there are two purposes of documenting lessons learned (I'm not an IT guy so please bear with me):
1) It brings in a great amount of discipline while conducting a project; you face certain issues, you figure out a way to counter them and you document those in a standardized document. That brings in rigor and discipline and helps the project team reflect on their actions
2) I don't believe the point of lessons learned is to have answers to specific questions. For instance, while building a macro I came across error XYZ and corrected the code to counter that error- I wouldn't document that as a lesson learned- that would probably be appropriate for a trouble shooting guide, similar to sites like Stack Overflow. But what if you are facing issues negotiating with a vendor; or you need additional funding on for your project and are not quite sure how to bring that up with the sponsor; or one member of your project team has left the company and you desperately need to adjust resources without impacting cost & schedule- wouldn't it be helpful to learn how others have handled similar issues in the past? That is the point of lessons learned- so you don't have to reinvent the wheel
Totally agree a good lessons learned process should be about recognizing good and bad experiences of a project and sharing those forward with future projects. Having had both Corporate best practice and operational director roles before embarking on my current career I can tell you there is nothing more galling for everyone involved than seeing multiple projects falling into the same trap and then saying they hadn't known there was a trap there.
Let me draw an analogy when you drive to work you alter your route over time, optimize it to avoid tailbacks, speed traps and other things which you don't like. When your Neighbor gets a job close to your office if you don't share a car you would certainly point out to them the best route...this is lessons learned.
As an IT person, I hear you John. I had gone through this before and I know it's so frustrating. I think regardless of the method of information sharing on lessons-learned, it must be done in order to assist future and existing projects. Saving Changes...
I think you are slightly mis-interpreting the value of a lessons learned document. The documentation system you are describing is really a copy of Microsoft TechNet, which is not needed until there is an error.
If you really did have a lessons learned document for each project (building a web site) or (building a web server), they would describe in general terms what processes worked and what processes didn't. You would now have a compilation of data that suggests a solution to improve the outcomes of those processes.
For instance, you could run into troubles in any number of ways:
- adding IIS services into an existing server
- building a new server and turning on IIS services before fully patching
- linking web sites to backend database services (SQL, Oracle, MySql, Hadoop)
- adding multiple web sites to a single IIS server (or cluster, or HyperV)
If there were instances where the problems were minimal, you might start to offer your clients those types of configurations at a discount -
If there are instances where there is a new problem every time you deploy a site, and the problem is new every time, you need to add time into your quote for services to take care of the extra time.
Lessons learned is not about solving the individual problems, it is about learning how to do the processes better, especially in situations where there can be lots of problems. Saving Changes...
The value of lessons leaned is to document what went wrong and what worked. The goal is to not repeat past mistakes on your future projects. Address the areas that you encountered difficulties and go forward with a new approach. Saving Changes...
Lessons Learned may be beneficial for the individual, but mostly are for the organization. IBM project management was maintaining a knowledge database, used by 40K PMs globally and an excellent resource to find any kind of PM deliverables: processes, templates, how to, estimation guidelines, risk sources etc. Making tacit knowledge available to the group.