PLM By The Book – is it even possible?

It can be very reassuring to pay thousands of dollars for PLM consultancy.  Or maybe a million or two, if you are a global corporation.

What greater peace of mind can there be than to know that everything will be taken care of?  At the end of the project there will be a leading-edge, seamless implementation, exactly aligned with the needs of the business and supported by comprehensive documentation.  Money well spent.

The project would have been far too large and complex to be run internally, and why should the PLM Team struggle to understand every last detail when the integrators have it all covered?

Therein lies the problem.

With scores of people working on the project, from different organisations and with different levels of skills and experience, it can be very difficult to maintain a clear, accurate, and (most importantly) unified position of PLM direction and progress. 

All of the working plans, presentations and documentation will be brand new.  Initially, most of them are drafts because nothing has yet been agreed.  Stakeholders need to be educated, and introduce questions and curveballs as they try to comprehend it all.  Controlling personalities push their views too hard, and others acquiesce.  The project aims become imbalanced.  Workshop follows workshop, generating new issues that complicate the mix.  Integrators fall back on their standard methodologies for a structure, and the PLM Team hopes that it will all work.

And maybe it does.  After all, every real-life PLM implementation is a one-off, as every organisation’s PLM is different.  It must obviously be flexible, in response to the particular circumstances.  How could a book that was written before everything even started possibly apply to all of this, let alone be of any help?

It depends on the scope of the book. 

PLM is all about applying a range of detailed fundamentals in a wider business landscape.  Those detailed fundamentals can be captured in a very concise written format, because (as they are fundamentals) they are the same every time.  Sharp and accurate documentation makes for common understanding and agreement. 

And as PLM concepts can be difficult to grasp, people may have to go round a “thought loop” several times before the penny drops.  With written documentation, you can do that.

The Product Structure Standard is an example of how people need to see a reasoning in black and white several times before grasping it.  How you configure your products within the PLM system is so important that you must get it right.  Mistakes and errors permeate everywhere with increasing consequences.  The Standard differentiates between ‘Controlled Products’ (which a customer can order on a contract, and which must exist in the same form within PDM); and ‘Uncontrolled Products’ (which are optional configurations that can be altered at will).

While the Standard was being created, on a live implementation in Norway, people would ask a question, read the Standard, say they understood, and then ask the same question again and again.  Only by repeatedly referring them back to the written text in the Standard did the concept finally take hold.

The same is true of your overall project documentation.  It must be clear, precise, accurate and comprehensive.  Only then will all of the stakeholders align with it at their various speeds so that you get a genuinely agreed understanding.

‘PLM by the book’ is not the whole answer, but it is one of the best ways of keeping everyone on track.