The Little Black Book of PLM
Lionel Grealou posted on June 30, 2020 |
A little reference for PLM you can carry around with you. How can you get one?

A little black book is a pocket directory of whatever is of interest. It often includes a useful strategy checklist, implementation guidelines, hints and tips of what works and what does not, reference contacts, etc. Just imagine if there was such thing for PLM: a repeatable framework to implement operational improvements; an overarching “guiding framework” for digital transformation, initial platform agnostics and platform-specific when required; and a holistic framework to follow with all mandatory and optional steps to initiate, design, build, test and deploy PLM. Now, that sounds handy. How can you get one?

You can’t. It doesn’t exist. Let’s explore why.

Many Questions, But No Magic Recipe

Considering “how to get up the PLM maturity ladder” typically brings many questions from engineers, mid-level managers and executives, such considerations usually cover a range of questions which can be simplistically summarized in nine themes in no particular order:

  1. What does PLM mean for the organization, and how “mature” is the organization with its understanding and use of PLM and related solutions? How does PLM fit in the wider enterprise digital landscape? This is often an emotional question.
  2. What process-based “best practices” and platform-specific principles need to be considered when selecting, implementing and using a PLM platform? This relates to the product development use cases, such as where to find and how-to re-use them.
  3. What technical, system and implementation-based “best practices” are required to ensure PLM success? Do they exist or apply to the organizational context? This again includes where to find and how-to re-use them.
  4. More technically, should a cloud-based or hybrid infrastructure architecture be selected? Are PLM SaaS platforms mature enough to integrate PLM to the wider digital thread?
  5. What is the most commonly used platform in a given industry? How does the organization benchmark compare with industry standards and among high performers? Also, why is that different?
  6. How much change and learning will be required to embark on a fully integrated digital transformation across the PLM process and platform landscape?
  7. Should the organization engage with the vendor directly and/or appoint a system integrator to own the full end-to-end solution delivery? Alternatively, should the organization lead the solution or engage external support differently? What are the possible engagement models?
  8. What access, performance and usability can the PLM platform deliver, and how do PLM vendors compare? This includes questions about the visualization of large data sets and supply chain integration topics.
  9. How should the organization get started and internal stakeholder buy-in and budget approvals, as well as create a credible digital transformation roadmap and select and adopt the deployment framework that will answer the above questions and, in turn, enable PLM success?

If PLM was a repeatable process or clear IT system, there would be many generic clues as to how to answer the above questions. Moreover, if these clues were consistent and consensual, they would constitute one step forward toward PLM clarity.

Value Frameworks: From Discoveries to Strategic Initiatives

The above questions are not unique to PLM. They apply to all disciplines—(ERP, MES, CRM, etc.—and digital platform selection, upgrade, replacement or integration. The fact that makes them more relevant for PLM is that there is no widely available framework for PLM platform implementation. Elements of such frameworks exist in the form of “little black books” that vendors and system integrators use to sell and sometimes implement their solutions.

Every digital platform vendor has developed its “value creation” framework to help clients select and implement their solutions.

  • SAP used to have the ASAP methodology—namely Accelerate SAP, which was later rebranded SAP Activate. It appears to be one of the most comprehensive implementation frameworks as pretty much everything has been templatized.
  • PTC has its Value Roadmap, including one specifically for the Internet of Things (IoT) to guide OEMs as they prioritize business use cases and help them measure current operations versus expected improvements.
  • Dassault Systèmes developed its Value Engagement Model as a consulting tool to scope business value and define implementation roadmaps.
  • Siemens created the Catalyst framework to help narrow the value gap between current and future operations. It is another useful approach to help define the business case and guide organizations toward an effective implementation start.

Consulting organizations also have proprietary toolkits that often build upon the above vendor frameworks. They have the same goal: define and maximize return on investment and accelerate value realization from PLM. Two core criteria to consider are:

  1. Business value – The difference between current and future operations, and value gaps, the difference between how technology is used now versus how it could be used more effectively.
  2. Time to benefit realization – This is based on complexity, pre-requisites, dependencies, etc.

The former is fairly straightforward to define upfront, though it requires ongoing maintenance and revision. The latter is more difficult to maintain as it requires applying the organization’s contextual experience with the selected platform and technology implementation.

Unlocking PLM Secrets

Even if there is no guaranty of success, dealing with change can be structured and embedded into a consistent delivery framework. That applies not only to the front-end piece of work to define the art of the possible but also to the “sell” needed for a business’s digital transformation. PLM sits at the intersection of many disciplines that potentially have their own secret sauce. Of course, for each category, there are multiple recipes to cook it.

The table below lists a number of things to watch that every organization embarking or running a PLM initiative would want their trusted consultant to bring in their little black book.

The little black book of PLM

(sample content)


Things to watch for…


  • Experiment before you commit to a platform.
  • Start small and focus on doing one thing well before scaling. Avoid “boiling the ocean” with the PLM scope.
  • Define clear commit stages and exit criteria.
  • Ensure contractual boundaries are flexible enough to allow for experimentation and adjustment.
  • Check references: get external and independent feedback.
  • Consider services from competent niche players rather than only buying from the big brands.
  • Ensure you get the A team.
  • Focus on trust and ability to learn rather than existing rigid knowledge.

Education / HR

  • Engage early, which will help look at cultural factors, barriers.
  • Define clear rules of engagement.
  • Focus on business change, i.e. the delta learning.
  • Focus on value delivery and not process. Avoid trying to fix the whole organization at the same time.

Solution architecture

  • Define early principles. Do not compromise on them, even if it means stopping or pausing the project to assess deviations.
  • Ensure the technical architects get their hands dirty. Speak the relevant technology language and walk the talk.
  • Keep it simple when it comes to personalization.
  • Make rapid decisions and revert them quickly if needed.
  • Understand how to handle bugs versus enhancement requests.
  • Test the vendor and system integrator relationship through scenario planning beyond the RACI.

System architecture

  • Consider all infrastructure options, including cloud-based and SaaS.
  • Understand security aspects of the above.
  • Assess integration bottleneck in the wider digital thread landscape, e.g. ERP interface.
  • Review customization need against each storyboard or use case.


  • Aim for big digital transformation ROI with “room for milk” as things change.
  • Do not only consider resource or process efficiency. Include cost avoidance, the cost of doing nothing.
  • Start small but always maintain a simple business case and roadmap that goes beyond PLM into ERP, etc.
  • Exclude sunk costs from the business case.

Business change

  • Do not accept a process best practice if you do not agree with it.
  • Focus on business change activities that add value and can translate immediately to action.
  • Avoid theoretical frameworks as they never get used.
  • Don’t spend months defining a communication plan. Communicate with simple yet clear informative messages—balancing technical and delivery status.
  • Define operational metrics and quantify the current pain points as reference points.

Stakeholder management

  • Include supporters and detractors in the business change workgroup.
  • Do not use a static key user group for everything.
  • Consult and includes internal customers of each end-user group, e.g. manufacturing and service engineers use product engineering data although they are not the primary users.


  • Profile legacy data and assess quality during the initial discovery.
  • Be clear on how to address data migration, versus archiving, scope.
  • Prioritize data-driven rather than process-change-driven decisions. People can learn a new process but dirty released data can’t be changed.
  • Don’t expect that the business will suddenly cleanse released data it did not create to quality standards in the first place.
  • Deploy in stages instead of big bang deployment unless it was used as a basic repository only.
  • Start with out-of-the-box data migration and interfaces Iterate them TO BE processes as they mature.

Delivery management

  • Focus on business value for all decisions, even for IT decisions.
  • Keep the plan under control by using and updating the plan weekly.
  • Maintain the PLM roadmap throughout and immediately highlight deviation.
  • Build credible governance with a supportive steering committee where you can openly ask for help.
  • Hire an independent business and technical savvy program lead. PLM is not an IT project.

Perhaps contrary to common thinking, there is no “black magic” with implementing successful PLM. Only common sense and experience prevail. There is no single black book that would cover the above, non-exhaustive guidelines. One key to success is to ensure that the core delivery team can together bring the relevant holistic experiences and trusted relationships that PLM initiatives require.

Recommended For You