The questions are valid, but in my view it is a very little part of a PLM project, and certainly not the ones to start with.
First: If you want to implement PLM, or re-implement for that matter, You now have a golden opportunity to evaluate your product development processes and Your business processes. You should look at what they are like, and then ask: Is this process really the best one for you or is it a creation of boundaries from earlier systems or constraints? If it still is a good one, well implement it. If it is not, now is the time to make it better or evaluate OOTB processes from a PLM vendor. A bad process will not get better if it is implemented in PLM, it might only get faster.
Second: It is crucial to map the information flow to your processes. What information is available in what process and at what time. Is this optimal? Would it be better if some information is available earlier or if some information could be deferred until a later stage? The last one could be the difference between creating and maintaining a vast number of product variants up front or maintaining a generic product definition to support Configure To Order.
Third: Having the best IT solution in the world with first class processes and superb data quality will not help you one bit if the organization is not ready to embrace it. This is why PLM is often described as a journey, and in my view, it is. There is no way an organization can fathom a full blown PLM system with processes in one go. That’s why organizational roll-out and gradual maturing and rollout is essential in my view. This is also why it is very important to have sufficient support from management.
Fourth: At last we come to what is very often debated too early, namely the selection of PLM tool and vendor. My advice is that you select a tool that is able to adapt to your changing processes, because they will change, that the vendor has the bandwidth to support You and that he understands your business.
Conclusion: In my view the success of any PLM implementation is hugely dependent on a healthy overlap between processes, information, organization and IT-tool.
In order for any organization to absorb and cope with the complexity it is useful to have a PLM strategy (think big). After the grand thoughts are defined then start small with clearly defined areas that can be tested and rolled out in the organization. Now you have tested the internal processes needed for defining, migrating and deploying parts of your PLM system, so the time has come to start to scale faster to achieve the PLM strategy. Will it ever be finished? Well not until your company is finished…..