What are your manufacturing IT project principles?

Engineering and IT Insight: Do many projects seem to repeat basic arguments on project direction and options? Does the team often rehash issues? If so, then perhaps you need to specify project principles; 10 tips, and alternatives, follow.

By Dennis Brandl December 15, 2011

Do many of your projects seem to repeat basic arguments about the project’s direction and options? Does your project team always seem to want to go back to the starting point and rehash old issues? If so, then perhaps you need to specify project principles. Principles are a vital aspect of any successful organization because they provide consistent help and direction in making basic decisions.

Principles provide general rules and guidelines that are intended to be persistent and rarely changed. There are hundreds of different kinds of principles, ranging from personal principles, such as “I will not lie” or “I will not steal,” to engineering principles such as the US Navy’s principles of engineering, manufacturing principles such as the ISO 9004 Quality Management Principles, and professional principles from ACM (Association of Computing Machinery) for ethical activities of software engineers.

The value of having well-defined and accepted principles is that they remove many undesirable alternatives that you might use on a project. This is important in IT projects because there are usually many possible strategies, custom and commercial solutions, and vendors.

There is no single list of project principles that applies to all companies, but the following examples can be helpful in selecting project principles. For principles, there are often two opposing alternatives. The correct alternative can depend on the size of your company, if you are a vendor or an end user, if you have a good IT organization or rely on external consultants, or if you have pre-existing specific company-wide principles.

The following are 10 principles, and the alternatives, that I have encountered:

1. Pick the “Best of Breed” solutions and integrate them over a less capable integrated single vendor solution –or– pick an integrated solution from a single vendor of a set of “Best of Breed” solutions.

2. Give a preference to buying solutions instead of building them –or– give a preference to building a focused custom solution instead of compromising on a non-optimal commercial solution.

3. Plan and design for expected future enhancements –or– plan and design to exactly meet the end user’s requirements.

4. Give preference to industry communication standards, such as OPC-UA and MTConnect –or– give preference to the vendor’s recommended communication standard.

5. Pick solutions that follow industry naming and modeling standards, such as ISA88 (Batch Control), ISA95 (Enterprise-Control System Integration), and ISA99 (Industrial Automation and Control Systems Security) –or– select vendor solutions that have been optimized for their environment.

6. Give preference to commercially available industrial network hardware, such as hardened Ethernet –or– give preference to hardened and proven propriety vendor network hardware.

7. Do not modify the equipment vendor’s code or HMI interface –or– replace equipment vendor code with custom code that follows the company’s interface and HMI standards.

8. Deliver no system or software before the documentation is complete –or– deliver systems and software as soon as they are available so they can be used by the end user.

9. Never put software developed outside of the company into any company software unless approved by the VP of development –or– never build software when you can buy it instead.

10. Never change anything on a production system with written approval –or– fix the problem first, then document the changes and get written approval for a permanent change.

If your principles are technology focused, then they should be reassessed every several years.

Technologies change, and what made sense five years ago may no longer be appropriate. For example, a build-versus-buy decision may change because the market now offers solutions (so buy), or the market no longer offers solutions (so build).

Basically, project principles restrict choices. This means that they must be well thought out and the consequences understood. Following principles may not always lead to the cheapest or fastest solution, but it will lead to best solutions for your environment.

– Dennis Brandl is president of BR&L Consulting in Cary, N.C., www.brlconsulting.com. His firm focuses on manufacturing IT. Contact him at dbrandl@brlconsulting.com. Edited by Mark T. Hoske, Control Engineering, www.controleng.com.

www.acm.org 

www.iso.org/iso/qmp 

Related reading

Design, documentation, support, and system snapshot can preserve software investments.  

Engineering and IT Insight: How to convert a project into a product—Extra effort is required to convert a manufacturing IT project into a successful product. Advice follows on how to do it. (If you’re considering buying software that sounds or test drives more like a project, you may want to look at other software.)

Engineering and IT Insight: How to convert a project into a product