The PLM has been brought on the market by CAD vendors. By extension, it became not only the management of product data but also the management of the process that drive the product definition.
Some will use Microsoft project (or similar tools like PSNext), some will prefer excel (the most extreme case I have seen is managing project plans with PowerPoint presentation...).
Project process that involves only the engineers. Marketing, Sales, Suppliers, Quality,... all the department of the company can be concerned.
How PLM would help?
1 - Have a centralize information
"The single version of the truth".... the motto of PLM consultant. This is the first key. Find the right information and easily.
2 - Gather Project Document
Your PLM implementation should allow you to have a workspace for the project team. This workspace should be controllable in term of access. Globalized team love that...
3 - Manage Tasks and people
Of course, you need to be able to define tasks. But more than the definition, you should be able to distribute the work and follow the advancement of each task. How? Not by simply giving the approximative percentage of completion but with a standardize life cycle (i.e. In Work -> Review -> Complete).
Assigning people the task and identifying the responsible with allow you to have a smother process.
4 - Manage Deliverable
In a company I see 3 types of documents:
- Product Documents: Valid all the life of the product (specifications, user guides, ...)
- Project Documents: Valid only during the project phase (Expenses, Project Finances, ...)
- Enterprise Documents: Separated from the rest, they define the way the company operates (Quality, Process documents, norms,...)
Deliverable are of the two first kind. Product Document will be related to the product structure, Project to the workspace structure, but both need to be attached to the task in order to facilitate the review and the search for documents.
With the usual tools this is what you cannot do.
5 - Manage the risks
Managing a project without a strong management of risk... is a big risk :). Having the risk management very close to your project allow you to have a better identification of what may go wrong. It ensure you to track the risk mitigation.
6 - Review Dashboard
With all the information in one system (or several, from the moment your PLM implementation gets the information it needs), you can get very easily consolidated dashboards.
I think these 6 points justify the need for a centralized data. system. Of course you can extend that view to Project Quality (6-sigma), to Project Financial, to manage resource, to enter actual hours, have project templates... but that's another story.
Project management is a great entry point for a PLM approach. Because it involves everyone. Because you can limit the change and then the reluctance to change.
Yesterday, during a meeting with a customer, the representative had a very interesting question:
"What are the profiles do you recommend for my team in order to increase the success of an implementation?"
It's not often that a customer ask this kind of questions and I was more than happy to answer.
1 - The project manager
On the top of classical project manager skills, the project manager must know the company pretty well. It is key that the project manager has a global knowledge of the effect of a PLM implementation in his company. He must as well have a knowledge of the tool and not only high level.
Of course he does not know everything about everything, but he must have a clear understanding of the stakes and issues the user will face. This is one of the reason that I would not recommend someone from the IT department to take that role.
2 - IT
IT should be strongly involve in all discussions though. We need people who know the architecture of their enterprise and that will be able to understand our constrains. Honestly in my experience I have seldom been disappointed with IT at customers from the moment they understood what we are doing and why.
3 - Key Users
If the PLM implementation fails, often it is because the users don't use it.The rejection rate in PLM can be very high. Why? when there is a process in place, everybody finds good reasons not to respect it to go faster. with such a tool, you cannot anymore. The choice of the key user is then... key. They will champion the project to the users. So they need to be conviced that what we do and what they do is the right thing.
Rule #1: Never have key users from IT or from a department not affected by the implementation. They will never use the tool.
Rule #2: Never chose new people in the company. They don't know how you work.
Rule #3: Find the most old school and reluctant people in the department and make them your champion. You convince him. He will convince others.
Rule #4: Have technophiles in the team. People who would find the tool fun. Enthusiasm is important. On the long run that will pay.Tehy will exchange with the old schooled in a way they would have never done and will learn a lot. That will tend to reduce the generational gap.
Rule #5: Chose people who have natural leadership.
This might be very simple, but too often I have seen low commitment from the key users ("I don't have time", "This is crap, I don't want to do that", "Blah they put me in that room with you then I don't bother them anymore",...).
PS: Of course, for big implementation, you need to add some layer. You need to decompose the project in domains, then define key users by domains... etc... Maybe one day I will tell you how to prepare the change in the organization...
