FEA for Managers & Reviewers - Q & A

by Tony Abbey, FE Training

This week I presented a very short free webinar to a mainly US based audience on the topic ‘FEA for Managers and Reviewers’. This was a collaborative effort between NAFEMS and Desktop Engineering (DE). DE is a US based magazine focussing on CAD, CAM and CAE and I write a monthly article for them. The webinar was based on the March 2013 article of the same name.We had a big audience and the webinar prompted a lot of questions. Mulling this over with the NAFEMS editorial staff we thought that this would be an ideal discussion to bring to NAFEMS members. So we have decided to post a link to the webinar. We will also follow up with the questions via this blog. Please feel free to join in!

I have added a sample question and my answer in the text here, but we will put the other questions and answers in the ‘comments’ section so that you can add your own comments and observations.

Q: Any good tips for the managers on how to evaluate the FEA team skills while the manager himself may not be an expert in FEA fields?

A: That is a tough task; a balance between trying to absorb what your time and abilities allow but achieving an effective level of supervision and review.You will need an initial briefing on what FEA is all about. Resources include a NAFEMS training course (of course!), a series of interviews with an FEA expert from outside your team and a non-technical introductory textbook.

Then set up a series of peer review sessions where each member of your team presents a summary of an analysis they have done. The brief should be to cover what the analysis objectives were, the thinking behind the methodology used, details of the method, the results and conclusions and how these were validated. The rest of the team should be encouraged to discuss the analysis openly with comments and suggestions. They should also know you will be asking for layman’s explanations of some of the topics. Explain that this has a twofold purpose – to allow the team to share experiences and for you to absorb some of the ideas behind analysis planning, methodology and validation.

Your manager skills will be needed to keep everyone on track and to gauge when to halt deep dives into theories and methods which are clearly beyond your abilities. Explaining complex ideas in a simple way is a good attribute for any member of your team to have, so encourage this.You will also be able to assess the confidence each engineer has in their own analysis and how the team views each analysis.

Your objective should be to educate yourself in this way so that you can play a role in asking critical questions about analyses projects. With experience this fresh ‘external’ pair of eyes can be very valuable to the team, perhaps finding issues that the team overlooks. I often used to talk through analysis projects with my Father, who was not an engineer, but was very good at bringing ideas back to basics and identifying flaws in methodology. Another path is to use an accreditation route, such as the soon to be re-launched NAFEMS Registered Analyst scheme. This will be a formal rating of the skill level and experience of each engineer.

Then set up a series of peer review sessions where each member of your team presents a summary of an analysis they have done. The brief should be to cover what the analysis objectives were, the thinking behind the methodology used, details of the method, the results and conclusions and how these were validated. The rest of the team should be encouraged to discuss the analysis openly with comments and suggestions. They should also know you will be asking for layman’s explanations of some of the topics. Explain that this has a twofold purpose – to allow the team to share experiences and for you to absorb some of the ideas behind analysis planning, methodology and validation.

Your manager skills will be needed to keep everyone on track and to gauge when to halt deep dives into theories and methods which are clearly beyond your abilities. Explaining complex ideas in a simple way is a good attribute for any member of your team to have, so encourage this.You will also be able to assess the confidence each engineer has in their own analysis and how the team views each analysis.

Your objective should be to educate yourself in this way so that you can play a role in asking critical questions about analyses projects. With experience this fresh ‘external’ pair of eyes can be very valuable to the team, perhaps finding issues that the team overlooks. I often used to talk through analysis projects with my Father, who was not an engineer, but was very good at bringing ideas back to basics and identifying flaws in methodology. Another path is to use an accreditation route, such as the soon to be re-launched NAFEMS Registered Analyst scheme. This will be a formal rating of the skill level and experience of each engineer.

Then set up a series of peer review sessions where each member of your team presents a summary of an analysis they have done. The brief should be to cover what the analysis objectives were, the thinking behind the methodology used, details of the method, the results and conclusions and how these were validated. The rest of the team should be encouraged to discuss the analysis openly with comments and suggestions. They should also know you will be asking for layman’s explanations of some of the topics. Explain that this has a twofold purpose – to allow the team to share experiences and for you to absorb some of the ideas behind analysis planning, methodology and validation.

Your manager skills will be needed to keep everyone on track and to gauge when to halt deep dives into theories and methods which are clearly beyond your abilities. Explaining complex ideas in a simple way is a good attribute for any member of your team to have, so encourage this.You will also be able to assess the confidence each engineer has in their own analysis and how the team views each analysis.

Your objective should be to educate yourself in this way so that you can play a role in asking critical questions about analyses projects. With experience this fresh ‘external’ pair of eyes can be very valuable to the team, perhaps finding issues that the team overlooks. I often used to talk through analysis projects with my Father, who was not an engineer, but was very good at bringing ideas back to basics and identifying flaws in methodology. Another path is to use an accreditation route, such as the soon to be re-launched NAFEMS Registered Analyst scheme. This will be a formal rating of the skill level and experience of each engineer.

Then set up a series of peer review sessions where each member of your team presents a summary of an analysis they have done. The brief should be to cover what the analysis objectives were, the thinking behind the methodology used, details of the method, the results and conclusions and how these were validated. The rest of the team should be encouraged to discuss the analysis openly with comments and suggestions. They should also know you will be asking for layman’s explanations of some of the topics. Explain that this has a twofold purpose – to allow the team to share experiences and for you to absorb some of the ideas behind analysis planning, methodology and validation.

Until next time,
Regards,
Tony

View all blog posts