Best Practices/Lessons Learned Formats
Best Practices/Lessons Learned Formats
(OP)
The company I work for does not currently have a 'design best practices' or 'lessons learned' list or document.
We have a product that we have designed and built and are selling. It's for the most part a good product but it does have some issues. I did not design the first product but I am designing the next generation. Through the design process I found that we do not a have a list or method of capturing all the issues we had with the previous generations and the causes of those issues.
Does anyone have a format that they would like to share? I don't want to have a series of articles or a blog. I want something easy to use and understand.
I am thinking of something that breaks the machine up into basic functions. Drive, Controls, Structure etc... Tells the problem, the cause, maybe includes a diagram if required and a section for notes on the problem, best solution something like that.
This will be an internal document to capture the company's knowledge.
Thanks
We have a product that we have designed and built and are selling. It's for the most part a good product but it does have some issues. I did not design the first product but I am designing the next generation. Through the design process I found that we do not a have a list or method of capturing all the issues we had with the previous generations and the causes of those issues.
Does anyone have a format that they would like to share? I don't want to have a series of articles or a blog. I want something easy to use and understand.
I am thinking of something that breaks the machine up into basic functions. Drive, Controls, Structure etc... Tells the problem, the cause, maybe includes a diagram if required and a section for notes on the problem, best solution something like that.
This will be an internal document to capture the company's knowledge.
Thanks





RE: Best Practices/Lessons Learned Formats
"Art without engineering is dreaming; Engineering without art is calculating."
Have you read FAQ731-376: Eng-Tips.com Forum Policies to make the best use of these Forums?
RE: Best Practices/Lessons Learned Formats
Need some input from sales as to what the customers would like over and above current machine functionality, and service history to know what the real trouble areas are.
Other than that just keep talking about it and you'll come up with a better way.
James Spisich
Design Engineer, CSWP
RE: Best Practices/Lessons Learned Formats
Suggesting you analyze how the project went, to identify what worked, what didn't, what went well, what could be improved for next time etc is perceived as 'navel gazing' or looking backward rather than looking forward.
Of course if we don't learn from our mistakes we're bound to repeat them, and if we don't learn from our successes we may not repeat those.
So no I don't have a document sorry but would suggest looking at not just technical aspects but project management aspects etc. as well.
KENAT, probably the least qualified checker you'll ever meet...
RE: Best Practices/Lessons Learned Formats
I do realize that these types of things are very specific but I was hoping that someone would have something that could offer some inspiration. Maybe have a little 'knowledge capture' we could all benefit from.
RE: Best Practices/Lessons Learned Formats
a) record keeping - well that is so banal I can't even begin to sum up any enthusaism for helping you. I suggest a database might be a good format but 9 out of 10 users who epxressed a preference ended up with excel cos that's what engineers use. I quite like a rolodex myself.
b) generating a list of problems and how they were solved, and likely problems your new design will face. That's Systems Engineering. Keywords would be partitioning, subsystem requirements,fishbone diagram, interface diagram, FMEA, and so on, and so on.
For a reasonably small project your problem is more of knowledge capture than in a big project, where there is far too much data and no way of finding it and organising it.
So I wouldn't fuss overmuch about a formal method of storing it, anything will do.
Cheers
Greg Locock
SIG:Please see FAQ731-376: Eng-Tips.com Forum Policies for tips on how to make the best use of Eng-Tips.
RE: Best Practices/Lessons Learned Formats
The headache that we struggled with, was "as-built" drawings. A part would be designed a certain way, then inevitable errors crept in during manufacturing, then the drawing would get revised to reflect the "fix", but now it essentially contains the manufacturing error, dooming oneself to repeat it unless something special were done. Given that we were using CAD, I would copy all the drawing outside the title block (i.e. keeping the original design intent) and then do the as-built changes inside the title block. If there was a "next time", I could copy the file, erase the as-built, and start fresh with the original drawing ... and this time do something to hopefully stop the manufacturing error from happening again. It was almost impossible to get anyone else to grasp this concept, though.
RE: Best Practices/Lessons Learned Formats
There are many different ways of storing the information, and indeed what is the most suitable means is probably an issues database, with appropriate search functionality. A Wiki, if the company has an internal web page can often be effective, as everyone has access to it.
But by far the biggest issue is not only how to store the information, but also to ensure that all employees are able to both be aware of the documentation, and to be able to access it.
Storing it in a project is a sure fire way of ensuring that the information will be lost and forgotten about.
As an aside, I pushed for a review of what went well and what didn't after completing an upgrade of a 2MW off grid power station, particularly as we were quite successful in some respects and very poor in others. Management thought it was a fantastic idea, though I struggled to get the results of the meetings to be stored. However, after this, management went and did exactly what they did on the above mentioned project on the next one, so you may need to be creative to counter this.
RE: Best Practices/Lessons Learned Formats
htt
Sometimes when I am starting from scratch on a document, I look for an equivalent primer in order to get the thinking process started.
RE: Best Practices/Lessons Learned Formats
The important pieces that were actually usable data were serial number, exactly which component had to be replaced, and weather replacing the part fixed it. A symptom description and notes section were useful but only after some serious digging. You might see if the EE forum can offer more info as their industry does this standard.
Luck is a difficult thing to verify and therefore should be tested often. - Me
RE: Best Practices/Lessons Learned Formats
The Lessons Learned form that Stick1 linked looks pretty good. I would transfer the form into Excel, at least then it would be able to be searched.
"Art without engineering is dreaming; Engineering without art is calculating."
Have you read FAQ731-376: Eng-Tips.com Forum Policies to make the best use of these Forums?
RE: Best Practices/Lessons Learned Formats
-b
RE: Best Practices/Lessons Learned Formats
RE: Best Practices/Lessons Learned Formats
- Intro/application
- illustration original
- service history
- illustration new
- why new design better
- service history if available.
Insightful companies could benefit from working on this as time allows. It makes good reading for the newbies.
RE: Best Practices/Lessons Learned Formats