Manufacturing IT projects contain more than just software. Knowing how to salvage manufacturing IT project components is key for intellectual capital preservation.

Share

It's important to know when to fold a manufacturing IT project, but it is equally important to know what to do when you fold a project. Many manufacturing IT projects do not finish, not necessarily because they failed, but because of changing requirements, changing business conditions, company mergers, or changes in products and processes.

A manufacturing IT project contains more than just software. Any project, whether it's a PLC program, DCS program, MES system, SCADA system, HMI system, integration project, or a combination of these, will have: requirements, designs, test plans, test cases, common libraries, documentation and coding standards, and other project artifacts. The project artifacts still have value because they represent the intellectual capital invested in the project that can be captured and made available for future projects.

Typically, most project artifacts are kept only on desktop systems. At some stage in the project, these artifacts are copied to the target system or to a configuration management system. This is a risky approach because information will then be lost when the project is stopped. This is especially true if the project work is performed by contractors. As they will start looking for the next consulting opportunity once the announcement is made that the project is cancelled. Getting their attention and time to correctly document and save all of their work will be difficult, if even possible. For many projects, once the announcement is made, all outside contractors will be off the site by the end of the day.

The best rule for any project is to capture all project artifacts in common storage and, if possible, place the artifacts in a controlled configuration management system. If you are following the approach of engineers and programmers working in a local sandbox with daily check-in of work and multiple shared versions (daily build, distributed beta, final test, and final build), then you will have all of the artifacts captured.

Capturing folded project artifacts allows you to reuse those artifacts on future projects. For example, most requirements are well reviewed and agreed-to documents and these requirements may still be valid on the next project. Many of the non-functional requirements, such as performance, up-time, and security, may not significantly change from project to project.

Other examples of reusable artifacts include: error handling methods, event logging methods, standard HMI faceplates, standard control module elements (PLC or DCS code), standard interfaces, test strategies, test frameworks, test cases, and standard templates for requirements, code, and tests. Each of these artifacts may have their own requirements, design documents, and code. These documents should be added to a knowledge base and made available to future project teams.

Another important action to take when stopping a project is to generate a set of lessons learned documents. Each document should define a single aspect of the project and if it was completed above, at, or below expectations.

When something worked really well, identify the participants so they can be called in on future projects to share their knowledge. When something did not work, don't identify the participants because the goal of the documents is not to assign blame. Instead when identifying something that did not work, document why it didn't work, what the early symptoms were, and what could be tried instead.

In poker it's important to know when to hold 'em and know when to fold 'em. For manufacturing IT projects, it's also important to know how to fold 'em.

Author information : Dennis Brandl is president of BR&L Consulting in Cary, NC, www.brlconsulting.com. His firm focuses on manufacturing IT. Contact Dennis at dbrandl@brlconsulting.com.