As further proof of my dedication, I am writing this blog from the mountains of Durango. One thing about Colorado is that in spite of its beauty, getting around here can be very challenging. We spent several hours today traversing a 40-mile stretch of road called the "Million Dollar Highway" between Durango, Silverton and Ouray. This road is very treacherous but very rewarding, and navigating the switchbacks and hairpin turns is anything but easy. I was struck by the similarities between this journey and Product Lifecycle Management (PLM) implementation. Many times, installing and setting up a PLM system might appear to be fairly straightforward just like the 40-mile stretch of 550 North looked on the map. Once the journey is underway, you are confronted with unexpected challenges that must be navigated. Many PLM vendors want you to believe that you can purchase and set up their software in one day. This may be true and really I doubt any of the established PLM vendors would be unable to accomplish this feat. The real question is how much value a company realizes from their PLM systems, and while a quick set up accelerates time to value, if it's not done correctly, it can cripple a company in the long run. There are numerous factors to consider when embarking on a PLM implementation and regardless of whether the software is a budget purchase or a full featured multifaceted application. This blog will debunk the idea of a big red easy button and outline a few things that are needed to ensure success when adopting PLM as part of a product development environment.
When a company embarks on a PLM implementation, one of the first questions that needs to be asked is why? Unfortunately, this question often gets obscured or forgotten in the rush to production. Identifying the critical issues you are trying to address with PLM can bring focus to the implementation and allow a company to see value sooner. Once companies are educated about the possibilities of PLM, they often tend to lose focus and take on too much. It is important to have a plan. When I decided to go on vacation in Colorado, I set up a plan for each day. I mapped out the route from Texas, where we would stay, what restaurants we would visit and what activities we would schedule for each day. I then called these restaurants and different companies to make sure we had reservations for our trip. What should a PLM implementation plan look like and when should it be created? Many times certain events trigger the actions around acquiring PLM. It could be a breakdown in communication for a specific product development effort or some late-stage change management issues. The point is when a company decides to move forward with PLM they need to sit down and create a map. This map needs to be reviewed as the process of vendor and partner selection continues. PLM vendors and consultants can be very helpful in creating maps but the company purchasing PLM needs to be actively engaged in this process and not be too reliant on the partners for this activity.
As part of a map, a company purchasing PLM needs to understand priorities and ultimate vision for their organization. Recently, we were approached about a software upgrade for a smaller division of a large company. As we discussed the project the client indicated the desire to bring additional companies from the division into their system and that potentially the larger parent company might consider adopting this PLM solution. This obviously dramatically impacts the map for this project. A simple upgrade of this client's PLM system would omit a large portion of the business drivers behind this plan. The technical aspects of the project which involve migrating data from one system to another pale in comparison to getting these three separate companies on the same page from a business process perspective. If the map focused on the upgrade, the project would fail. Fortunately, the client has already recognized the challenge behind integrating business process from three separate companies and has begun a dialogue and identified key issues. Before a single byte of software is installed, this client needs to have a detailed map in place that will navigate the perils of merging these organizations and then on top of all of this keep in mind the larger implications. It would be tempting to take down the relatively easy upgrade and worry about the rest later but anyone who has experience with PLM knows how this would end up.
The company in my example knows why they are upgrading or implementing PLM, which is a good start. Having the details mapped out prior to loading and configuring software is essential. Avoid rushing into a rapid configuration since this approach may miss the reason you purchased the software in the first place. My new wisdom is "implement in haste repent in leisure". If you can avoid the temptation of the big red button and the "quick start" implementation, you will reap more long term value from PLM. There is nothing wrong with easy-to-implement PLM solutions or fixed-price implementation templates as long as they are aligned with strategic goals for product development. The best way to avoid getting lost in the mountains or careening off a tight curve is through upfront planning. Just consider this a cautionary voice as products become more refined and consultants get better at productizing their implementation packages.
