May/June 2013
Talk to Me

Good specifications avoid problems

By Bill Lydon, InTech, Chief Editor
 talk1

Good specifications avoid problems and result in better automation projects. Many automation problems start with poorly thought-out design and purchase specifications that cost large amounts of money over time. For instance, when people in an organization assert that it is cheaper and quicker to purchase sensors, controllers, human-machine interfaces (HMIs), and other project materials and start the application development and installation without a full definition. In many cases, managers make this assertion with little or no technical or field experience. The theory is that design work can be done on the fly - after all, we know what we want. This is a false economy that is likely to be expensive over time.

I once worked for an experienced automation manager who believed in the value of detailed design and purchase specifications up front; he saw the savings in doing it right. He stressed, "If you don't invest in design and specification effort up front, then the cost in time and money later is much larger." Investing up front in detailed specifications without ambiguous information allows for estimating timelines far more accurately as well as purchasing the right items leading to installation, commissioning, and startup progressing faster.

Bad specifications can lead to many problems and in some cases may be career limiting. If a project is done on the fly without specifications, then users and management may start asking why the system is not working and/or meeting the expected needs. It is important to create specifications that management and users can understand so everyone agrees. This process is also helpful to avoid feature creep that puts your project over budget and extends completion times. There cannot be enough said about the importance of spending the time at the early stages of a project defining specifications and getting input from other stakeholders to safeguard your time and budget expectations and, in the end, deliver quality results.

Also important is to work out design issues before installation when changes are more costly. Fortunately, with automation software today, you can rapidly prototype screens and other functions that can be part of your specification, making it easier for people to review and comment. In addition, most control software provides the ability to build logic and simulate functions using variables rather than real sensors and actuators, so you can virtually understand the dynamics of control and sequences.

A difficult issue to deal with can be enthusiastic purchasing people who want to substitute software and hardware devices that have a lower price and are allegedly "like or same as" on the project. This is possible, but without a good specification and interaction with purchasing people, items can end up in a project that cost extra project time and money. And poor substitutes can increase the lifecycle cost of projects impacting operations and maintenance costs.

The best specification is one that starts by describing the what - not how, can be interpreted in as few ways as possible and is concise, consistent, and reviewed by all parties involved to improve it and gain agreement. The very process of writing the specification has the benefit of becoming a focal point for everyone, including operations and maintenance, to think over issues before committing to installation. In my experience, having weak or no specifications has resulted in difficult, expensive projects and disappointed people. Good up-front specifications, with buy-in from all involved - including operations and maintenance - have been far more successful. Good specifications provide a clear and unambiguous description of exactly how a project's technical requirements are to be met and benefited by review and input from all parties.

If this sounds like work, it is, but front-end work pays off in better project execution and long-term results.