I recently attended a conference on Inbound Marketing in Boston. It was quite a change from the Product Lifecycle Management (PLM) centric events I normally attend. It was held at the old convention center on Boylston Street so it gave me a chance to do some walking around in search of fine cuisine. I was armed with my faithful phone and Yelp and Trip Advisor so I felt pretty confident in the likelihood of finding a high quality lunch spot within reasonable walking distance. I scanned my technology and found a highly rated sandwich place about half a mile away. The problem with technology is that it doesn't always give you the full picture. My hike took me through some semi dicey areas (not as bad a San Francisco) and once I got to the restaurant I noticed the prominent Cash Only sign. Being on a plastic only subsistence at the time I was forced to go back to the drawing board and select another candidate. I found another highly rated sandwich shop about half a mile from where I was so I set off yet again. I arrived to a very small place with no seating and for the day no turkey or chicken. Being a strict consumer of fowl and really wanting a place to sit down and eat I once again resorted to Yelp to find another place to eat. Yelp yet again produced a sandwich shop that was ironically about a quarter mile from where I started. After I got there I noticed it only had 25 reviews. It was ok and after all the walking I needed a place to sit and rest anyway. The point of this rather longwinded recount of my journey was to highlight the dangers of becoming too reliant on technology. I was so confident in my gps and ratings system that I failed to do the extra work to ferret out the details. If I had read a little more and paid a little more attention to my directions I would have avoided some of the pitfalls I encountered along the way. PLM implementation can follow a similar pattern; recently we have worked with several companies where this issue came up. This article will review these situations and reveal how companies deal with the technology and process issues around adopting PLM.

When I was in Boston I met with a company we have been working with or quite some time. They have deployed PLM in different business units and we had been involved in an upgrade for one of their companies. After the upgrade they had reorganized some of the companies they had recently acquired into a business unit with this company. They wanted to extend the footprint of the PLM system to cover the entire business unit beyond just the one organization which is a good plan. The challenge they are experiencing is that some of the people within these companies view this as a technical issue in which it is just a matter of installing more software and getting these other companies' access to the existing PLM system. So like my trip through Boston they are techno-centric without considering the bigger picture. The executive I am working with recognizes he has a PLM as a process issue as opposed to a PLM as a technology issue and he is working internally to help others understand this. They need to figure out how the organization will function as a single entity through PLM and need to map existing processes into a unified methodology before they can successfully transition into the new system. As you can imagine getting multiple companies to agree on common methodologies can be a daunting task especially if the impression from the people involved is that all they need is a log in to get going. In the meetings we had and after I had suggested per a past article I had written, The PLM State: The Cart before the Horse? Using PLM to Design Business Process, that they could use the PLM system as the test bed and reference point as they attempted to reengineer their business process as opposed to trying to start from a blank slate or attempting to reconcile three business processes into a single one. His response reprinted with his permission was pretty enlightening and also contributes to the premise of my article.

"I have been in IT for over 20 years and I have led many projects. I have been fortunate that all of the project that I have led from the start have been successful. I have been involved with too many projects to count that have not been successful because they were not scoped correctly, not resourced or funded correctly or the objectives and goals did not match the needs of senior leadership or the company. Correct planning, before the project starts dramatically increases the success rate of a project. I know you will appreciate this. During my career, I led the successful implementation of an ERP application. The timeline from start to finish was 13 weeks. I challenge anyone to find a faster timeline. Yes, it was a company that was in its infancy. However, we did transition from one ERP application to the new one and we did implement all necessary modules to run a mid-size manufacturing company in the healthcare space. The reason we were successful is because we took 3 months (prior to starting the project) to plan the project. All aspects of the project. We included all key resources for the project in the planning and we developed a formal plan for implementation."

I really don't think I could state it any better than he did. Too often in our industry this aspect of the PLM acquisition is put aside based on the perception that the technology itself will eliminate the need for this step. Quick starts and prepackaged solutions promise the illusion of a rapid deployment by cutting out or shortening the upfront planning. My client's point is that this is an essential ingredient to a successful adoption of enterprise software. I particularly liked the statement about not matching the objectives and goals of the senior leadership of the company. This is a crucial requirement that is rarely fully considered and aligned with the outcomes of most PLM deployments. We have certainly witnessed the outcomes for companies that have failed to plan to this level stepping in after the company has "implemented PLM technology" but failed to meet the business needs of their organization. Quick fire implementations are not inherently bad they just need to be balanced with some up front planning and there is a misperception that these packaged deployments eliminate the need for planning. I also think some consulting organizations discourage this type of activity because it may lead to more complex scope which will force them to move beyond their comfort and capabilities outside the one size fits all deployment methods they promote.

The key takeaway from my experience wandering the streets of Boston is that technology can make you overconfident. It tempts you to take shortcuts and to move away from sound business practices that are fundamentally essential to process change or enhancement. It really doesn't matter if it is ERP, CRM, PIM PLM, Cloud based, On Premise, Thick Client, Thin Client, HTML, Java, Apple, Windows, or Basic the process for implementing business solutions requires upfront planning, vision alignment, resource allocation and time in order for things to go smoothly. This is probably not a news flash for most people but it probably is a useful reminder to avoid getting swept up in the latest technology trend and understand that some things are timeless. Take heed it will save you some shoe leather.[clear][clear-line]