The following tip is from the ISA book by Greg McMillan and Hunter Vegas titled 101 Tips for a Successful Automation Career, inspired by the ISA Mentor Program. This is Tip #38, and was written by Hunter.

We have all been there. The sales person stands before the crowd demonstrating a control system. He clicks here and lays down a pump, he clicks there and adds a control valve, he opens this window and everything magically links and is fully functional. The system is a flawless masterpiece. Nothing can go wrong … go wrong … go wrong … Anyone who knows me knows that I cannot stand scripted demonstrations. They are like the references  discussed in Tip #37 – the demonstration will always be flawless. I want to see what happens when I throw the system a curve!

My favorite war story about this particular subject happened in the late 1990s. I was on a team evaluating two brands of expensive simulation software that was to be used for modeling and optimizing our large continuous plants. The plant manager was friendly with one of the salesmen and let it be known which product we were to choose. However, the team quickly realized that the product he had selected was far inferior to the other option. Given the manager’s personality, there was little chance that the team’s opinion would be allowed to override his own. The team arranged for each company to give a presentation of their product. The company favored by the team presented first. The product worked well and was quite adaptable.

The sales person did not follow a script, but asked for ideas from the audience and built a process model before the whole group. The plant manager’s favorite company gave its presentation a few days later. The salesman knew that the previous presentation had gone well so he chose to use a recently released beta version of his product, which had a slick graphics package and lots of bells and whistles. During his demonstration he clearly followed a script … adding a specific column type here, a certain pump there, etc. I let him continue for about a half hour – leading us down a path that had been carefully choreographed to avoid any problems.

Then I raised my hand and asked an innocent question – something about the system’s ability to handle a different configuration. Perhaps the column had a recycle stream coming in one-third of the way down the column or used a different control philosophy than the one he had chosen. “Of course,” he answered, “you would just add those elements to the model.”

“Great,” I responded. “Do you mind showing us?”

He blanched but had no choice. Three mouse clicks later the system sputtered and blue screened. At that point the salesman had to admit that everything he had shown us was a beta version of software that was not fully tested. Needless to say the team selected the other product and the plant manager had no option but to back the team’s decision.

Concept: Like the references in the previous tip, scripted demonstrations are practically worthless. Let them get started and then start asking questions that force the sales person to depart from the script. If the system is good, it will easily handle the diversion and perform well. If the system is designed poorly, it will quickly become clear.

Details: Regardless of the product being demonstrated, most sales people like to follow a well-choreographed, thoroughly tested script. The risk is low and the script has been specifically designed to highlight the strengths and minimize the weaknesses of the particular product. The sales person’s job is to make sure everything goes to plan. However, the audience members WANT to know the product’s weaknesses and flaws. They have a vested interest in forcing that demonstration off its script so that a more complete evaluation is possible. When attending a demonstration, the audience must recognize that the demo is scripted and take pains to force the sales person in a new direction.

Recognizing a scripted pattern is usually easy. The sales person appears to be following a predefined sequence and is not eager to deviate from the path. He or she might even be referring to notes as they proceed. In such cases, ask about a different feature and then ask how easy that feature is to implement. Once the sales person answers, it should not be much of a problem for him or her to DEMONSTRATE the feature to the crowd. At this point the sales person is trapped, and must acquiesce or start providing reasons why they cannot.

If possible, ask for an opportunity to “drive” the system and take part in the demonstration rather than simply watching it. Now you are in control and can easily go down different paths and try different features to better evaluate the system’s strengths and weaknesses. If the system is good then it should have no problems handling whatever you ask it to do.

Watch-Outs: Sometimes a presentation is being made in front of a large group of diverse customers and your question is not of interest to most of the people in the room. Rather than taking up everyone’s time chasing a side issue, take it up with the sales person on an individual basis after the demonstration is finished.

Exceptions: Occasionally a product is so bad or the sales person is so nervous that the scripted presentation is all they can do. In such a case, there is nothing gained by embarrassing the person any further by forcing them off the script. Just recognize the situation for what it is and move on.

Insight: This same idea applies to factory acceptance tests. Do not let the integrator take the system through a scripted test sequence to prove its functionality. Instead, intentionally close the wrong valve or press the wrong button. Force the system off the beaten path. It is certain that the operators will do that eventually and it is far better to discover problems before the system is on line! If possible, require that the integrator be completely hands off during testing to prevent them from nudging the system along during testing.

Rule of Thumb: A well-designed system should be able to handle whatever is thrown at it, especially the “non-standard” situations. Every now and again step off the beaten path, throw the system a curve, and see what transpires.

About the Author
Gregory K. McMillan, CAP, is a retired Senior Fellow from Solutia/Monsanto where he worked in engineering technology on process control improvement. Greg was also an affiliate professor for Washington University in Saint Louis. Greg is an ISA Fellow and received the ISA Kermit Fischer Environmental Award for pH control in 1991, the Control magazine Engineer of the Year award for the process industry in 1994, was inducted into the Control magazine Process Automation Hall of Fame in 2001, was honored by InTech magazine in 2003 as one of the most influential innovators in automation, and received the ISA Life Achievement Award in 2010. Greg is the author of numerous books on process control, including Advances in Reactor Measurement and Control and Essentials of Modern Measurements and Final Elements in the Process Industry. Greg has been the monthly "Control Talk" columnist for Control magazine since 2002. Presently, Greg is a part time modeling and control consultant in Technology for Process Simulation for Emerson Automation Solutions specializing in the use of the virtual plant for exploring new opportunities. He spends most of his time writing, teaching and leading the ISA Mentor Program he founded in 2011.

Connect with Greg

About the Author
Hunter Vegas, P.E., has worked as an instrument engineer, production engineer, instrumentation group leader, principal automation engineer, and unit production manager. In 2001, he entered the systems integration industry and is currently working for Wunderlich-Malec as an engineering project manager in Kernersville, N.C. Hunter has executed thousands of instrumentation and control projects over his career, with budgets ranging from a few thousand to millions of dollars. He is proficient in field instrumentation sizing and selection, safety interlock design, electrical design, advanced control strategy, and numerous control system hardware and software platforms. Hunter earned a B.S.E.E. degree from Tulane University and an M.B.A. from Wake Forest University.

Connect with Hunter

Pin It on Pinterest