This website uses cookies primarily for visitor analytics. Certain pages will ask you to fill in contact details to receive additional information. On these pages you have the option of having the site log your details for future visits. Indicating you want the site to remember your details will place a cookie on your device. To view our full cookie policy, please click here. You can also view it at any time by going to our Contact Us page.

How and when to fold an IT project

06 October 2009

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. It's important to know when to fold a project, but it is equally important to know what to do when you fold a project.

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

Dennis Brandl -- Control Engineering, 9/1/2009

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


Contact Details and Archive...

Most Viewed Articles...

Print this page | E-mail this page