06 October 2009
Dennis Brandl -- Control Engineering, 9/1/2009A 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 artefacts. The project artefacts 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 artefacts are kept only on desktop systems. At some stage in the project, these artefacts 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 artefacts in common storage and, if possible, place the artefacts 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 artefacts captured.Capturing folded project artefacts allows you to reuse those artefacts 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 artefacts 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 artefacts 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.
Print this page | E-mail this page
This isn't a paywall. It's a Freewall. We don't want to get in the way of what you came here for, so this will only take a few seconds.
Register Now