Engineering and IT Insight: Are you using the wrong control system tools?

Applying the wrong tools in control system projects can be akin to using stone knives and bearskins. Which of these five misused tools are killing your productivity?

By Dennis Brandl November 5, 2010

Anthropologists say that man could be called the toolmaking animal. Other animals build and use simple tools, but mankind displays the pinnacle of this behavior by building cars, trucks, power tools, airplanes, spaceships, computers, PLCs, DCSs and advanced control systems. With all of our toolmaking and tool-using abilities, it is difficult to understand why some control system projects fail because they don’t use the right tools for the job. Some project teams are trying to execute control system projects using “stone knives and bearskins.” (From Star Trek, April 1967, “The City on the Edge of Forever”)

Using the wrong tool for a job is the third bad habit of unsuccessful projects. Using tools that are not suited to the job can be the cause of significant wasted time and effort, leading to errors, rework, and frustrated team members. Anyone who has tried to fix a car or appliance without the right tool can understand this problem. Tasks that can be done in minutes by one person with the right tool may take hours for multiple people using the wrong tools.

Many control system projects will only use standard office environment tools to manage schedule, requirements, problem reports, source code control, designs, and other project-specific tasks. Office tools (text editor, word processing, spreadsheets, and presentation software) are usually included with the IT department’s standard PC build, so they are available to all users. Their universal availability often means they are the first choice to solve a problem, but not necessarily the best choice.

Commonly misused tools are:

  1. Spreadsheets used to manage schedules,
  2. File systems to manage documents and source code,
  3. Word documents or spreadsheets to manage change requests and problem reports,
  4. Presentation tools to document architectures and designs, and
  5. Text editors instead of IDEs (integrated development environments).

1. Project scheduling. Spreadsheets are great general purpose tools that were made popular in 1979 on Apple II computers. However, after 31 years there are better tools available for project scheduling. Scheduling tools, such as Microsoft Project (www.microsoft.com), Primavera (www.oracle.com/primavera), (at)task (www.attask.com), and Clarizen (www.Clarizen.com), manage task dependencies and resource leveling in ways not possible using spreadsheets. These tools have been refined over decades to provide comprehensive project scheduling support and visibility into project activities, yet many unsuccessful projects will not use these tools.

2. Managing documents. Using a shared file system instead of a document management system to manage requirements, source code, change logs, and other project documents is another example of using the wrong tool. Shared file systems don’t have the document meta-information that assists in searching, don’t handle automatic version control and change tracking, and don’t have check-in and check-out controls. The biggest problem with shared file systems for project documentation is the time spent finding documents. Some project teams spend 20 percent of their time looking for the right documents or trying to find the latest version of a document. Without check-in and check-out capability it is always a challenge to know who is working on a document and the status of the document. For document management you can use collaboration tools such as Microsoft SharePoint, Google Sites, Altassian’s Confluence (www.atlassian.com), box.net (www.box.net), or Xythos (www.xythos.com); or dedicated content management tools such as Documentum (www.emc.com/domains/documentum).

3. Change tracking. Managing problem reports and change requests in spreadsheets using shared files is another common tool misuse. Often there are hundreds of problem reports or change requests in a single project. Creating, prioritizing, assigning, and tracking status changes can be a major task that is best accomplished using a problem tracking dedicated tool, such as NetResults (www.netresultstracker.com) or Bugzilla (www.bugzilla.org).

4. Dedicated design environments. Software designs are complex systems, with many integrated parts. Using a general purpose drawing tool to document architectures and designs leads to errors and rework.  Dedicated design environments, such as Enterprise Architect (www.sparxsystems.com) or Rational (www.ibm.com/software/rational) eliminate typos and common errors that can slow down or even stop projects.

5. Integrated development environments have become standard tools in programming projects, but many control system projects will still use Microsoft Notepad to edit files. If your vendor does not provide an IDE, there are specialized text editors that can simplify code development and provide built-in syntax checking and error detection. Tools such as JEdit (www.jedit.org), Gedit (www.gnome.org/projects/gedit), and UltraEdit (www.ultraedit.com) provide a near IDE environment and can significantly increase your team’s productivity.

Experience, youth each provide wisdom

You know that your project has a bad habit if the team members are always using the same tools for all jobs. When all you know how to use is a hammer, then every problem looks like a nail. If this is the case, then it is time to “teach the old dogs new tricks.” Some control engineers that have been out of college for some time (and are getting gray hair) do not realize how the Internet has changed the habits of development. Today the best method to solve a problem is to reuse and not reinvent. You can reuse solutions found on the Web using simple searches. These solutions will usually point to dedicated tools and reviews of alternate tools. Web searches are a good starting point to discover if there are better tools you can use on your control system projects.

Older engineers can also teach your “new dogs some old tricks.” With the release of Microsoft Power Shell as a widely available tool, the ability to develop sophisticated command line scripts has been restored. Older engineers and programmers who worked in Unix and MS-DOS environments knew the power of command line scripts to automate repetitive tasks, using tools such as AWK and SED. The scripts were specialized tools used to eliminate manual activities. PowerShell now provides a command line environment with the added ability to handle structured information and sophisticated error handling. Any time you have to perform repetitive tasks in your control system project, consider using a PowerShell script instead to reduce time, effort, and manual errors.

None of the special purpose tools mentioned will add significant cost to a project, especially when you consider the increased productivity that comes from the tool’s use. Don’t force your project’s team members to use the wrong tools for their jobs; instead, encourage them to increase their efficiency by finding the best tool for the job. They may have to buy, build, or learn to use the tool, but the time saved will help your projects succeed.


– Dennis Brandl is president of BR&L Consulting in Cary, NC, 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.


Also read:

– Engineering and IT Insight: Schedules for engineers – A missing or unrealistic schedule is a bad habit common to unsuccessful projects. Lack of experience in the project space can lead to ballpark estimates and schedule slippage.

IT and Engineering Insight: Control architecture, who needs it? – If you have a large control software programming project and no control system architect, small changes can lead to dead ends and bad decisions.

IT and Engineering Insight: Seven habits of unsuccessful projects – Understanding if you are in an out-of-control IT project is important. Here are some traits of failing or soon-to-fail projects. If your project has three or more of these attributes, you need a project "reboot."

Production line remote monitoring – Engineering and IT Insight: Automation engineers spend a lot of time just getting to the right place to identify and fix problems. The IT solution to this problem is based on VNC, or virtual network computing.