"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...
Brandon MulnixInsights Project Manager| Byrne ElectricalSaranac, Mi, United States
There is a lot of great replies. In my opinion, Lessons learned are a great source of finding gaps in an organizations processes. By having a Lessons Learned document if should give you justification to discuss with stakeholders the gaps and help develop a solution. Similar with the change log, if similar changes are identified on different projects. Saving Changes...
Stelian ROMANProject Manager| MicroSafetyCarlingford, New South Wales, Australia
It depends on the organisation and on the people. The document itself is designed to be valuable.
I see more value in retrospectives after each sprint or time interval where the issues are discussed with the team and if actions taken.
With the constant change in environment the lessons learned process is not as relevant as it used to be. Issues related to technology may be irrelevant by the time the project is completed. Saving Changes...
NITIN MITTALSr. Project Manager - Professional Services| USADenver, Co, United States
Lesson learned documents always help you to understand trends , failures and success of what team did. And it is good tool to make new action plans which are more productive , more predictable and less riskier. Saving Changes...
Mark GrayPM Consultant, Coach, Trainer and more| Self EmployedParis, France
I forgot to add - #L2BL is well established in some companies - and although I agree that the changing landscape can make the "news" into "olds" very quickly we still need this "knowledge capitalisation"
However, if you still doubt the value of the exercise, take a look at llis.nasa.gov - they really leverage their learnings through sharing of information, using an extensive database, knowledge management teams, etc. Saving Changes...
We are fairly good a documenting "lessons learned", but we are very poor at "implementing lessons" which is the whole point of documenting lessons learned. Lessons learned are just observations if not implemented. Going back to the original question, and as others have stated, documenting lessons learned does not necessarily have to get into the "weeds" of specific code or other fault issues, but address them more holistically. What caused them, what was done, and what can be gained by implementing them for the organization as a whole. Saving Changes...
RAJESH K LProject Manager, PMP| Bharat Electronics, Bengaluru, IndiaBengaluru, Karnataka, India
Lessons learnt document are invaluable to the organisation. Following to be ensured for it to be useful
a. it should be documented in standard template
b. to be reviewed and finalised before putting in repository
c. to be readily available for authorised members of the organisation Saving Changes...
Lessons learned are valuable ONLY if you share them with other teams in your organization and there's a culture where people check them as part of project startup as part of organizational knowledge.
If they're just something that's done and never ever referred to or referenced again, it's a waste of time Saving Changes...
lessons learned is a tool PMs can and should use often along the project life cycle, not only at end.
It helps identifying and debates with the teams ativities, tasks, actions that didn't occurred as expected.
Along the implementation stage its common to observe misundertandings due to various reasons. Teams should discussed what went wrong and avoid to repeat it. This act is well established in "agile" projects adopting scrum methodology, dails scrums, sprint retrospectives imply regular analysis about what the team did well, and won't did so well.
On my projects i track every day, lessons learned, some i discuss with the team, others not (stay with me, for personal reference). Saving Changes...
I’m a project manager that almost dedicates full time to projects related to food and beverage. In my path dealing with the company’s work, I noticed that when you document the project from beginning to end , it’s easier to go back and tell the sponsors in what areas we failed and need to improve , and where we get success at the end of the project.
This was a complete new area of the company I work for. All the projects were executed and finished without taking even notes about it and when I was new on my work I was getting a hard time to understand what happen before me.
Now I can say that everyone who ask about a project will have the right information on time. And even if I quit or change of job, there will be a database that the next PM will say thank you. Saving Changes...
