People fix problems; they define problem statements, select and implement solutions, deploy PLM and other digital platforms. Talents are central to making decisions, designing solutions, leading and influencing stakeholders in improving business operations. Typical product development operations and PLM related activities include automation, solution architecture and tool implementations, configuration and administration, process design and adaptation / personalization, training, functional and change management, stakeholder managements and many other project, delivery and programme management activities, and many more. PLM talents balance technical and business skills, across an array of delivery and leadership roles.
In this post, I elaborate on core attributes, competencies, skills and roles required when selecting and implementing PLM solutions, from new solution selection, platform upgrade, data migration, business change, managing technology vendor relationships and implementation partner delivery, support and maintenance.
PLM projects are often described as “business-driven technology-enabled transformation” initiatives; they typically sit at the intersection of business operations, contributing to:
- Assert a level of alignment or “handshake” across functions and relevant stakeholders
- Improve how business functions operate, connect and collaborate
- Manage the required learning curve when deploying the new working practices
- Improve data continuity and integration across functions
- Rely on automation, IT tools and software to be more effective, across existing and new platforms
- Balance multiple advantages and constraints, compromising on process optimization, influenced (or not) by selected tools and technologies, infrastructure, cloud hosted services, configuration and customization requirements, with many other under-the-hood technical dependencies
Running such projects require the relevant attributes, competencies and stills: from business to industry, functional to technical, data to process, project management to change leadership. These skills must algin with the PLM scope and selected delivery model, spreading accordingly across the relevant roles: covering commercial / procurement, business process and technical delivery, support, education, IT, enterprise integration, etc.
- Competency: how one goes about work (knowledge and behaviors required to be successful at something)
- Skill: what one can do (specific abilities to perform)
- Role: what function is assumed, by whom (contextually)
Mapping roles and core attributes
The following table presents a sample mapping for typical PLM implementation roles and core attributes (non-exhaustive list). It highlights multiple perspectives and cross-functional expertise; roles are adjusted based on scope and selected delivery methodology.
|Business analyst / consultant||Requirement evaluation |
|Product owner / business relationship manager||Requirement / backlog prioritisation |
Metrics and business analytic design
Gap analysis and roadmap definition
Organizational change impact
|Commercial manager / buyer||Contract negotiation |
|Solution architect||Business to technical translation |
Functional and technical design
|System / infrastructure / enterprise architect||System and infrastructure design |
Physical data structures
|Technical SME / administrator / developer||Configuration |
Back-end and / or front-end coding
|Functional SME / process consultant / trainer||Functional qualification |
CAD / PDM / PLM applications
Training material development
Education / coaching
|Project manager / release manager||Planning |
Waterfall / agile / delivery models
|Scrum master / test manager||Coaching delivery teams |
Systems engineering / DevOps
Delivery quality assurance
|Database / system administrator||Database, middleware, disaster recovery, backup and restore, performance tuning…|
Clearly, some roles have overlapping competencies and skills and the above table is certainly too generic; some roles might not be project based but under the vendor or service provider umbrella. Moreover, actual role-based job expectation might differ from one organization to another.
For example, smaller projects will not have as many resources as per the roles listed above; people might wear multiple hats based on their abilities and bandwidth and that’s perfectly fine as soon as the delivery structure allows for sufficient governance and quality assurance.
Attracting the right talents
The required roles must be aligned to the project context:
- How to leverage existing talents and trusted resources across to the new PLM initiative?
- What are the “permanent” vs temporary roles, short- vs long-term, what relates to core competencies?
- What is insourced vs outsourced activities, including roles and responsibilities across suppliers to minimize duplication but also ensure the relevant quality assurance?
- What delivery model is to be implemented, from managed services vs project-based, waterfall vs agile?
- What commercial model is to be implemented, from fixed price deliverables to time and material?
- What levels of knowledge transfer will be required from supplier to internal resources, and what skills and competencies are to be retained internally?
Many attributes listed above are not specific to PLM and can be transferrable from other disciplines; it is also always good to consider what can be learned on the job, such as:
- A business consultant bringing industry and process expertise to a discovery project can be expected to learn on the job about a specific PLM tool as required during the project.
- A technical SME working on data migration is expected to bring tool and data mapping expertise, not necessarily specific industry process knowledge; this can be learned on the job, unless there are industry specific data characteristics unique to the project scope… Such knowledge can be acquired by working with process experts and functional SME.
In a subsequent post, I will discuss how talent requirements need be aligned to specific scope, delivery and sourcing strategies to enable PLM initiatives; and how SaaS offering might affect the PLM implementation roles.
What are your thoughts?
This post was originally published on Momentum-PLM on 20 October 2020.
Disclaimer: articles and thoughts published on v+d do not necessarily represent the views of the company, but solely the views or interpretations of the author(s); reviews, insights and mentions of publications, products, or services do neither constitute endorsement, nor recommendations for purchase or adoption.