PLM Interest Group

The PLM Interest Group provides neutral tools, expert knowledge, managed programmes and leadership to raise the performance of PLM.

The PLMIG provides a wide range of structured methodologies to enable Members to raise their implementations to a standard of PLM excellence.

PLMIG toolsets are the instruction books for PLM. They embody most comprehensive and advanced set of neutral working methodologies for PLM.

                  Recovery and Refocus

          Make the Most of your current PLM Effort

PLM implementations can die a long, slow death - almost like a polar expedition that does not reach its goal in time and runs out of energy on the way home.

The PLM Team feels trapped by events, and more and more powerless to overcome the barriers. Management loses faith, and users long for the way things used to be.

The answer is not to give up, but to recover.

In any major corporate PLM implementation, at least 80% of the work will have been useful.

The way ahead is to make use of this in the new, corrected PLM environment.

There are 3 main scenarios of PLM failure.

Scenario 1:  A far-reaching and ambitious PLM programme is defined, based largely on a complex solution provided by a particular vendor.  The focused, high-profile programme is followed vigorously for a number of years until the technical difficulties mount up.

Management loses patience with the expense and delays.  The members of the PLM Team leave or are forced out, and new managers are brought in to start again from scratch.

Scenario 2:  A major corporation approves a range of projects under the 'PLM umbrella' that are run together as a programme.  The effort produces improvements that resolve problems under the surface but achieve no headline results.  Many outlying parts of the business are untouched, and are left wondering when they will become involved.

Eventually the programme is deemed to be ineffective.  The PLM Team is forced to hold meetings to decide what to do next, and the meetings cycle seems to run indefinitely.

Scenario 3:  A company or corporation knows it has to "do something about PLM", but does not understand its importance.  It puts in place a PLM Manager who is then left to work out what to do about this.  The PLM Manager is faced with a user base that likes working with spreadsheets and legacy systems, and who do not see the value of change.

Management decides that PLM is not worthwhile, and the PLM Manager is sidelined.

All three of these scenarios waste the company concerned time and money.  Improvements that should be gained from PLM are abandoned; money that has been spent on PLM so far is written off; and whoever is left to pick up the pieces has to start again from first principles.

If your implementation is heading in this direction, you should start the recovery before you hit the crash. If you have reached this point there is a process to follow that will create space for the recovery.

In all cases, the aim is to retain the maximum value from the effort so far, and to move smoothly onto a corrected path.