xLM Solutions works closely with customers providing a variety of consulting and PLM services, guiding the implementation of new solutions, conducting data migrations, integrating PLM/PDM solutions with other technology, and customizing PLM/PDM solutions to meet unique customer requirements.

I recently visited a customer to review requirements for a new project on top of their PLM system –Dassault Systèmes 3DEXPERIENCE. I met with two of the customer business analysts (solution architects). During a discussion about one of the related features which currently exists in their legacy system but will be replaced by 3DEXPERIENCE, a debate transpired between the two analysts about the usage of and the need to implement the specific feature in the new PLM solution. One analyst claimed it was not used enough through the years and so why spend effort, time and money on it, while the other claimed it to be a loss of potential.

While listening to the debate, I asked myself, is there a right or wrong answer here? What would you have recommended in this case?

Loss of Potential vs. Immediate Practical Implementation

Despite having years of experience in PDM/PLM implementations, I found myself having a hard time solidifying a clear recommendation, even though I have been in such situations before. This is one of those gray areas in PLM, not a clear black and white case. While the analysts never directly asked me what the right or wrong course of action is, it definitely caused me to think about it for future recommendations.

As you can probably imagine by the introduction, there are multiple variables involved and the answer would differ based on each project’s circumstances. 

I concluded that there were two sides to the debate. Let’s review them.

• The immediately practical solution architect. He checked the legacy system and discovered that only 70 objects of a specific type of this feature were created since 2008. Since the system supports 300 users with frequent usage, it means that this feature had a very small and insignificant percentage of usage. Therefore, the effort of developing a custom solution is overkill for a feature that is literally not being used.
  
  
• The perfectionist solution architect. He claimed that the misusage was actually due to various reasons such as lack of training, legacy system evolution (this feature was added in a later phase in their legacy system), and that not using it means not realizing a valuable potential (users don’t know what they don’t know). This architect suggested it would be a worthwhile effort to implement such a feature despite the additional effort involved in customization, maintenance, etc. For argument’s sake, this could have even been a feature that never existed before.

Loss of Potential in PLM

I was looking for some sort of a formula to quantify it into values that can actually be weighted, one against the other. In this case, we are dealing with loss of potential. Just to clarify, when we talk about loss of potential, we mean loss of possible value vs. the more common discussion about having an acknowledgeable existing pain and whether it is worth implementing a solution for it. In the case of loss of potential, it is harder to quantify and associate value to a problem which you do not realize even existed. The solution I came up with is a bi-level, value-based and tactical implementation approach. Surprisingly enough it was based on the same question I would have asked had it been a known problem – “a pain point.”

On the value side, the answer would be to evaluate the value gained from implementing the feature vs. the extra implementation effort cost. If the result is positive, the thumbnail rule would be to implement the feature and do so in the immediate future. The question is, how do we evaluate value or gain from a feature which is considered a loss of potential, as it is not being used. The best answer I found is to ask the following such questions:

• If you had this feature, how much time and effort would it save you in doing the specific operations related to the specific business process?  
• How much more time do you spend doing your day-to-day job as a result of this feature not being available, well trained on, etc.

The answers to these questions would actually allow us to associate a number (of hours, of monetary value, etc.) to a technical feature’s potential.

A Tactical Approach

The tactical approach is not necessarily value related. It deals with developing a roadmap for implementation, which in this example would mean that we can implement the unappreciated feature at a later phase. In this way, it would reduce delays and the immediate cost associated with the extra feature implementation and allow the business to plan for phase II. Since the feature was not used before in the legacy system, there will be no loss of functionality compared to the as-is situation, and more value could be introduced in a later phase.

What’s the Answer?

Obviously, the solution is not black or white in all cases. Multiple other variables may change from one project to another, such as hard deadlines, limited budgets, centers of resistance to change in the organization, and more. Therefore, these guidelines cannot be a set-in-stone type of approach, but more of a common guideline to try and follow. However, common sense and organizational culture familiarity would normally help in determining the best methodology. 

I’d be happy to hear your ideas and thoughts. Please share you experience.