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.)
One 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.
Because 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, www.brlconsulting.com. His firm focuses on manufacturing IT. Contact him at dbrandl(at)brlconsulting.com. Edited by Mark T. Hoske, Control Engineering, www.controleng.com.
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.
Case Study Database
Get more exposure for your case study by uploading it to the Plant Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.
Annual Salary Survey
In a year when manufacturing continued to lead the economic rebound, it makes sense that plant manager bonuses rebounded. Plant Engineering’s annual Salary Survey shows both wages and bonuses rose in 2012 after a retreat the year before.
Average salary across all job titles for plant floor management rose 3.5% to $95,446, and bonus compensation jumped to $15,162, a 4.2% increase from the 2010 level and double the 2011 total, which showed a sharp drop in bonus.