This article is the continuation of the my previous article about lean implementation methodology for PLM. It is ok to present methodolgies that are said to be best for implementing a PLM strategy. It is better to provide examples and solutions on how to start these implementations. When I was reading about lean startup the good thing was that the illustration of the MVP, Minimum Viable Product was quickly provided and it allowed me to understand through this examples what was key for users to have in order to be able to get feedbacks to, if necessary, pivot as soon as possible. It has to have not too much and not too few features, you can be wrong about the way you think it will evolve and about the product you start with, you shouldn’t be too wrong about the amount of things provided at first.
Size of MVP depends on the departement you are developping the system for
Recently, my other article about why we shouldn’t start a PLM implementation from the engineering has been the root of many comments and discussions on linkedin but also in the meetings I had after that. One of the important point was to get some users live on the system as soon as possible to enhance the dynamic of the PLM implementation project. Most functionnal PLM consultant independant from software editors use to say that the important thing is the PLM initiative itself and not the software. For them what is important is to make people aware that they are all bringing some value to the product. The sooner you get people live on the system the better your PLM initiative will be.
A matter of Budget triggered by the software implementation
Many times in the comments I received on linkedin and other networks were related to justifying a cost of implementation. I had many times the comment that it was easier to have such budget validated when it was impacting R&D than other departements. We know most of the cost is held by the software implementation and not to pure consulting. Then you realize that with these arguments, the way the implementation will be made will be triggered by the software and that is not what you are looking for. Years ago there was the wave of the “toolbox” system which still existed then but were banned from marketing. Toolbox system could be adapted to any departments the same way you use Microsoft Access, adding workflows, … Problem is, the software was already too expensive. So wen selecting a solution it would be right to look at flexibility of the system and flexibility on pricing.
- Does your MVPLMS has to start with engineering? still a question for which I’m not sure about the answer.
- What is the MVPLMS scope?