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.