This is a blog from the trenches—written by engineers at Maverick Technologies who are implementing and upgrading control systems every day across every industry. This isn’t what they teach you in engineering school. These are lessons learned from years on the job, encountering the obstacles and issues that are part of the real world of control and process engineering.

Just who is the customer and what does he really want?

Sometimes there are objectives for a project that are hidden below the surface. Can you satisfy those?

Robert K. Henderson, PE, CAP

October 15, 2012

Share

The customer is the individual who pays the bills. The customer is the group that will use the product. The customer is the executive who judges how well the project meets the business needs of the company. We could add more examples to the list, but each of these customers looks at a project slightly differently and judges it in unique ways. As engineers, we must always try to understand these different viewpoints and be responsive to the needs of the various voices that speak for a collective customer. If we do not understand how different stakeholders offering input on a project might be in conflict with each other, we open ourselves up for some nasty surprises.

Some years ago, I was part of a team installing a SCADA system in a food production facility. We were layering data collection and reporting on top of existing line automation. The request for the project and the contract came from the corporate office. It was to be a pilot for similar SCADA systems at a number of facilities.

Design, installation, and startup went smoothly. We were in the training stage, teaching plant maintenance about system health monitoring and details of preventative maintenance, when one technician said to me, “Thanks, but all I need to know are where the weak points are.” I was definitely surprised by this odd request, and our team went to work trying to find out what was going on behind the scenes.

It seems that prior to this project, the plant manager ran the facility as his private kingdom; the only real data received by the corporate headquarters was what he chose to send them in his reports. Our system, by providing raw production data that would be difficult to alter, threatened his autonomy. He was not able to prevent our project from being installed, but he fully intended to make sure it stopped working the moment we were out the door. After some very thoroughly documented testing to prove we had met all the technical requirements and some renegotiated warranty terms, we moved on, leaving the plant and corporate headquarters to fight things out amongst themselves.

In retrospect, it is hard to see how we might have handled the situation differently once we were on site implementing the project. This kind of resistance to our success needed to be identified during the sales meetings or scope development process, but such things are difficult to draw into the open. Unfortunately in this case, those phases of the project process involved the corporate group rather than the plant group. It’s natural to assume that everyone working on a project at the customer company has the same desire for success. They all work for the same company, after all. But in this case, by trusting that the customers at the plant had the same motivations and views as the customers in the corporate office, we failed to identify this grave threat to the success of the project.