It’s the beginning of the year. Companies are starting new initiatives, and one of them is potentially the next PLM-project. There is a common understanding that implementing PLM requires a business case with ROI and measurable results. Let me explain why this understanding is a myth and requires a myth.

I was triggered by a re-post from Lionel Grealou, titled: Defining the PLM Business Case.  Knowing Lionel is quite active in PLM and digital transformation, I was a little surprised by the content of the post. Then I noticed the post was from January 2015, already 5 years old. Clearly, the world has changed (perhaps the leadership has not changed).

So I took this post as a starting point to make my case.

In 2015, we were in the early days of digital transformation. Many PLM-projects were considered as traditional linear projects. There is the AS-IS situation, there is the TO-BE situation. Next, we know the  (linear) path to the solution and we can describe the project and its expected benefits.

It works if you understand and measure exactly the AS-IS situation and know almost entirely the TO-BE situation (misperception #1).

However,  implementing PLM is not about installing a new transactional system. PLM implementations deal with changing ways-of-working and therefore implementing PLM takes time as it is not just a switch of systems. Lionel was addressing this point:

“The inherent risks associated with any long term business benefit driven projects include the capability of the organization to maintain a valid business case with a benefit realization forecast that remains above the initial baseline. The more rework is required or if the program delivery slips, the more the business case gets eroded and the longer the payback period.”

Interestingly here is the mentioning “..the business case gets eroded” – this is most of the time the case. Lionel proposes to track business benefits. Also, he mentions the justification of the PLM-project could be done by considering PLM as a business transformation tool (misperception #2) or a way to mitigate risk,s due to unsupported IT-solutions (misperception #3).

Let’s dive into these misperceptions

#1 Compare the TO-BE and the AS-IS situation

Two points here.

  1. Does your company measure the AS-IS situation? Do you know how your company performs when it comes to PLM related processes? The percentage of time spent by engineers for searching for data has been investigated – however, PLM goes beyond engineering. What about product management, marketing, manufacturing, and service?  Typical performance indicators mentioned are:
    • Time To Market (can you measure?)
    • Developing the right product – better market responsiveness (can you measure?)
    • Multidisciplinary collaboration (can you measure?)
  2. Do you know the exact TO-BE situation? In particular, when you implement PLM, it is likely to be in the scope of a digital transformation. If you implement to automate and consolidate existing processes, you might be able to calculate the expected benefits. However, you do not want to freeze your organization’s processes. You need to implement a reliable product data infrastructure that allows you to enhance, change, or add new processes when required. In particular, for PLM, digital transformation does not have a clear target picture and scope yet. We are all learning.

#2 PLM is a business transformation tool

Imagine you install the best product innovation platform relevant for your business and selected by your favorite consultancy firm. It might be a serious investment; however, we are talking about the future of the company, and the future is in digital platforms. So nothing can go wrong now.

Does this read like a joke? Yes, it is, however, this is how many companies have justified their PLM investment. First, they select the best tool (according to their criteria, according to their perception), and then business transformation can start. Later in time, the implementation might not be so successful; the vendor and/or implementer will be blamed. Read: The PLM blame game

When you go to PLM conferences, you will often hear the same mantras: Have a vision, Have C-level sponsoring/involved, No Big Bang, it is a business project, not an IT-project, and more. And vendor-sponsored sessions always talk about amazing fast implementations (or did they mean installing the POC ?)

However, most of the time, C-level approves the budget without understanding the full implications (expecting the tool will do the work); business is too busy or does not get enough allocated time to supporting implementation (expecting the tool will do the work). So often the PLM-project becomes an IT-project executed mainly by the cheapest implementation partner (expecting the tool will do the work). Again this is not a joke!

A business transformation can only be successful if you agree on a vision and a learning path. The learning path will expose the fact that future value streams require horizontal thinking and reallocation of responsibilities – breaking the silos, creating streams.

Small teams can demonstrate these benefits without disrupting the current organization. However, over time the new ways of working should become the standard, therefore requiring different types of skills (people), different ways of working (different KPIs and P&L for departments), and ultimate different tools.

As mentioned before, many PLM-projects start from the tools – a guarantee for discomfort and/or failure.

#3 – mitigate risks due to unsupported IT-solutions

Often PLM projects are started because the legacy environment becomes outdated. Either because the hardware infrastructure is no longer supported/affordable or the software code dependencies on the latest operating systems are no longer guaranteed.

A typical approach to solve this is a big-bang project – the new PLM system needs to contain all the old data and meanwhile, to justify the project, the new PLM system needs to bring additional business value. The latter part is most of the time not difficult to identify as traditional PLM implementations most of the time were in reality, cPDM environments with a focus on engineering only.

However, the legacy migration can have such a significant impact on the new PLM-system that it destroys the potential for the future. I wrote about this issue in The PLM Migration Dilemma

How to approach PLM ROI?

A PLM-project never will get a budget or approval from the board when there is no financial business case. Building the right financial business case for PLM is a skill that is often overlooked. During the upcoming PI PLMx London conference (3 – 4 February), I will moderate a Focus Group where we will discuss how to get PLM on the Exec’s agenda.

Two of my main experiences:

  • Connect your PLM-project to the business strategy. As mentioned before, isolated PLM fails most of the time because business transformation, organizational change and the targeted outcome are not included. If PLM is not linked to an actual business strategy, it will be considered as a costly IT-project with all its bad connotations. Have a look at my older post: PLM, ROI and disappearing jobs
  • Create a Myth. Perhaps the word Myth is exaggerated – it is about an understandable vision. Myth connects nicely to the observations from behavioral experts that our brain does not decide on numbers but by emotion. Big decisions and big themes in the world or in a company need a myth: “Make our company great again” could be the tagline. In such a case people get aligned without a deep understanding of what is the impact or business case; the myth will do the work – no need for a detailed business case. A typical human behavior, see also my post: PLM as a myth.

Conclusion

There should never be a business case uniquely for PLM – it should always be in the context of a business strategy requiring new ways of working and new tools. In business, we believe that having a solid business case is the foundation for success. Sometimes an overwhelming set of details and numbers can give the impression that the business case is solid.  Consultancy firms are experts in this area to build a business case based on emotion. They know how to combine numbers with a myth. Therefore look at their approach – don’t be too technical / too financial. If the myth will hold, at the end depends on the people and organization, not on the investments in tools and services.