In today’s article, our own CEO & Founder, Mark Harrop, shares his lengthy experience with PLM – more notably, the behind-the-scenes implementations and relationships that don’t always go as planned. Despite the huge strides PLM has made in recent years, it’s an unfortunate fact that PLM projects still fail. 

On the surface, the PLM market for retail, footwear, and apparel seems like one long success story. From humble beginnings, crossing over from the automotive and aerospace industries in the face of scepticism, RFA PLM has become big business. As analysts, every year we track hundreds of sales to new brands, retailers, and manufacturers, on every continent, who turn to PLM to solve their most pressing challenges: limited collaboration, siloed information, breaks in supply chain communication and transparency, squeezed margins, and delays in their products’ routes to market. Today, in late 2018, it’s rare for a week to go by without a vendor announcing a new customer agreement, or celebrating a go-live date – when a customer begins using their solution in earnest.

But success often comes with caveats, and in the case of RFA PLM, these can be serious. Because, while PLM projects succeed more often than not, the reality remains that not every deal made public reaches completion, and not every initial go-live translates into a sustainable, multi-year partnership between vendor and customer. And the cost of these breakdowns can be considerable.

Or to put it more frankly: for all the strides that RFA PLM has made in market penetration and baseline functionality, PLM projects still fail – more of them than you perhaps realise. What’s all the more frustrating, today’s failures are caused by the same issues that have undermined PLM projects for decades: inadequate preparation, miscommunication, false promises, and an outdated vendor mindset that prioritises inflated service, implementation and maintenance costs above all else.

And neither are these issues exclusive to small businesses. In fact, failed PLM projects are probably more prevalent among large, multinational brands and retailers – regardless of whether the vendor or the customer should shoulder the bulk of the blame. This is less surprising when you consider the scope and value of these kinds of projects (greater complexity creates more chances for things to go wrong) but their impact can still be transformative. A single failed deal can demolish a vendor’s financial performance for an entire year or more, and a broken partnership can easily destroy a customer’s faith in the entire PLM industry.

How do we know all this? WhichPLM is in something of a unique position, in that we are provided (under strict agreements that we have always adhered to) with customer names and numbers by all key PLM vendors, every year. From this information, coupled with our own independent research, we have produced yearly market analysis for the best part of a decade. And behind that analysis sits what I believe to be the industry’s most complete archive of PLM deals, partnerships, and implementations – dating back to 2010 and in some cases even further.

At the same time, we also enjoy close relationships with some of the world’s biggest brands, retailers, and manufacturing coordinators. From private label importers to household names in luxury, we keep in touch with PLM customers of all shapes and sizes before, during, and after their PLM projects. And while we usually hear good news – customer satisfaction remains at an all-time high in 2018 – we’re also given the truth with no varnish. That means we see the full impact of those projects that do fail, and we also get to understand why those failures happened in the first place.

Occasionally, our knowledge puts us in downright farcical situations, like meeting one vendor’s customer at another vendor’s event, or reading a glowing case study on a vendor’s website while our contacts within the same customer tell us the implementation stalled at the first hurdle and that relations between the two companies have completely broken down.

Almost every time we hear of a project failure, though, our knowledge leads to frustration. It hurts to see PLM projects fail because, as our objective PLM Evaluations support, PLM on the whole is functionally better than it’s ever been, and huge strides in SaaS and even multi-tenant cloud solutions, sold on an affordable subscription basis, have made it accessible to almost everyone.

So if the software itself is not to blame – at least not in a general sense – then what is? As independent observers, we can often see failures coming well before they reach a critical point, and as I mentioned, one or more of the same common warning signs are usually visible in every failed project. To help you avoid some of these pitfalls, I now want to analyse the most obvious reasons for PLM project failure, and provide some guidelines for how to avoid or overcome them – so your business does not end up as a sad footnote in our archives, at a potentially huge cost.

Poor cultural fit between vendor and customer:

By far the most common cause of PLM project failure, poor cultural fit is precisely what it sounds like: a mismatch between the priorities, methods, resources, and strategies of the two companies, customer and vendor, that make up a PLM partnership. A third party implementer or consultancy may also factor into the equation.

This might sound like a minor problem. After all, isn’t PLM just software? Does it matter if we’re all friends, and share a common vision? The answer is yes, because as WhichPLM has advocated time and time again, PLM is about much more than just the software. In successful projects, vendors and customers remain partners for years or even decades, working together to design new functionality, collaborating to onboard suppliers, handling new integrations at the API level, and so on.

Where that true partnership does not exist, breakdowns are almost bound to occur. Even a successful initial or first-phase implementation might come undone when customer and vendor priorities do not align in phase two, or where the parties disagree about the definition of best practices.

These issues can be avoided by thorough investigation, shortlisting, and demonstrations, as well as by reading independent PLM evaluations such as the series that WhichPLM has produced over the last three years. These include functional benchmarks of most key PLM solutions, updated annually, but also analysis of the broader business, allowing potential customers to get a better idea of whether their culture aligns with that of the shortlisted vendor(s).

Scope misalignment:

This might sound ridiculous to an outside observer, but even in the case of multi-million-dollar deals, vendors and customers don’t always agree about what their partnership actually entails. Far too often, we learn that a fledgling PLM project has broken down during implementation when it emerged that functionality, modules, or integrations the customer expected to be included in the agreed cost are actually to be billed for separately.

This misalignment can occur for various reasons. Sometimes it’s accidental, with customers being unclear about what they consider essential functionality or vendors not properly articulating the line between different modules. In other cases, this difference in scope arises from well-meaning promises made during demonstrations and negotiations that subsequently prove to be impractical, or cannot be delivered in time due to unforeseen circumstances.

Occasionally, though, scope misalignment is malicious in nature; a vendor will sign an agreement that the customer believes, in good faith, covers all essential functionality at no extra cost, only to then drop an additional statement of work on the customer’s desk once the phased implementation begins. At worst, vendors have knowingly signed these kinds of agreements and then used customers’ money to fund development of functionality the client believed was already part of the standard solution, and that was demonstrated as a non-functional series of mockup screens. To say WhichPLM does not condone this behaviour would be putting it mildly.

The solution to this issue is clear: customers must obtain cast-iron commitments from vendors that every module, integration, and function they expect to be present in the implemented solution will be included in the agreed project cost. By the same token, vendors must be entirely transparent around what functionality forms part of the current solution, and what is either undergoing active development or does not exist except in mockup form.

We know that all vendors are not equal in this respect (many are scrupulously honest) but equally, those vendors who have participated in this behaviour in the past are unlikely to police themselves in the future.

We also encourage any prospective customer of PLM to read our Evaluations, which contain detailed functional breakdowns, and which can reveal missing functionality.

Surplus services:

Alongside the software itself, PLM customers also contract with vendors (or their designated partners) to implement their solution, train end users in how to make the most of it, and provide other essential services. Just as with functional misunderstandings, though, the scope of these services is not always clearly defined, and implementation costs in particular can spiral out of control when cultural issues or matters of scope rear their heads.

There is no concrete rule for what constitutes an acceptable software to service ratio, but we know from first-hand accounts that it is not uncommon for customers to be hit with unexpected service quotes that exceed the cost of software licensing by a factor of ten or more.

This is obviously difficult for small businesses, who usually lack the budget for huge numbers of service days, but it’s especially problematic at the Tier 0 and Tier 1 level (the upper end of the market, by business size). Some vendors and their service partners see the larger deals as a carte blanche opportunity to bundle the software licenses with frankly extortionate amounts of consultancy and “administration” days.

As with the functional scope, customers and vendors should work together to clearly define the nature and the quantity of the services their implementation will require, and include a buffer for overruns and exceptional circumstances.

Usability:

One of the simplest questions when it comes to PLM projects often goes entirely unasked: will people actually use this functionality once it’s in place? Too often, customers and vendors either fail to consider the end user experience, or disregard the valid points made by product and sourcing teams. Or even when these concerns are taken into account, projects may fail to allocate the proper time, money, and resources for effective onboarding and training.

The result? A solution that goes unused, and key teams who create their own workarounds to avoid having to interact with something that they feel is making their lives more difficult, when it ought to be doing the opposite. Soon, when more data is being created outside the solution than inside it, the PLM initiative falters. And what’s worse, these end users now have an extremely negative perception of PLM – one that they will carry through to any proposed replacement project, and will port with them to future roles inside or outside the company.

To avoid this situation, PLM project teams (both customer and vendor) must factor the end user experience into their work. And equally, due consideration must be given to the way each shortlisted solution looks, feels, and behaves as it stands today. Many vendors have extensive UX overhauls in the pipeline, but this work will be extensive, so customers must be careful not to sign on the promise of a better experience being weeks or months away.

And again, WhichPLM’s Evaluations have graded many key PLM solutions on their usability over the course of the last three years.

Fit for the future:

As a long-term partnership, any PLM project must be forward-looking. Often, though, deals are signed because the customer needs a solution to immediate challenges, and does not take the time to consider how things may change in the future. Similarly, vendors will often prioritise immediate problems in their demonstrations; this is understandable, but nevertheless some will also be motivated to sign deals on the strength of their ability to solve pressing issues, knowing full-well that their solution will not provide what the customer needs in years to come.

The future of every business is unique, but to avoid this issue customers should ask themselves what direction their business is likely to evolve in over the next five years. If there’s a chance they may introduce new product categories, they should ensure that their chosen solution supports these new business units without extensive customisation and additional cost. If they are considering 3D, they should evaluate every shortlisted vendor’s ability to handle the widest possible range of 3D formats in a meaningful way. And in a general sense, customers should exercise due diligence in ensuring that the solution they select (and the vendor who provides it) has the ability to scale.