More tech, more tech, more better tech!

By Harry Thanos

THE WELL KNOWN problems with sensor and control loop performance are not related to how suppliers define accuracy, nor will they be solved by government regulation. In my experience of many years in the engineering and construction business, the problem lies with the evolution of the project delivery process in the United States over the past 40 or so years. It has become the conventional wisdom among owners (whoever controls the money controls everything) to rush the project work in order that we achieve the so-called on time and on budget performance.

According to this wisdom, performance at completion is compared to initial baseline values. But these baseline values bear no relationship to what is required to properly do the work. And by "properly do the work," I mean the effort-hours needed to correctly answer the thousands of technical and administrative issues that are involved in any engineering/construction work, but do it in a way that is consistent with the financial constraints and goals of the project at hand. Because we measure our performance against meaningless targets, we end up fixing everything in the field, with overall costs and timing higher than if the project delivery sequence was revised to include the proper amount of time for finding the right answer in the shop instead of at the site. Worst of all is the fact that projects fail to achieve their target financial goals, the main reason for which such work is undertaken.

Let me make my theory more concrete. Is it not true that a team of instrument engineers that is being supervised by, say, Greg Shinskey or Greg McMillan or Stan Weiner or Béla Lipták, or many others not so well known, and which team members were given the necessary time to locate the locus of intersection of a correct technical solution with the specific project economics, would have more measured success than today's practices? Is it not true that after a few years of proper work habits, the misapplications of sensors, control schemes, equipment, etc., would tend to decrease and over time become a much smaller problem? To achieve the proper balance between technology and finance is time consuming, because the solution must be tailored to the specifics of each project, but by so doing there exists a much better chance of both avoiding the improper application of hardware/software and hitting the capital return objectives of the owners.

In my judgment, it does not take a genius to solve the technical/financial conundrums of any given project. It does take time. And it does take the use of proper performance indicators. The incorrect use of time in current project execution practice has led us to not allocating enough engineering effort hours, and thus we have slowly, unwittingly and harmfully eliminated the needed supervisory time from project work plans. And, in the process, we not only have created poor designs with bad financial outcomes, but we have also lost the best way for those with knowledge to pass their valuable skills on to others. Meaning that our knowledge base must be slowly eroding and this can’t be good for the economy. There has got to be a better way, so that our engineering and construction work becomes truly value-adding in the sense of helping create true economic profit while at the same time it increases our knowledge base.

So what do I suggest?

FOR PROJECT DELIVERY TEAMS:

1. Allocate more time to think, supervise, question, teach, analyze, research, ask, utilize peer reviews, find out how other industries do it, etc., such that a effective answer has been found that is technically and financially sound. Yes, this will cost more money in the shop -- but there will be big savings in the field and in overall execution time gained. As important, ROIs will improve and management may once more beckon engineers to the top positions instead of thinking of engineering as a necessary evil. Every technologist should never forget that engineering without economics is a meaningless term.
2. To ensure that lessons learned during startup are retained in the knowledge data bank of each organization, it should become standard practice to have the owner/contractor process designers and other team  members lead the startup efforts, and not leave the field until all the design objectives have been met. After startup, a Process Design Considerations Memorandum should be mandatory, including all the lessons learned in the field.
3. The measuring sticks for success must be revised from "On Time and on Budget," to "Our turnover ratio on this project is higher than our competitors," or "Our net margin on this project is better than our competitors," or even "We achieved the expected return we promised to the owner based on the total capital invested," and other similar goals that link our performance to real world results, such as "We made saleable product on the date promised initially" and "We gained the following valuable knowledge that will help us improve our returns on future projects."

FOR CONTROL MAGAZINE: 

1. I think you are doing a very good job educating the reader. You have two places every month where learning can take place. Béla Lipták's column, “Ask the Experts,” and the informative work by McMillan and Weiner in Control Talk. My suggestion is to expand these columns to include even more technical details, with added emphasis on how various technical equipment/instrumentation options can be adapted to differing project economic realities.
2. It might be instructive to start a Lessons Learned column targeted to finding what did not work and why, where readers would be invited to tell in some detail what they learned, anonymously if they so preferred. If printing costs do not permit such page expansion, then perhaps you can do it on the electronic version only.

FOR OWNERS/CONTRACTORS: 

Support existing or initiate new Operational Excellence Forums, where peers could hold videoconference discussions on technical issues, guided/facilitated by knowledgeable teachers. The thrust of such Forums would be "what's best techno-economically for this case?" A summary of the problem and the understandings reached would be available on the web as a Case Study. Case Studies have been valuable teaching tools to train people on how to solve business problems. Over time we would build up a knowledge library, which will be helpful to future learners.

FOR INDIVIDUAL ENGINEERS/TECHNOLOGISTS:

Keep learning, keep asking, keep advancing. Believe that you can add value. There is beauty and pleasure in digging for the truth and the facts, even the mundane ones that we deal with. Teach others.

In summary, we need a new way to design and construct plants. The old way is not working.