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.

The Top Plant program honors outstanding manufacturing facilities in North America. View the 2015 Top Plant.
The Product of the Year program recognizes products newly released in the manufacturing industries.
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.
Doubling down on digital manufacturing; Data driving predictive maintenance; Electric motors and generators; Rewarding operational improvement
2017 Lubrication Guide; Software tools; Microgrids and energy strategies; Use robots effectively
Prescriptive maintenance; Hannover Messe 2017 recap; Reduce welding errors
The cloud, mobility, and remote operations; SCADA and contextual mobility; Custom UPS empowering a secure pipeline
Infrastructure for natural gas expansion; Artificial lift methods; Disruptive technology and fugitive gas emissions
Mobility as the means to offshore innovation; Preventing another Deepwater Horizon; ROVs as subsea robots; SCADA and the radio spectrum
Research team developing Tesla coil designs; Implementing wireless process sensing
Commissioning electrical systems; Designing emergency and standby generator systems; Paralleling switchgear generator systems
Natural gas engines; New applications for fuel cells; Large engines become more efficient; Extending boiler life

Annual Salary Survey

Before the calendar turned, 2016 already had the makings of a pivotal year for manufacturing, and for the world.

There were the big events for the year, including the United States as Partner Country at Hannover Messe in April and the 2016 International Manufacturing Technology Show in Chicago in September. There's also the matter of the U.S. presidential elections in November, which promise to shape policy in manufacturing for years to come.

But the year started with global economic turmoil, as a slowdown in Chinese manufacturing triggered a worldwide stock hiccup that sent values plummeting. The continued plunge in world oil prices has resulted in a slowdown in exploration and, by extension, the manufacture of exploration equipment.

Read more: 2015 Salary Survey

Maintenance and reliability tips and best practices from the maintenance and reliability coaches at Allied Reliability Group.
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 Society for Maintenance and Reliability Professionals an organization devoted...
Join this ongoing discussion of machine guarding topics, including solutions assessments, regulatory compliance, gap analysis...
IMS Research, recently acquired by IHS Inc., is a leading independent supplier of market research and consultancy to the global electronics industry.
Maintenance is not optional in manufacturing. It’s a profit center, driving productivity and uptime while reducing overall repair costs.
The Lachance on CMMS blog is about current maintenance topics. Blogger Paul Lachance is president and chief technology officer for Smartware Group.
The maintenance journey has been a long, slow trek for most manufacturers and has gone from preventive maintenance to predictive maintenance.
Featured articles highlight technologies that enable the Industrial Internet of Things, IIoT-related products and strategies to get data more easily to the user.
This digital report will explore several aspects of how IIoT will transform manufacturing in the coming years.
Maintenance Manager; California Oils Corp.
Associate, Electrical Engineering; Wood Harbinger
Control Systems Engineer; Robert Bosch Corp.
This course focuses on climate analysis, appropriateness of cooling system selection, and combining cooling systems.
This course will help identify and reveal electrical hazards and identify the solutions to implementing and maintaining a safe work environment.
This course explains how maintaining power and communication systems through emergency power-generation systems is critical.
click me