Let’s talk about medicine to build an analogy.  I imagine that all of us have had some exposure to that topic.  The nagging question seems to always be whether the help you need requires the Mayo Clinic, or if it is something that any local physician can handle.  I remember some counseling that I received years ago from an oncologist.  He said, “No matter who you talk to about treatment their specialty will be their preferred and recommended approach, but whatever you decide to do remember that the outcome is operator dependent.”   If you are the one who is going to live with the results of the work to be performed,  you may think about who you would select a little differently than someone who might be making the decision in your behalf.  When we think of ‘specialized’ medicine, we often think of top surgeons or solving medical mysteries.

Within a control system project, there might be specialized expertise that is required as well.  Project size alone can have its own complexity, or schedules can introduce challenges that a limited number of project teams can handle.  Then there is the matter of actually getting something delivered that you can support without the author’s continual presence in your plant.  There are other things that contribute to our understanding of ‘specialized’, but I think we get the point.

At Bachelor Controls, our focus is to be the ‘best value through startup’. That should lead to a lower total cost of ownership as well. In order to achieve ‘best value through startup’ both the SI and the customer need to invest significantly at the beginning of the project. It’s often been said that ‘the devil is in the details’. Well so is success! Gather as much information as practical from the groups and individuals that will be affected by the work. This typically includes system operators, engineers, managers, IT personnel and maintenance personnel. The intentional, up-front communication with all the stakeholders allows the customer’s system to be clearly understood and documented. With this mutual investment, the project needs can be more accurately described and then developed. Depending on the complexity of the project, this exercise can be brief with simply an informal concept of operation. For more complex projects the exercise will be longer and a functional specification that evolves into a detailed design specification would be more appropriate tools for describing the work and guiding the process.
A well-designed specification equips the project team with a defined scope of services and a project plan for managing and completing the project successfully. The schedule needs to contain milestones that will identify responsibilities for both the integrator and the customer alike. The project needs to follow a structured project methodology that takes into account the identification of risk areas and how to deal with those in a way that minimizes the potential for schedule impact. The specification should also deal with abnormal situations that could arise in the customer’s system and then describe how those should be handled. Many abnormal situations can be incorporated into the automation logic, but it may not be practical to address all abnormal scenarios with automation logic. It is OK to deal with some abnormalities through operator intervention, but that should be clearly understood along with a description of what the operator is to do.

The integrator should be able to produce a documented project methodology showing flow and a written document describing the methodology.  Without such a documented procedure, the methodology will take on individual personalities and the outcomes will be more varied and more a function of the team members than of the corporate oversight.  The methodology should contain design reviews to validate that the solution is on track and all the stakeholders are satisfied with the direction and progress of the work.  The methodology needs to also have a documented FAT (Factory Acceptance Test) protocol.  Without a written protocol to guide the SI and the customer through the testing portion of the project, the team simply tries a variety of things until everyone gets tired and quits.  This is testing that is to be performed before the system is released to be shipped to the customer’s site.  With a structured protocol, both the customer and the team can have confidence that the testing portion of the project has been thorough.

Separate from the above testing regimen, is the testing of any control panels or system I/O  (input/output) modules that are being shipped to the customer site.  At Bachelor Controls, our slogan is “Every Panel – Every Wire – Every Time”.  A time-proven process in trouble shooting a system is to ‘divide the problem’.  By thoroughly testing the control panels prior to shipping, the field checks become simpler because of the thorough testing, hence, confidence in the panel accuracy.

Upon arriving on site after the automation system has been installed, wired and plumbed, the system must have an I/O check completed before attempting to run. All the motors, valves, operators, etc. need to move as expected and their feedback signals need to be validated within the automation controller. All network connections must be verified and an overall network performance evaluation might even be appropriate.
Having completed the activities described in the above paragraphs, the system should be ready for ‘dry runs’ or ‘water tests’ or whatever minimal cost exercise can be used to validate the actual installed compliance with the scope of work that was so diligently developed at the beginning of the project.

When working through a project in this manner, the typical result will be a system that ramps up to production rates in minimal time, which is where the real value of the work is seen.  Extra contractor personnel get to leave the job earlier and the client gets to start making good product sooner.  That is ‘Best Value through Start Up’.

Ray Bachelor
Chairman of the Board