Stan: This month we conclude the thread we started in March – sharing the experience gained over the 38-year career of Lewis Gordon, a principal control systems engineer retired from Invensys. Last month we focused on how the profession is changing in terms of management and goals. This month we wrap up with an exploration of the challenges of capturing and transferring the knowledge and skills of retiring engineers, operators, and technicians.
Greg: A very large proportion of the knowledge and skill accumulated over entire careers will be walking out the door over the next decade. What can we do make sure this knowledge is not lost?
Lew: Firstly, management must recognize full the impact of this loss. For current projects, changes in technology make it impossible to maintain performance by simply copying what has been done before. Fundamental design concepts must be implemented in new environments, and new technologies must be integrated with existing systems to maintain and continuously improve control performance. This requires knowledge – mindlessly copying designs is not adequate to the task.
Stan: Best engineering and configuration practices are immediately essential, along with properly documented designs and operating procedures. The ability of today's control software to document itself must be fully utilized.
Lew: Longer term, management needs to set goals for constantly improving and expanding the technical capital of their staff. This means implementing best practices in capturing and transferring the knowledge and skills held by experienced staff.
But this activity is time consuming, difficult, and expensive. Nobody makes an immediate profit from knowledge capture and transfer. As has been the case for waste treatment and safety, it won't happen unless it is supported by management and incentivized by financial and performance metrics. Companies need to take the long term view that knowledge retention and growth is an essential part of company growth.
Stan: This brings us to the bigger question. Given the motivation and need, how do we make sure knowledge is growing?
Lew: The fundamental issues are these: How and when should knowledge be captured? How and when should it be transferred? Most fundamentally, what knowledge should be captured? How should captured knowledge be made retrievable and useable?
Capturing individual knowledge can be problematic because many engineers and technicians, often the ones with greatest depth of technical knowledge, may not be good communicators.
Greg: I know people with extensive expertise and achievements who are too nervous to standup before a group to give a talk. Many can't get started writing the first sentence for a publication. For these people, more informal settings such as panel discussions and casual workshops allow them to open up and express themselves. I have successfully used an informal conversation rather than a traditional interview to capture and publish the expertise of over fifty experts in my Control Talk Column since 2002. I simply let the conversation take us where it needs to go. Not much is preplanned except some possible topics. The whole experience is a trip with many sites along the way. Part of what makes the talk flow so freely is the understanding shared.
As engineers we can get obsessed with details and perfection. The writing process involves concepts and imperfection. The final product must capture attention and convey the essence of the importance and relevance of the knowledge. The process is iterative by nature, with lots of editing by the writer, reviewers, and copy editors. Technical people need to write and present papers not only to support this knowledge being re-used but also to improve their marketability and establish their brand. 'Tip #60: Write and Present Papers" posted April 19, 2013 on the ISA Interchange site discusses how I got started and the motivation for others to do the same. At the minimum, engineers should keep a detailed list, and preferably copies, of their reports, publications and presentations. Who will listen to practitioners who have not taken the time or sharpened their ability to document what they have learned and accomplished?
Lew: There is also a need for a knowledge engineer who understands how to ask the right questions, develop a conversation, and make the content accessible and retrievable. This is more than a conventional technical writer.
Information captured by the knowledge engineer must be generalized. Extraneous details associated with a specific project must be flushed out as part of the capture process. If it has to be done by the new user, it simply won't happen – there isn't time. Besides having communication ability, a knowledge engineer must also understand the relevant fundamentals and principles that will make or break an application. We are all subject to information overload. We need to be able to see the forest despite the trees, and vice versa.
This screening must be done by the person putting the knowledge into an online library. The information must retrievable - organized so that people can find what they need when they need it. In the beginning of a project, project engineers need to recognize the improvements and possible benefits to be gained from previously captured information. This information can be organized by industry, process application, and/or performance objective, such as minimizing specific energy or raw material consumption, or maximizing production rate or optimizing product quality).
Stan: Online search tools should also allow a user to find solutions for common difficulties such as disturbances, interactions, recycle streams and resonance. There is an incredible body of knowledge out there in terms of article, books, columns, papers, and presentations but some may not turn up on in internet search. Presentations may not retrievable unless you go to a Technical Society's or Supplier's website. Publications before 2002 typically require you to know the exact title, publisher and in some cases the date. How do you ensure the latest knowledge gained is part of this system?
Lew: Timely knowledge capture needs to be part of the defined and funded project scope. When such an effort is tacked on the end of a project, as an unfunded afterthought, it simply won't happen. Project managers need to move their resources on to the next project. Customers want to keep their project under budget and on time, since these are the typical for judging their project performance. Too often, there are no metrics and few personal goals for knowledge capture and transfer.
In general, you shouldn't wait till expertise is walking out the door to begin capturing it. But even if many have left, there is still an opportunity to recover what they know. Most retirees feel a loyalty to their company and don't want to be forgotten. These veterans want to feel needed and useful, and don't want their many years of hard won expertise lost. The cost of setting up a team to manage their participation in a program to capture and transfer their knowledge would be minimal. The money paid need be just enough to make the effort real. The best results would be gained by a knowledge engineer working with a retiree in short, multiple sessions. The result can be invaluable to many younger engineers, and a long lasting benefit to your company.
Greg: I started an ISA Mentor program in 2011 with Hunter Vegas. We began with about 10 automation engineers. The only requirement was that the participants were users with at least 2 years of plant experience and would commit to presenting a paper or being a panelist at an ISA conference. The participation was enthusiastic and there was an instant synergy at ISA Automation Week 2011. The program triggered a long series of questions and answers (Q&A) posted in 2011 and 2012 on my ISA Interchange site. This year the Q&A is posted on the Emerson Exchange 365 Mentoring Discussion site to provide a more interactive experience online. The Q&A posts are generic enough to benefit a wide audience and not reveal what might be considered company confidential information. The Q&A was beneficial to the mentors as well. The mentors had to step back and clearly understand the starting point of knowledge needed for various tasks and innovation.
The program led to the ISA book in 2013 coauthored with Hunter Vegas titled 101 Tips for a Successful Automation Career. The book provides a unique way of improving personal and technical skills of general benefit. Each tip is limited to 2 pages and starts with an introduction to provide a background and orientation followed by brief “Concept”, “Details”, “Watch-Outs”, “Exceptions”, “Rule-of-Thumb”, and “Insight” sections to provide comprehensive yet concise of essential knowledge and guidance.
The InTech January/February 2013 article "Enabling New Automation Engineers" and the Control September 2013 article “Process Automation Generations Talk to Each Other” coauthored with key participants and Hunter Vegas provide a view of the type of communication and knowledge needed between different generations.
Tight travel budgets and project work overload has reduced the level of participation in the ISA Mentor program. The online meetings and online discussions between the new engineers did not develop as hoped. Some solutions have fallen by the wayside since the mentors are in different companies and not available for being onsite to provide timely assistance as conditions change and implementation requirements develop. Even the best ideas can fail due to slight misinterpretations, missing details, or unforeseen conditions. A better organization would have included the addition of mentors within the company to work directly with the new engineers. The role of timely part time mentoring could be fulfilled by retirees who were practitioners either as a user or supplier of engineering services with a basic knowledge of the capability of today's automation systems.
Stan: In the September, October, and November 2009 Control Talk Columns "Going, Going, Gone - Part 1", “Going, Going, Gone - Part 2” and “Going, Going, Gone - Part 3” we extensively discussed the dramatic changes at the company we retired from and found out from Nick Sands, Vice President of ISA Professional Development, what a leading company is doing to deal with the loss of expertise.
Greg: To help show the value of process control engineer lives on, we came up with “Top 10 Things Retired Process Control Engineers Can Do”.
"Top 10 Things Retired Process Control Engineers Can Do"
10. Optimize the pH and chlorine in your pool.
9. Remotely control your pool and home temperature.
8. Stream big moments in automation history on roof top big screen.
7. Be the engineer for model trains that carry snacks to guests.
6. Develop neural networks to increase intelligence of in-laws.
5. Use data analytics to provide best answers to spouse's questions.
4. Teach process control to grandchildren.
3. Teach pressure control to politicians.
2. Teach lake level control to agencies.
1. Use Model Predictive Control (MPC) to address BBQ and beer interactions.