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

Table 5.1 Engineering response to PLM implementation practices

Standard practice Engineering response

Cross-functional teams As engineers we know our business, why do we need to

waste people's time in marketing or operations?
It's okay that quality department does not want to
participate, we know what they need

As-is and to-be process modeling We are implementing a new application, why do we

need to model our current processes?

Application design documentation Nobody ever looks at those documents after you deploy

the system anyway

Minimize application customization How hard is it to change a label on a screen?

Code freeze These are just small changes that should not have any

adverse impacts

Retire standalone systems If this system doesn't work, I will write my own

programs

Testing Why can't IT look for bugs? My time is too precious to

be testing the application
Why should we run “negative tests”? Who would
normally do these things anyway?

Security Product engineering resources should all be granted

System Admin authority so that they can change
whatever they need to change in the system

Metrics and measurement We are not worried about the business case - this is an

important project

Data cleansing My data is fine. Why do I need to clean up the rest?

Training I don't need the training. I can figure out how to use the

system myself. How hard can it be?

make no mistake, when the PLM implementation team is allowed creative license
to address what should be standard practices, they significantly increase the risk of
project failure.
To illustrate this point, Table 5.1 shows typical responses from product engineers
(end users) when presented with standard implementation best practices in PLM
implementation.

5.2.3.3 A Burning Desire to (Not) Change

Collaboration, integration, global design these are the standard rallying cries for

taking on a costly, high risk, and complex PLM implementation - but not for the
typical engineer. The globalization of business has reached the product development
department it just has not necessarily reached the individual engineer.
Typically, time to market (TTM), product management, and product quality are
the drivers to automate the product development processes - but product engi-
neers just want their job to be made easier. Although it logically stands to reason
that standardizing the PLM processes, integrating them with all company sys-
tems, and providing a common communication interface to partners will improve

...