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.)


Dennis BrandlOne of the paths to creating a great manufacturing IT product is through a great manufacturing IT project. There is a thrill in seeing a successful project completed. The end users are happy and understand the system, and everything was completed on schedule and under budget. Many system integrators, end users, and vendors want to take the next step and convert the project deliverables into a product. When taking this step, it’s important not to underestimate the extra effort required to convert a successful project into a successful product.

System integrators, consulting companies, internal development organizations, and even large automation companies have all attempted to convert projects into products. For system integrators and consulting companies, the product is usually composed of internally developed tools and libraries of commonly used project code. For internal development organizations, it is work developed at one site that is then rolled out to multiple sites. Automation companies often attempt the conversion by purchasing a company with project experience and then converting its project code and internal tools to a general distribution product.

Converting a project to a product requires that work done at one site (with very specific requirements, local committed users, and an implementation team of experts) can be replicated at multiple sites, with widely differing requirements, limited end-user commitment, and limited or no experts available to assist in installation, checkout, and start-up.

The primary differences between projects and products are: requirements’ scope, documentation support, installation ease, actionable error messages, graceful failures, test coverage, stress testing, and minimum environment requirements.

Projects have a well-defined and testable scope that covers one specific problem or area. Products must cover a range of different, but similar, problems. Requirements that were defined for a project or a set of projects must be re-evaluated. The new requirements must be verified with potential new customers and in new situations. Often the requirements must be extended, resulting in redesign and rework of the project code. These efforts can easily double the original project requirements cost.

Projects often include at least some documentation left with the end user, but few projects include the full set of documents normally provided by a product. Products have professionally developed user guides, installation manuals, technical guides, and debugging frequently asked question (FAQ) documents. Projects normally have design guides, unreviewed notes from developers, or at best some form of online help. New documentation must be generated to convert the project to a product. Generating well-written and complete documentation will often take 25% to 50% of the original project coding and documentation effort.

Products have automated installs; projects have manual installs. Project teams often will not consider how easy it is to install the system. It may take several days and multiple people to install and start up the software, but the project attitude is often “we only do it once, so it’s not worth it to make it easy,” or “it’s easier to just document the steps instead of automating them.” Adding automated installation to the project can easily add 25% of the original project effort. It could add more if the automated install must be performed in multiple target environments.

Products have actionable error messages. These are error messages that direct users to the actions they must take to resolve the problem. The actions may involve fixing configuration problems, correcting security access, or contacting support services. Most projects will have cryptic error messages identified by numbers (such as Error 42), which provide no help to the user on how to resolve the issue. Well-written projects may provide a document with the error codes, but few projects include all possibly displayed errors. The error messages for projects are often designed to aid the developer in debugging and not to aid the user in correcting the problem.

Products usually provide graceful failures. A graceful failure is a failure where the system never freezes, information is saved for later debugging, the system may run in a restricted but still usable mode, messages are provided that guide the user to actions to eliminate problem, and the system can restart without requiring user intervention. Project code will often stop or freeze in the event of a failure, such as loss of an OPC connection or failure to update a database. In the worst case a user may have to manually update databases or configuration files after a failure to allow the system to restart.

Products are tested in multiple environments, cover a wide variety of uses and configurations, are stress tested to determine system limits, and are tested in minimal environments. Projects are often tested only in one environment for a limited number of configurations. In addition, projects will often be tested and installed on oversized hardware to not stress the system. Stress testing, minimal environment testing, and multiple configuration testing will often unearth problems that would never be seen in the original project environment.

In addition to the differences mentioned above, there are more considerations:

  • Products have user support, while projects provide the phone numbers of the developers. Usually the project developers are only minimally available for support because they are assigned to other projects and not formally assigned to ongoing support.
  • Products usually include examples and don’t start with blank screens. Projects will not normally provide any help in this area or, at best, there may be a short set of cryptic notes that explain how to get started. Many projects include user configuration, but a delivered product requires the end user to perform the configuration. This means that a product must include the documents, wizards, and examples needed to perform the initial system configuration.
  • Products check their configuration for validity at start-up so that they don’t get into invalid conditions. Project code will often operate under the assumption that everything is operating correctly and has been correctly installed.
  • Products have well-written and well-documented code. Projects usually have sparse code documentation and often do not follow “professional strength” programming standards. Product code is “read” many times as the product evolves, so it must be readable and well commented. Project code is often never looked at after installation, so there is little advantage to making it readable and well commented.

Controls and IT Integration, Control EngineeringBecause of differences between projects and products, the effort required to convert project code to a product can be 3 to 10 times the original project effort. Many system integrators, end users, and vendors do not fully appreciate this extra effort and will rush to push out project code as if it were a product. This results in angry users, a poor reputation for the product, and a damaged reputation for the developers. If you are converting a project into a product, remember the important differences between the two and ensure that you plan for the effort required to develop a robust product.

- Dennis Brandl is president of BR+L Consulting in Cary, NC, His firm focuses on manufacturing IT. Contact him at dbrandl(at) Edited by Mark T. Hoske, Control Engineering,

Further reading:

Engineering and IT Insight: Keep documentation in sync with code—Deferring software documentation can create future difficulties, slowdowns, and errors. Ensure user, design, and test documents are up to date with software code.

Engineering and IT Insight: Virtualize now, send the message to your vendors—Virtualization simplifies system upgrades, and there are at least two more reasons to virtualize and three major issues to address.

Top Plant
The Top Plant program honors outstanding manufacturing facilities in North America.
Product of the Year
The Product of the Year program recognizes products newly released in the manufacturing industries.
System Integrator of the Year
Each year, a panel of Control Engineering and Plant Engineering editors and industry expert judges select the System Integrator of the Year Award winners in three categories.
October 2018
Tools vs. sensors, functional safety, compressor rental, an operational network of maintenance and safety
September 2018
2018 Engineering Leaders under 40, Women in Engineering, Six ways to reduce waste in manufacturing, and Four robot implementation challenges.
GAMS preview, 2018 Mid-Year Report, EAM and Safety
October 2018
2018 Product of the Year; Subsurface data methodologies; Digital twins; Well lifecycle data
August 2018
SCADA standardization, capital expenditures, data-driven drilling and execution
June 2018
Machine learning, produced water benefits, programming cavity pumps
Spring 2018
Burners for heat-treating furnaces, CHP, dryers, gas humidification, and more
October 2018
Complex upgrades for system integrators; Process control safety and compliance
September 2018
Effective process analytics; Four reasons why LTE networks are not IIoT ready

Annual Salary Survey

After two years of economic concerns, manufacturing leaders once again have homed in on the single biggest issue facing their operations:

It's the workers—or more specifically, the lack of workers.

The 2017 Plant Engineering Salary Survey looks at not just what plant managers make, but what they think. As they look across their plants today, plant managers say they don’t have the operational depth to take on the new technologies and new challenges of global manufacturing.

Read more: 2017 Salary Survey

The Maintenance and Reliability Coach's blog
Maintenance and reliability tips and best practices from the maintenance and reliability coaches at Allied Reliability Group.
One Voice for Manufacturing
The One Voice for Manufacturing blog reports on federal public policy issues impacting the manufacturing sector. One Voice is a joint effort by the National Tooling and Machining...
The Maintenance and Reliability Professionals Blog
The Society for Maintenance and Reliability Professionals an organization devoted...
Machine Safety
Join this ongoing discussion of machine guarding topics, including solutions assessments, regulatory compliance, gap analysis...
Research Analyst Blog
IMS Research, recently acquired by IHS Inc., is a leading independent supplier of market research and consultancy to the global electronics industry.
Marshall on Maintenance
Maintenance is not optional in manufacturing. It’s a profit center, driving productivity and uptime while reducing overall repair costs.
Lachance on CMMS
The Lachance on CMMS blog is about current maintenance topics. Blogger Paul Lachance is president and chief technology officer for Smartware Group.
Material Handling
This digital report explains how everything from conveyors and robots to automatic picking systems and digital orders have evolved to keep pace with the speed of change in the supply chain.
Electrical Safety Update
This digital report explains how plant engineers need to take greater care when it comes to electrical safety incidents on the plant floor.
IIoT: Machines, Equipment, & Asset Management
Articles in this digital report highlight technologies that enable Industrial Internet of Things, IIoT-related products and strategies.
Randy Steele
Maintenance Manager; California Oils Corp.
Matthew J. Woo, PE, RCDD, LEED AP BD+C
Associate, Electrical Engineering; Wood Harbinger
Randy Oliver
Control Systems Engineer; Robert Bosch Corp.
Data Centers: Impacts of Climate and Cooling Technology
This course focuses on climate analysis, appropriateness of cooling system selection, and combining cooling systems.
Safety First: Arc Flash 101
This course will help identify and reveal electrical hazards and identify the solutions to implementing and maintaining a safe work environment.
Critical Power: Hospital Electrical Systems
This course explains how maintaining power and communication systems through emergency power-generation systems is critical.
Design of Safe and Reliable Hydraulic Systems for Subsea Applications
This eGuide explains how the operation of hydraulic systems for subsea applications requires the user to consider additional aspects because of the unique conditions that apply to the setting
click me