Best Practices/Lessons Learned Formats

[JakeAdkins]

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

 

[MadMango]

Things of this nature are industry/company/product specific. I believe anything you receive will have to be modified so heavily, you are probably better off creating something on your own. You have already identified major areas, and the information you want to capture. I have seen these created in Excel, Word and several others formats. I would pick something you are comfortable working in and develop your own.

"Art without engineering is dreaming; Engineering without art is calculating."

Have you read faq731-376 to make the best use of these Forums?

 

[DesignerGuy16]

Best is to just brainstorm. We're doing the same thing currently.

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

 

[KENAT]

Lessons Learned- The problem I've found is management rarely want to look at what went wrong on a project they just want a quick fix and 'move forward'. No point crying over spilt milk etc.

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...

 

[JakeAdkins]

Thanks KENAT. I guess I have been blessed with management that has more perspective that some of what you have dealt with. My supervisors are supportive of this effort.


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.

 

[GregLocock]

You seem to have two separate problems

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

SIGlease see FAQ731-376 for tips on how to make the best use of Eng-Tips.

 

[BrianPetersen]

Back when I had something to do with this, which admittedly is years ago, we just made an excel spreadsheet with major columns like "Issue", "Solution", "Recommendation for next time". You can flesh this thing out with who's responsible, target dates, drawing numbers, etc to your heart's content. During commissioning, it was the project manager's responsibility to maintain this document, and if there was ever a repeat or similar job, it was their responsibility to go through these documents from the previous job and shepherd any necessary design changes through.

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.

 

[FreddyNurk]

An interesting and entirely worthwhile venture, that is often either not supported as Kenat stated, or often (in my somewhat limited experience) buried in the previous projects and forgotten about until the mistake is repeated, then the documentation gets dragged out.

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.

 

[stick1]

There is a free Word 2003 "lessons learned" template offered by Microsoft at:

http://office.microsoft.com/en-us/templates/TC011417221033.aspx

Sometimes when I am starting from scratch on a document, I look for an equivalent primer in order to get the thinking process started.

 

[carnage1]

The two databases I have worked with like this were both at electronic manufacturers. one used SAP and the other used a custom built Microsoft front office application.
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

 

[MadMango]

For best practices, don't forget to talk with the people on the assembly line. Many have great ideas, but never bother to share them because no one has ever bothered to ask 'em.

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 to make the best use of these Forums?

 

[bvanhiel]

The House of Quality (part of the QFD process) is one tool you might look at for capturing this kind of data. It's a cross functional tool that requires input from sales and marketing through engineering, production and quality. Might be overkill, but leaving out marketing and production when making product changes is usally a disaster.

-b

 

[JakeAdkins]

Thanks for your input everyone.

 

[plasgears]

At GE jet engines we had a publication that listed many of the historic design flaws and how they were fixed. The format was:

- 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.

 

[Kinsrow]

DFMEA would be one method. This tool along with feedback from QC and production manufacturing would provide a closed loop iteration.