The PLM Trail

PLMTrailProduct Lifecycle Management (PLM) is a journey.  PLM is not magic dust that you sprinkle over a business to provide instant results; rather it’s a transformation over time.  Wait, you’ve heard this before?  Today’s perspective is not about why PLM is a journey – you’ll find pervasive wisdom on that front from many of the thought leaders in the arena like Jos Voskuil, Jim McKinney, or pretty much every consulting organization on this planet.  Instead, the present exploration is about precisely what kind of journey PLM may be characterized as.  It’s often a little too easy to romanticize the PLM journey, with teams of consultants, architects, and stakeholders running across the beach in a wonderful Chariots of Fire moment with the sun and requirements at their backs, and a Vangelis data model crescendo in the background.  What a glorious thing.  But in fact, PLM is a journey fraught with mortal danger, and that’s kind of a problem.

I have a thought.  PLM is indeed a journey, but not with the convenience of a road trip to the Grand Canyon, or a flight to Tokyo, or even a multiple-day backpacking journey in the Canadian Rockies.  You see, all of those journeys can be made with relatively little planning, and have minimal susceptibility to unlucky turns of events.  PLM is more like a trip to the Death Star in a rusted piece of junk with the intention to put a torpedo through an impossibly tiny hole.  PLM ain’t like dusting crops, boy.

If PLM was a trail, it would be exactly like Oregon Trail (the game).  Some of you may or may not recall Oregon Trail, made famous in school computer labs in the late 1970’s and early 80’s.  It was a rather sadistic little educational game, designed to communicate the hardship that American pioneers faced as they trekked across the west.  A lesson the game version delivered almost too well: while the true historical death toll for pioneers was something on the order of 4 to 6 percent, the simulation was often far more brutal.  You would be presented with many difficult choices along the long journey, and if you didn’t plan precisely so, that journey would end badly.  Badly meaning no survivors.  Sometimes even despite meticulous preparation, just one particular turn of events would ruin your day, and your entire wagon train was quite notably hosed.  It was an impossibly long journey with potential for disaster at just about every turn.  Sound familiar?

A bitter truth is despite a great variety of available software and platform options, and a healthy supply of PLM expertise of all types, many PLM journeys end in abject failure.  A recent article on, highlights this in no uncertain terms:

“In their effort to improve PLM capabilities, executives often invest large amounts of money in modern PLM software with the promise of significant returns. Arthur D. Little’s experience is, however, that most PLM initiatives fail. This is not due to a lack of capabilities in the software but is rather an effect of how the PLM projects are scoped and implemented. The consequences are not inconsequential, often leading to the loss of tens of millions of euros in sunk cost and resulting in the termination of staff and serious effects on critical business processes.”

There’s definitely a problem or two here.  In Oregon Trail, measuring out just the right amount of supplies before and during the journey was absolutely central to success.  You had to have provisions prepared ahead of time.  Wagon.  Check.  Bullets.  Check.  Canned Beans Check.  Ox Check.  Spare Wheel.  Wait, forgot!  Oh sorry YOU’RE DEAD.  Planning for PLM has similar criticality.  Those involved must have a complete, cross-functional holistic view of the enterprise.  It’s not surprising that project teams who are neither prophets nor magicians get at least one or two details wrong.  Or, if particularly unlucky, many details wrong.  Oh sorry YOU’RE DEAD.  My prediction is that someone with a deep consulting background will jump in and exclaim that’s precisely why you need consultants.  Consultants might make better guesses, depending on the relevancy of their experience,  but they are also neither prophets nor magicians.

One might argue that the infuriating random events injected into Oregon Trail that made it so unforgivable have no direct equivalent in PLM implementation.  After all what’s the PLM equivalent of Cholera, or a broken wagon wheel, or running out of bullets?  Actually, the parallels are quite vivid.  Losing a key member of the team to another opportunity?  Might as well have been Cholera.  What do you mean the integration has an effectivity bug?  Shades of a busted wagon wheel.  Organizational change has shifted funding?  Sounds like running out of bullets.  The key here is the PLM journey is too fragile considering the investment of time, manpower, and cash.

Back to the point on losing a key member: successful PLM implementations depend too heavily on genuine heroes – with just short of the Marvel-demanded cape.  These champions are typically keepers of the vision – the imaginary destination at the end of the journey.  The consequences when champions are taken out of the loop voluntarily or involuntarily are often quite dramatic.  And this can and does happen whether the champions are internal or external to the business.  And if you lose your key people, just like in Oregon Trail it’s Game Over, man.

The nice thing about Oregon Trail the game is you could always try again.  That was part of the appeal – convincing yourself that next time, you’ll get it just right and make it to the promised lands.  And you could restart as often as you like.  Learning through failure and experimentation.  In PLM, no such models exist – be prepared to insert 10 million dollars to continue.

The larger lesson is this: pioneers traveled all the way to Oregon through much pain and suffering because they had little choice.  It didn’t stay that way, and something called technology and progress transformed the very character of the journey.  Today, we just go online, book a flight, and complain that the trip takes a whole 3 hours while playing Angry Birds on a tablet, sipping Ginger Ale, and writing ridiculous blogs about PLM.

You see the point here?  Where is the PLM equivalent of the airline flight?   We’re still riding wagons through the wilderness.  More troubling is the fact that many insist that the journey must be accomplished riding in wagons across the wilderness, because that’s the only way to customize your experience and transform the business.  As long as you have an expert wagoneering consultant, you’ll be spectacularly successful.  It’s a thoughtful, but ridiculous notion.  Flying is safer and more convenient for all.

Yes, your solution architect has died of dysentery.  What are you going to do now?  The natives are about to shoot your wagon to pieces.  How long will the data migration take?  Hopefully you have a magician in the back of the wagon.  Tell me about your journey.

  • Ryan

    Yes, the eagle caries away your child. Keeping your key players is a challenge in todays business world. BTW, I love the Oregon Train comparison, it’s very fitting.
    There are two characters that can make or break your trip: the recycling magician and the Indians.
    The recycling magician is the person in the back of the wagon. This persons job is to perform the magic on the company data that is suppose to be “standardize” and easy to work with. This person is the one who makes you understand that the true reality is that your company data is in shambles. This person “recycles” and cleans up your data before it gets loaded into your system.
    We are currently on month 9 on our data clean-up. This has one person full-time and some automation tools to build our data foundation. It hasn’t been easy and your department managers are humbled when you keep coming back, and back, and back to them with question like “What do I do with this?” or “How do you want this document classified?” when all the data is “standardized”.
    We also need to include the Indians. Forgetting about the Indians with be the death of your PLM project. The Indians in this case are your employees. Without proper change management your game is over after you leave the General Store. You need to get buy-in early and continue to keep your Indians informed of the changes that will be affecting them. If not, you are going to find yourself with several arrows through your chest -and some in your back- and then you’ll be scalped!
    We are releasing a major component of our CPQ system and we had to delay a couple “come and see” sessions due to some “undocumented un-enhancements”. I had to push hard to get the sales managers to hold off on sending their staff to the sessions. I didn’t want to have a session that started with “The system is running but you can’t do this, and this and this and this is not working yet.” The first impressions are really hard to overcome- even when the final product works like it should.

    • Ryan, these are some great examples! I was discussing a very similar data cleansing situation with a colleague today – it’s amazing how much a nightmare it can become. Nothing like the sound of an arrow whizzing on by!

      • Ross Bernheim

        Most businesses aren’t planned, They just grow haphazardly. We resist proper planning ahead of time.

        PLM and standardizing the data going in is just the start. Engineering and Purchasing are the starting points for this data. But we need to not only integrate these two starting points, but we need to consider what data flows on to inventory management and accounting systems. Which brings us into the other side of the house, The business side where we need to consider stepping up the game to Enterprise Resource Planning software instead of trying to patch together accounting software, client management, inventory management, and other software.

        A suite of PLM and ERP would also eliminate a lot of redundancies and having to enter data multiple times and make sure all are in sync.

        • Ross, perhaps organic might be a better term than haphazard, the lack of proper planning is not by choice I would think, but rather that too many things are simply unknowable. It’s seat-of-your pants style, and it’s how businesses find their niches and strides. What do you think?

          It’s also interesting to note that the suites of PLM and ERP are always considered distinct, do you think the overlap between the two is a help or a hindrance?

          • Ross Bernheim

            Organic may be a more diplomatic term for unplanned.

            While I agree that many things are unknowable beforehand, it is a lack of any real planning and organization to make the business organized and orderly so that it can cope with the unknowable in an orderly manner that is a problem.

            All businesses know they need an accounting package for taxes and to find out if they made a profit or loss. But they don’t even make an effort to evaluate the software to see if it is a good fit for other needs. Does it communicate with other software? Does it store the information that you need? Does it have forms generation so you can tailor the forms such as PO’s to reflect your company and its needs?

            Does your company need CRM? Inventory management? How about looking at an ERP suite for the business side of the house and phasing in the modules as you need them?

            PLM and ERP are essentially looking at parts of the same data. The purpose and needs of the two types of programs and their rules are different and trying to keep the portions of the data that ERP needs in PLM would be horrendous. And the reverse would be just as bad.

            The overlap is the portion of the data that both programs use in common. Part number and description and perhaps some additional identifying information. But PLM doesn’t care about keeping accurate costing or inventory or adhering to accounting rules. Likewise accounting or inventory management software doesn’t care about RoHS, REACH, CE, UL, or other certifications, Multiple vendors and vendor part numbers for an equivalent part are generally not of any interest to an accounting program.

            Engineering will generate a part in PLM, then the information that is needed to purchase the part is transferred to the business side of the house, usually the purchasing module of either the accounting or inventory management program which then passes it to the accounting program. PLM to purchasing drops all the information from the PLM that is not needed for inventory or accounting purposes. But the part is now in the business side of the software where additional information relating to that side of the house is generated and attached to the part.

            There is a portion of the information that is common, but there is a lot that is different between the two types of programs.

          • Very well put, thanks for your insight!

        • Most businesses aren’t planned, They just grow haphazardly. We resist proper planning ahead of time.

          Growth by merger and acquisition really complicates things. It’s bad enough when one business unit these problems. Now take 5 business units which each have these same problems individually and then try to bring them together.

          • Ross Bernheim

            Mergers and acquisitions multiply the problems. There are not only data differences, but cultural differences as well.

            With many acquisitions and mergers, the impulse is to change things. This usually destroys the company acquired or merged in.

            There is an old saying about making haste slowly. You need to be open to change on both sides and build consensus that the changes proposed are worth the effort and cost for those making the changes.

            It is easy to tell the acquired or merged company to change and use the system the acquiring company uses without a full understanding of the costs of forcing the acquired company to do so. Rushing this process leads to problems and resentment.

            Changes need to be planned out and buy-in needs to be attained before commencing the changes. Also it might be worth considering changing the acquiring company’s system if the acquired company’s system is better. Or a blended system with the best of both systems.

            The key take away is to go slowly in making changes and understand the acquired company’s history, systems and culture before even attempting to make changes.

  • Ross Bernheim

    Data standardization is one of the reasons to get PLM started when your company is very small and has less data to begin with. The smaller the haystack, the easier it is to find the needle.

    Get buy-in from purchasing to use the PLM for parts purchasing and get them to add the parts as they purchase them, also get them to download and vault the relevant data sheets, certifications, etc.

    • A very good point Ross, usually after a certain scale territories between PLM, ERP, and CRM are already drawn – and the result can be the same fragmentation and silo creation these systems hope to avoid!

      • Ross Bernheim

        This is why it is important to select PLM, ERP (hopefully with CRM built-in) that can smoothly transfer data from the PLM to the ERP suite. I don’t envision data flowing from the ERP suite to the PLM.

        • I have seen many bridges and Enterprise Service Buses (ESB) between PLM and ERP over the years, the divide from EBOM to MBOM is usually the instigator. There are legitimate reasons why communication should be bidirectional. However, since their core audiences are different rarely are PLM and ERP ever selected with the other in mind – often making integration exceedingly difficult. Just some thoughts, thanks for yours!

          • Ross Bernheim

            One of the problems is that neither side understands the needs of the other side. This is why you need to have coordination between the engineering/production side of the house and the business side of the house.

            Key is the relationship between engineering and purchasing. Engineering has to put the information that purchasing needs to be able to buy the part into the PLM so that the purchaser can extract it and get it into the purchasing portion of the business software which is the entry point into the business software for parts. The parts need to be in the system before you can build a BOM in the business software.

  • Pingback: PLM: Insert 5 Million Coins to Continue | E(E)()

  • Pingback: Enterprise Game Saga Episode 3: Open Worlds | E(E)()