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

respected, highly decorated, senior engineer will state “we could have built that our-
selves, quicker, and cheaper” crushing the credibility of the project team and causing
the executive sponsor to go into a tailspin.
One of the fundamental issues is that the product engineers usually do not have
the same notion of “application” or automation as the PLM implementation team
does. On a recent project, the PLM implementation team was working hard to plan
and scope out the details of the PLM implementation. They were investigating con-
version and interface requirements for the project. In one particular interview with
end users, they were told about the “36 critical applications” that had been built -
some that interfaced directly with the company's contract manufacturer - and how
all of the data needed to be converted and the functionality of all 36 applications
incorporated into the new PLM solution!
Needless to say a major warning flag was triggered. The PLM project lead-
ers were very concerned that the initial project estimates of complexity, duration,
and cost were no where near accurate; 36 data conversions and countless func-
tional requirements unaccounted for was potentially devastating to the feasibility of
the project based on current executive expectations. A meeting was quickly called
between the product engineers, their boss (project sponsor), and the PLM project
leader to review the 36 critical applications and discuss the feasibility of adding
that much additional scope to the already tight project plan. Fortunately, what the
team discovered in the meeting was that the “36 critical applications” were simply
HTML pages of document links. The large number of “applications” was due to
how the documents had been categorized. Since documents were already in scope
and the HTML pages pointed at the same document repository that had already been
analyzed by the tech team, there was no scope impact.
The key message from such examples is first not to take lightly the concerns
of product engineers or end users as that could negatively impact the success of
the project later on. More importantly, a thorough analysis of the issues would
usually reveal easy workarounds that the project team could adopt to address the
concerns.
5.2.2.2 “We Can Do Better”
The “build it myself” mentality becomes very apparent as soon as the PLM
implementation team starts working with the engineering team, collecting solution
requirements, and reviewing vendor applications. Vendor application capabilities
leave plenty of room for complaints.
The maturity and stability of the PLM applications is analogous to the ERP mar-
ket 15 years ago. The functional foot print is currently being expanded through
acquisitions resulting in a bit of a hodgepodge of user interface standards, process
flow, and data definition. The vendors are making good progress but they are quite
a distance from completion. Although this is more of a “maturity” challenge and
less of a PLM unique situation, it is a significant issue for the PLM project team to
manage through. Add into the mix the earlier discussion of the technically compe-
tent engineer end user and it quickly becomes apparent the incredible challenge it