Product Lifecycle Management (PLM): Critical Issues and Challenges in Implementation - Information Technology and Product Development - page 83

desk in their office - accurately describes many organization's traditional prod-
uct development automation solutions. With the introduction of commercial off the
shelf (COTS) PLM applications, the engineering department's necessity to develop
and support its own custom functions or even an entire application suite is gone.
Unfortunately, the need might be gone, but the engineer's desire to build their
own PLM solution still exists. And, this creates several issues during the PLM
implementation process.

5.2.2.1 You Say Tomato ... I Say Tomato

One of the worst meetings that the PLM team will have early on in the PLM imple-
mentation effort is presenting the purchased PLM application to the company's
product engineering group (i.e., the primary users of the PLM). This is usually the
first opportunity for the engineers to get to see the new PLM application. Typically,
these engineers would not have been part of the “solution” selection committee -
and as such they didn't sit through the hours and hours of vendor demos and they
did not hear the perfectly reasonable sales responses to why some of the more
challenging functionality does not exactly work as expected.
If you have experience with any IT application implementation you might con-
sider this unpleasant meeting “standard fair,” a rite of passage, or as one project lead
likes to say “now the project can really begin!” So, why is this different for PLM
implementations?
The product engineer is a “hacker at heart” and is not afraid of diving-in head
first to address a technical problem. Interestingly enough, product engineers most
often have a very simplified vision of a solution. Their limitations are defined by
the hands-on experience that the engineer has had writing software and working
with databases and the complexity of the environment (number of users, platforms,
etc.) that he or she is deploying into. That being said, the difference in the prod-
uct development world is that if the product engineer (user) had the time, they
could probably build - or has already built - the functions the team is trying
to implement. When working on the implementation of CRM or sales applica-
tions, for example, it is very unlikely that the end user would come back with a
programmed, working prototype of a functionality - not so with PLM implemen-
tations. Although it is not often that the engineer community would challenge the
PLM implementation team with an actual working set of functions, it has and does
happen.
It is not unusual to demonstrate an application function and to have the engi-
neer question the complexity or approach used to automate the process. This simple
question can cause the team significant issues later in the project if the PLM imple-
mentation team does not thoroughly address it and resolve it with the engineer.
When product engineers question the complexity, they are really thinking about the
underlying function and not all of the technical complexity that actually makes indi-
vidual functions work together as a PLM system. If the engineer's concerns are
ignored by the PLM project team, when the project hits a snag later on (say, the
deployment is delayed or the scope is reduced to stick to the schedule), the very