By definition, a project has a defined start and end, clear objectives and scope, and finite budget – which can be managed as part of a portfolio or/and under a program umbrella.
Product Life-cycle Management (PLM) projects are not different from other (business change IT-enabled) projects; they typically include requirement capture, process definition, tool installation, solution, data model and system architecture, and functional configuration and customization, testing and validation, tool integration, legacy data migration, user education, organizational change management, product selection, project management, change management, stakeholder management, dependencies, risks and issues management, deployment planning, operational acceptance, etc.
25% of PLM initiatives are structured as programs or large projects as they typically require multi-year multi-stakeholder engagement, and they can be fairly complex.
60% of PLM initiatives are regrouped in a portfolio of business and IT improvement projects.
Project or program management typically represents 20% of the PLM implementation cost – excluding software and BaU cost… Not recognizing upfront the importance of project management can lead to increased costs (or business dis-benefits) downstream…
Programs or project portfolios deliver better results (in business benefit terms and from a business adoption perspective) if they are supported by a dedicated PMO structure and third party delivery assurance partner – typically representing no more than 5% of the PLM implementation cost (on large initiatives or large number of smaller initiatives).
80% of large PLM implementation initiatives are following a new PLM toolset and vendor selection project.
40% of PLM initiatives ‘leave’ integration and data migration requirement definition and implementation to the last minute.
50-60% of the challenges with PLM implementations relate to deployment, transition planning, integration and data migration (often hoping that “somebody in IT will figure it out later on”).
Generally, ‘big bang’ deployments do not exist from a technical standpoint with (complex) PLM initiatives – though it is possible to make it look like that to the end users with adequate preparation and planning.
25% of PLM initiatives end-up being IT tool replacement projects.
20% of the PLM implementation cost is typically spent for solution design, proof-of-concept (POC), solution architecture definition and blueprinting.
60-70% of the (prioritized) POCs should be realized upfront as part of the early design activities (some are also typically performed during the tool selection process to validate the decision).
Testing and user validation of the PLM solution can require as much effort and iterations as designing and building the technical solution itself.
IT implementation activities typically represent 30-40% of the implementation efforts of PLM projects.
Appointing a PLM system integrator does not mean assigning the overall implementation scope, workload and budget to a single party.
Selecting a system integrator should not be only about technical or IT skills, but rather focusing on technical management and business change management competences.
Most system / tool build activities should be performed offshore (in low cost countries where technical resources can be rapidly ramped-up and scaled) using a build factorymodel coordinated by a local delivery interface.
PLM initiatives require strong multi-vendor management – which can also be outsourced to a specific vendor.
Business benefits from PLM initiatives are more important than IT benefits or cost avoidance; software change costs might be considered as an investment (cost of the first acquisition, above and beyond the recurring cost of ownership, aka maintenance and support).
Business benefits are typically realized months or sometimes years after the PLM project is deployed – hence, they must be tracked rigorously after deployment and beyond the life-cycle of a given PLM implementation.
Tactical quick-wins deployments are important to establish and maintain the momentum, allow for familiarization with the new solution and selected technology, realize early benefits, confirm the ‘investment’ in change and keep stakeholders engaged.
Engineers and Project Managers have different interests (…).
Business transformation and business improvement teams should compete and align their priorities, though operate in a customer-supplier context so that proper hand-overs are done after PLM deployments.
Cultural factors must be considered from the initial stage as well as at every stage when implementing PLM to ensure that the expected benefits will be realized – as better processes and better tools might not suffice (pending adoption and change resistance challenges).
PLM transformation projects do not equate to a series of small business improvement projects.
Lessons learned should be captured and used at every possible stage of the PLM implementation (not just at the end after the deployment is complete).
The above facts are experience-based and non-exhaustive, they might be a bit approximate or perhaps subjective; and are opened for discussion 🙂
What are your thoughts?
This post was originally published on LinkedIn on 15 February 2015.
About the Author
