Process Improvement
|
Please login or join to subscribe to this thread
|
||||||
|
||||||
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 cheers /sd 
Network:0
Good points.
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. I think my company might be trying to make a lessons learned document where they should be making more of a troubleshooting guide. Thank you for the distinction.
Great Points. Indeed Lessons Learned are very valuable.
sd,
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. Malc
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.
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.
@Sromon Das,
Well stated! 
Network:2386
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.
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.
See some more thoughts here: https://www.linkedin.com/pulse/lessons-lea...nta-pmi-fellow/
Learning lesson document information collected has what went good as well as what went wrong; so it will also help upcoming projects to consider the issues/risks before they occur.
|
||||||
Please login or join to reply
ADVERTISEMENTS
|
"Golf is a good walk spoiled." - Mark Twain |
