Who owns PLM implementation project?

plm-implementation-ownershipI’m coming with new discussion related to how we can successfully implement Product Lifecycle Management. I think, this issue is as important as to have good PLM technologies and ready to use functions in a product.

However, I see PLM-related implementation project uniqueness in the following factors:

1. Cross Functional. Large diversity of people and process involved into implementation. Traditionally PLM-related activity is spanning across multiple domains in organization, which position PLM influences a significant range of operational activities.

2. R&D involved. PLM is heavy impacted by R&D and Engineering activity of organization. Engineering and Product development work is unique in the way people see how they work and from a standpoint how they want to see computer systems manage their work.

3. Tools. Large diversity of software tools and providers involved. In very rare situation company uses single vendor solution for their development practices. The reasons are many historical, product development needs, acquisitions and mergers etc. As a result corporate IT zoo for PLM implementation may be easy include several dozens of tools and components.

With this specifics how I can see a possible PLM implementation project from ownerships standpoint.

1. Corporate Ownership. The corporate ownership absolutely must have successful PLM implementations. The leader of PLM implementation should have enough power, leadership and knowledge to harmonize diverse number of stakeholders involved into implementation.

2. Service Provider Ownership.
This is very typical situation for most of PLM implementation. Additional company (in many cases can represent major vendor for this customer), is taking overall responsibilities about implementation. Were advantages are clear, the disadvantages are practically the same lock and high dependence on such service provider, ability of service provider to work with a significant number of player in the same organization in parallel.

3. PLM Consultancy. There is situation when company decided to hire PLM consultant for planning and leading of PLM implementation. This PLM consultant needs to work with corp. resources and diverse teams to lead them toward PLM implementation. Such PLM consultant can also cooperate with Service Providers to do some additional work.

What is my conclusion so far? To have strong PLM project ownership and leadership is absolutely needed to PLM implementation. There is no single recipe how to implement PLM, company needs to work on their own plan and vision for PLM implementation. Diversity of vendors and tools provide an additional complexity in PLM implementations.

These are my thoughts…What do you think about that?

Best, Oleg.


Share This Post

  • I think you pointed out right things. PLM Implementation is like portfolio management. You have a high level implementation like a portfolio, then you have programs and projects and for every thing, there is a project. I personally think that PLM Implementation should be driven together by a small team of functional representatives from R & D Engineering, Manufacturing and other agencies and IT. IT is enabler only. Rest recipe should be prepared at functional level and given to IT for final physical implementation. I think most of the implementation fail or elongate due to wavelength mismatch within team. IT guys are in hurry to implement it technically and functional come with updates. it need to be managed at initial stage.

  • Stan Przybylinski

    If an implementation project is not sponsored at a high enough level, and owned INTERNALLY, it is likely to fail. Letting outsiders own organizational change makes it much easier for insiders to opt out of really participating in the changes, and provides an easy “scapegoat” should things go bad.

    That is not to say that you cannot give outsiders key roles. This is crucially important, because more companies do not have the necessary skills in-house.

  • Ashish, I think idea of organization built on IT +additional functional team is very good one. In successful implementations I’ve seen, this is was way to go. Thanks for your comments! Best, Oleg

  • Stan, you are right. To have internal ownership (is what we call sponsorship) is important. The question how it will be balanced with rest of organization and external people that have skills. In my view this is a very complex combination that in many cases lead to failure. My thoughts… Oleg

  • Lenny Grosh

    It is very simple. The business process owners have to own the PLM Implementation Project. It can not be IT because they do not own the processes. It can not be engineering only because of the cross-functional areas who touch a item through the ‘lifecycle’. So, you need a corporate sponsor, a project manager and functional area leaders working together to define the ‘lifecycle’ process for your company. This should be followed by enabling these processes into the correct PLM software package.

  • Lenny, thanks! The most successful implementation I’ve seen were made in configuration similar to what you explained. If you are lucky to have “engineering plus” sponsor, you will be on the right spot… However, one of the biggest challenge is to expand PLM beyond engineering services. There are a lot of resistance coming from organization and process owners… Best Regards, Oleg

  • Obviously, the “ownership” depends on the scope of the PLM implementation and benefits the enterprise is trying to achieve. Talking about a global PLM implementation vs a glorified PDM implementation to manage CAD files in a design center have very different ownership requirements and sponsorship structures. Looking at the more complex side, it is important to set expectations from the beginning that global full-blown PLM implementation is a journey, not an event. The keys to a successful journey in my humble opinion are:
    1 – Establishing and engaging the appropriate steering committee (SC). The SC owns the implementation and must be include senior representation from all affected functions and geographies from the beginning. Get them involved and responsible early. Don’t be afraid to raise tough issues, particularly organization change issues, and get them to take ownership. Develop meaningful metrics and scorecards to track progress.

    2 – Get as many folks involved as possible. The tendency is to have small groups drive the projects and represent users but their perspective and scope is usually limited. Get input and consequently ownership from as many users, managers, executives as possible. If orchestrated correctly, these are your true owners.

    3 – Organize to manage change. Every successful PLM implementation I have ever seen had one thing in common. They got many things wrong to start and had to change. This is not bad. People learn as they go and the true power takes time to be absorbed regardless of how many slick presentations, demos and consultants you use. If you are on a “journey” new elements coming in later will drive changes to existing elements to enable 1+1=3 type benefits. Organize your teams, projects, steering committee and particularly your IT component to be able to effectively manage changes to existing functionality and software upgrades….thanks for listening, Alan

  • Colin Bull

    I have to agree with Lenny and Alans comments. PLM cannot be just for engineering to store their CAD documents, “PDM on steroids”. It certainly is not an IT project, IT know nothing about the business processes involved with R&D NPI MRO and the lifecycle of the products or assets that the business develops.

    The most succesfull projects that I have been involved with, have an executive sponsor that wants to change the business. This coupled with a good cross functional implementation team comprising of high level management to guide and very capable engineers of all disiplines and department, driving the changes in the organisation to there collegues and peers.

  • Allan, I liked your bucket, especially one about change. I’d improve it by saying, it’s important to support ability of the system (and organization) to make short step toward wider PLM implementation. If you can easy manage change and cost of change is low in your system, overall PLM implementation have a very good chance to be successful. – Regards, Oleg.

  • Colin, thank you for your comment! Yes, from my experience, if you have executive sponsor interested to change business with PLM, you will be very successful. But, this is not a general case in my view. Regards, Oleg

  • Jim Jones

    This blog was very interesting reading since I am leading the definition and implementation of PLM in my current organization.

    I am an executive director who reports to a CTO who in turn reports to the CEO/owner. I can tell you that the amount of resistance is significant and so is the politics. No only do you need strong executive sponsorship but you also need direct leadership.

    I have established a steering team as mentioned, however I must
    say that involvement is poor. It is difficult for the division leaders to get involved. I think it is a important part of communications but
    don’t expect it to be a decision making forum.

    Also, the teams I have constructed is composed of representatives
    from various parts of the organization. Yes, the team is heavily
    engineering, and I must say that I wish the business side was more involved. It is critical to have consultants if your company’s experience in process engineering or enterprise architecture is low. I have consultants sitting side by side with my employees.

    Although I agree that PLM is not an IT lead project, however I also
    believe that the task is equally divided between process engineering and IT. I recommend that initially it be lead by the process teams supported by IT and then vice-versa moving into the development phase. I have found that the process team dreams too much and the IT team is negative about changing anything. The key is to determine a pragmatic balance in the middle.

    I must say that I found the comment about the scope of the project
    not only poignant but entertaining. Whether it is a gobal or company wide activity or just glorified CAD management has to be established from the beginning. If there is any gap between the understanding of the team and the sr. executives, you will have serious issues.

    We just had a milestone 2 review today. It defined the processes
    and enterprise architecture definitions for the systems we plan on
    developing and implementing. It was a long and grueling review,
    but successful. Next we are bringing in the system integrators to complete specific software requirements, then on to actually development and testing. We are all concerned about the migration plan, so a completely seperate sever systems that duplicate the current system was created. I would highly recommend this to mitigate risks.

    Wish me luck!

  • Jim Jones

    Look forward to any replies.

  • Jim, thanks for your comments – wish you good luck in your projects. IT / PLM projects are extremely complicated, involving lots of politics and exec decisions. I agree with your points. Most of vendors and companies are trying to set up so-called phased approach to move between implementation projects. It makes sense, however, requires internal leadership and sponsorships… Best, Oleg