Independent of the toolset, technology, scope, scale or type of product lifecycle management (PLM), one of the first considerations when embarking on such an implementation initiative is to create a credible “PLM roadmap.” Such a roadmap aims to translate the vision and strategy into inter-dependent building blocks to inform stakeholders about implementation phases, including critical transition steps and dependencies.
Roadmaps are evolving artifacts that must be maintained throughout the initiatives that they underpin, based on how the implementation progresses and how well the business can adapt. Typically, a roadmap is designed to show different aspects of the change initiative at different stages of its lifecycle:
- From inception, the roadmap describes the strategic “big picture” plan to reach expected goals and achieve the desired outcome (including unknowns and gaps); it is initially informed by the business case and articulates the “why” between goals and the plan for getting there.
- As projects initiate and progress toward these goals, the roadmap provides more information about the current and next steps—always keeping in sight the overall objective(s); the roadmap is not only a simplified plan or a “plan on a page,” but also a schematic with building blocks used for communication purposes such as:
- Reporting on project status at a steering committee with business executives and sponsors
- Informing and mobilizing business communities on a project’s progress and describing how they engage in certain activities
- Tracking high-level activities, priorities and dependencies to help manage delivery governance with implementation teams
- The roadmap can be derived in different views based on the target audience, providing the relevant perspectives at a given time and to a given stakeholder group, such as:
- A business view: training, user testing involvement, data cleansing requirements, business change activities
- An IT/technical view: capability development iterations, interfaces, data cleansing, migration activities, cut-over building blocks, etc.
Prerequisites to Building an Effective PLM Roadmap
The first critical element to consider when building a PLM roadmap is to assess what the organization means by “PLM” and the target scope; getting clarity and a consensus on this as early as possible will help with subsequent implementation and avoid distractions from buzzwords and other perceptions. Also, PLM is likely to have a different “flavor” based on the vendor, so aligning on the organizational language for PLM (or whatever you call it) is therefore critical.
This doubles with aligning to the organizational culture and “how things get done around here”: understanding how decisions are made, how risks and issues are managed, what executive governance is required, what the escalation process is, etc.
Identifying key stakeholder groups, business capabilities, data and technical/application landscape will help define contextual dependencies. Linking these to business imperatives and technical constraints will then help define the basic building blocks based on change maturity:
- What business functions and capabilities are in scope, and how do they perform today vs how will they be expected to perform tomorrow? (Typical improvement value statements from the business case.)
- Is the PLM scope part of a wider business transformation scope?
- Are the high-level use cases documented per the scope?
- What initial studies are required to validate technical assumptions?
- What are the critical changes about: people, skills, process, tools, infrastructure, clients?
- Are technical dependencies understood?
- Is the data scope understood and agreed upon with the business?
- How much change is the business willing to accept, and during which period of time?
- Is this quantified with evidence from past project lessons learned and executive commitment to change?
- What functions will be impacted by the change and will it require organizational change to support the new operating model?
- What support will be required to enable the change?
- Is the vendor onboard to support technical and commercial elements of the roadmap?
- Will a system integrator be required?
- How will the organization engage with third parties, and what is the procurement process? (And how long is it likely to take?)
First Building Blocks: Assess Business Capabilities
PLM implementation roadmaps can be daunting if the language is not aligned. Once this is understood, the first building blocks must be business centric:
- Why are we doing this?
- What went right and wrong in previous decisions and initiatives?
- Who are the key business capabilities and are they in scope for improvement or deployment (independent of the technology, existing or new platforms, etc.)?
- What is the application landscape and high-level data feeds between the multiple data sources?
- Where is data mastered and how does it align to business owners, broadly speaking?
- What are the movable and immovable parameters or constraints, and what is the rationale for them?
- How do these parameters link to the business case, cost and risk elements?
- Is the future platform selected, and how does it align to the above?
- If the future platform is yet to be selected, what requirement should it align to, based on the above considerations? What analysis is required to validate this and how will it be possible, etc.?
- How will the business operations be expected to change, and how will business risk be mitigated during the transition?
The above list of considerations is not exhaustive. The expected outcome is to assess the building blocks to get started with defining the PLM roadmap and the underlying assumptions that require further assessment during the implementation. The roadmap is designed to focus on the strategic steps to cover how these building blocks are interconnected, with an initial view of how they might interlock, what are the prerequisites, what can be parallelized, etc.
Technical, Integration and Data Dependencies
Roadmaps are business driven, yet many building blocks will have technical and data dependencies. The next steps include overlaying technical assumptions to the roadmap in order to map technical capabilities to the expected business outcomes:
- What functional capabilities and apps will be required to support the business capabilities?
- How will the above map to the existing and new software portfolio?
- What technical assumptions will need to be validated and how?
- How will these functionalities be “designed in context” and built, in terms of configuration and customization? (This will later inform on the required skills, build and test efforts, and activity duration for the detailed plan to carry forward in due time.)
- Similarly, what will be the technical integration and data migration requirements?
- What assumptions will drive business, process and technology changes?
Data cleansing and archiving is often a point that is underestimated when building PLM roadmaps. It is often naively assumed that the business will cleanse legacy data when needed or be able to identify what data to migrate and what to archive (i.e., not migrate) when transitioning from one platform to another, or from one process to another. The PLM roadmap must include how these aspects will be addressed, in the context of other business and technical dependencies.
Deployment Phases and Transition
Independent of complexity, most PLM roadmaps are multiphase initiatives. This helps to mitigate risk and “experiment” by running the relevant proof of concepts or limited pilot activities/initial foundation sprints. Such experimentations must cover education, data migration, cutover planning principles and business implications—and include post-deployment hyper-care support activities and service transition to business as usual, such as:
- How is the solution expected to be built and rolled out to the business?
- What analysis will be required, and when? (In what sequence and with what prerequisites?)
- What decisions and support activities will be expected by the business, and when?
- What are the key milestones for each phase (waterfall milestones or sprint/agile release iterations)?
- Are these phases sequential or can elements run in parallel (for economies of scope, common infrastructure, or based on long lead time activities)?
It is important to define these principles as early as possible and highlight the required impact assessments into the PLM roadmap, including how they will be validated and help clarify dependencies between the different building blocks. PLM roadmaps and business cases often go hand in hand as the process of defining one helps inform the other, while understanding a number of requirements for selecting a digital platform vendor or an implementation partner.
The PLM implementation roadmap will not include each and every consideration mentioned above at all times. On the one hand, all elements are expected to be addressed at some point and covered in the detailed implementation plan. On the other hand, the PLM roadmap needs to look at the big picture, help communicate about the strategy and “make it real” for every stakeholder group—often before the initiative formally kicksoff. It must also include dependencies to external tools and technologies/platform roadmap from the selected vendor(s). The roadmap does not bring all answers but lays the foundation for effective delivery now or later when the project(s) start(s).
Roadmaps are especially important with PLM-related initiatives as they tend to have lengthy discovery journeys… sometimes reaching far beyond completing the initial discovery activities.