Fellow blogger Andreas Lindenthal recently highlighted a rather sobering point.  Analyzing Product Lifecycle Management (PLM) implementations at clients over the last ten years, he attempted to measure the difference in deployed capability versus available capability.  His conclusion:

“Most companies do not use much more today than what was available 20 years ago.”

Ouch.

While the issue here is highlighted specifically in a PLM context, the problem is characteristic of all major enterprise software platforms ranging from Enterprise Resource Planning (ERP) to Business Process Management (BPM).  However it seems to particularly sting with PLM.  Andreas goes on to rightly explain that there’s a huge opportunity loss.  But if everyone’s just blatantly staring at untapped value in the face there has to be a compelling reason why.

Some observant types reason that overlapping capability with other systems (notably ERP and CRM) creates barriers to adoption.   So a PLM system ends up being used for its perceived strengths, which traditionally lie in the core Product Data Management (PDM) functionalities.  In many cases the overlapping platforms are entrenched across departmental or functional boundaries.  Very rarely is there one system to rule them all.

While competition from overlapping systems is true to an extent, a substantial portion of the untapped value tends not to be in another enterprise platform, but rather in legacy systems, Excel spreadsheets, Dropbox, and (hold your breath) reams upon reams of flattened tree slices (paper).

Now the opportunity loss seems particularly egregious… so there has to be a simpler explanation for not using all that untapped capability.  There is:  it’s simply too hard to make incremental progress.

The wisdom from thought leaders is accurate: PLM is a journey.  Should be, anyway.  But sadly in practice, often PLM ends up as a one shot effort – a flash in the pan.  Most of the achieved capability comes from the first strike, when all attention is turned toward the revolution.  Teams are energized and primed, consultants are everywhere, management support is focused and money flows like a fountain.  Every project has a roadmap, but as priorities change, budgets are reallocated, and business objectives transform, team longevity fades.

You could pay consultants to come in and work a quick miracle, but even the meatiest organizations have only so much money for that.  Smaller companies have even less.  Regardless of Return on Investment (ROI) real or perceived, sometimes the funding just isn’t there.

Consequently, changes after the initial strike have to do more with less.  But making dramatic changes to the system periodically becomes too much of a business disruption; subsequent changes must be evolutionary rather than revolutionary.  And therein lies the problem.

The tools just don’t do well in that regard – chiefly due to all the complexity introduced from all that extra unused functionality.   Making a change in a running, functional production environment becomes such a crucible that people are rightly afraid to pull the trigger.   You probably will never have a chance to properly undeploy the change, and if you’re really not careful you’ll rip a hole in the fabric of space-time.  Some of this danger could be mitigated with robust testing, but, adding insult to injury, many testing environments end up inadequate or not fully representative due to resource limitations.  So then teams sit and wait for an upgrade interval instead, because when things go south, there’s a convenient scapegoat!  But the upgrade gets delayed… and the system plows on as is.

So if you’re paying good money for a system that you can only begin to tap into, and there are fleeting hopes of pushing it much further for quite some time, what kind of situation is this?  If you are using a system where you’re not using 90% of the functionality, how efficient is the system for the 10% you are using?  And how’s that user experience?  Don’t get me started, that’s another post.

I’ve got two words for you:  Maximum Overkill.  You needed a golf cart, but you’re driving your clubs around in a monster truck, and boy is the thing expensive and hard to deal with.  It’s the price of a thousand unused functionalities.

Breaking this vicious circle involves overcoming the paradigm of software being sold exclusively on functionality, so that efforts aren’t focused on an endless parade of limited-value bolt-ons, but rather very strong and robust core functionality that is flexible, accessible, and amenable to evolutionary change.  For the companies suffering through 20 years of this is one thing, but younger companies no doubt should demand better.