Oracle is heavily involved with America's Cup racing and this week the Oracle sponsored US team is battling sailing superpower New Zealand (the Kiwis) for the cup. One interesting phenomenon I have noticed that is governing the outcomes of this race are the winds. The Kiwi boats seem to do better in heavier winds while the US boat is better suited for varying conditions. There is a balance required between too much and too little that allows the US boat to win against the favored Kiwis. This balance is often referred to as "The Golidlocks Principle". I remembered the story from my youth as almost anyone would. The idea of a small girl breaking into a house owned by bears and seeking out the perfect breakfast, bed and chair is a bit absurd but does highlight a constancy in our world about the rule of three; too much, too little and just right. This same principle applies to technology and specifically PLM. In my last article The PLM State: Footsore in Boston-The Perils of PLM Technology Fixation I discussed the ideas around becoming too enamored with technology at the expense of process and how to find the right balance. There was some good discussion on this topic afterward on the article in the PLM Professionals Group where I discussed the challenges of balancing the competing interests of vendors and clients in PLM deployment. This article will expand that topic to a broader context to understand what companies and service providers can do to ensure their PLM adoption experience is "just right".
Obviously, the vendors or developers of PLM software play a major role in the process of PLM adoption. Companies like Oracle, PTC, Siemens, and Dassault spend millions developing the major PLM platforms that most companies use. They also spend significant resources in marketing their products and assisting their clients in justifying the investments they make in this area. Without these vendors, service companies would struggle to convince companies to adopt these automation solutions for their product development process. I believe it is also true that these bigger vendors validate PLM and make it easier for smaller companies to develop and sell PLM technology. What this means is that as service providers and as clients we need to be sensitive to their role in the PLM acquisition and deployment process. However, as I pointed out in my previous article there can be conflicting interest especially around timing when it comes to PLM. Most of the major vendors are publicly held companies and try to sell their products on a schedule. This is why they often promote the "quick start" deployment methodologies we discussed in my previous article. If they can convince companies that the adoption cycle for PLM is short then they can also shorten the purchase cycle for their software. Unfortunately, this can lead to less than optimal results from the implementation side. We discussed how important it is to fully understand business outcomes and develop a plan that ensures these outcomes are met through the manner in which the PLM software is deployed. This preparation can take some time and should not be circumvented to meet a quarterly deadline.
The problem occurs however in that if we completely disregard the vendor in these transactions we create issues on their side. They are expending a significant amount of resource to assist with technical validation and cost benefit analysis to help companies select the best PLM tool for their companies. If they are not compensated for their efforts they will be forced to pull back on these activities and ultimately this will impact the market. Without the resources these vendors provide companies will struggle with justifying purchases and better understanding the capabilities of the systems they are evaluating. Moreover without some concession to these vendors the viability of the market as a whole is endangered. Most of these companies derive revenue from other areas. PTC has CAD software, Siemens and Oracle have vast product offerings so it is important to do what we can to support the economic realities involved in this space. Additionally, if we as service providers ignore this reality then the vendors will go out of their way to select inferior partners to work with that are unencumbered by the reality of what it really takes to effectively deploy PLM and all will suffer. However, it is not advisable to sacrifice the needed elements of successful PLM deployment merely to ensure consistent revenue flow for multi-billion dollar companies.
Steven Covey talks about the "win-win" scenario in his book The Seven Habits of Highly Effective People. Here is a quote from the book, "Win/Win means that agreements or solutions are mutually beneficial and mutually satisfying. With a Win/Win solution all parties feel good about the decision and feel committed to the action plan." I thought this was so critical that I actually wrote two articles on the principle. The article "The PLM State: Habit #4 Think Win/Win, Have you Hugged Your PLM Vendor Today?" is particularly relevant to this topic. The one thing that I failed to provide however is a solution to this particular conundrum. I really think that in the process of acquiring PLM for your company the product and the services need to be decoupled. Some companies do this to a certain extent but most keep services and software closely tied. This is mainly driven by financial requirements. Companies have budgets and consider the expenditure for software and services to be one in the same. The reality is that they are very different. Selecting software and understanding how much and what type you are going to need is a fairly well defined process. It can be executed in a relatively short period of time in most cases. To fully align services with a company's business requirements can be a little more involved. Ideally, conducting a discovery activity prior to developing an actual Statement of Work is a best practice that yields the best outcomes. Some would argue that service cost is a factor in differentiation between PLM platforms. I would be very suspicious if there are larger differences in service cost between different platforms. Most PLM tools are fairly mature and the cost to deploy should not be that great unless the platform has bigger issues.
Nonetheless, treating software and service the same is a costly mistake many companies make. They soon learn that services are more complex and the consequences usually manifest themselves as numerous change orders driving up cost or an inadequately configured application. Viewing the services separately on an independent timeframe allows for the best of both worlds. Vendors are able to meet their timelines and companies can reap the benefit of the resulting cost savings and then can ensure services are properly structured for their companies. Often times the purchase of the software can be a lever to be used to engage other parts of the business in the definition of the PLM system. Once the software has been selected then the political aspects of the situation melt away and everyone can focus on ensuring the final product is configured to meet the business needs that caused you to seek out the technology in the first place. Viewing services and software independently is the balance I described at the beginning. It is "The Goldilocks Principle" for PLM adoption. Hopefully, Goldilocks will smile on the Oracle sailing team and they will have the just right winds and retain the America's Cup once more.
[Edit: Repost from 2013]
[clear][clear-line]
If you'd like to learn more about our implementation methodology:
