Written by: Fred Keith

Any major change to the way a company fundamentally gets its work done in the interest of operational efficiency has always been challenged by human nature. People generally don’t like change, and we resist it when we perceive that the promise of growth and/or profitability may not be beneficial to us personally.

We all have our own personal ROI and none of us are robots. Unless we are persuaded and unless we are fully “on board,” we are likely to be suspicious about change at the outset, half-hearted through implementation, and resistant from then on.

More than most other corporate endeavors, enterprise software technology initiatives fall victim to this reality. New implementations in ERP, CRM, SCM, MES, FMS, asset management, logistics management, and others all run into resistance. Product lifecycle management (PLM), however, encounters particularly acute challenges because its scope and breadth reach into so many departments, touches so many individual motivations, and often collides with many personal goals. As many of us have heard, “culture eats strategy for breakfast.”

While we constantly write, speak and think about PLM initiatives in terms of people, processes and technology, the “people” part means addressing the management cultural change in planning as well as fixing it in implementations that have fallen short of ROI expectations.

Many companies focus too much on processes and technology. People and their work habits—which comprise the organization’s culture—rarely get serious consideration.

In other words, the implementation plan’s inherent greatness is left to sell itself. Too many management teams seem to view culture as a box to be checked and then ignored. They apparently believe that if their people are told to do something, for example, use a new system, they will just do it.

When project leaders finally concern themselves with cultural change, they are in a crunch. The attention spans of management and implementation planners often become stretched. Startup time frames are short, hard deadlines are looming, and budget dollars are nearly gone.

A great deal of time is expended in defining the software’s intended role, justifying its purchase, pinning down even the smallest requirements, evaluating and selecting a solution provider, and detailing the rollout. This up-front work is exhaustive, but the people part of the project—what the users say they want and need—often gets dismissed.

No technology implementation plan can guarantee a successful adoption, especially if the implementation is seen as a top-down decision. Users will treat it with skepticism, as a requirement for continued employment or an invasive new form of micromanagement.

When this is the case, users will see themselves as obligated to use a reporting system that adds no value to their work or, worse, as something to be done right before going home for the day. The inevitable results include inaccurate and incomplete data (garbage in, garbage out, or GIGO), questionable metrics, shaky analytics, poor visibility, and ineffective planning.

Inevitably, two or three years later a CFO who asks hard-nosed ROI questions will find yet another IT initiative that did not live up to its billing.

Moral of the story: don't expect enterprise software to solve what are fundamentally cultural alignment issues, especially if the issues extend throughout your organization. You'll be disappointed. Save your money for more promising initiatives.

Summarizing the Objections and Issues

This next section itemizes the cultural issues and objections that so often derail enterprise-level technology implementations, including strategic PLM initiatives:

• Job security fears that efficiency means downsizing
• Requirements determined by gut feel with conflicts left unsolved
• Complexity and the KISS bias
• Confusing the journey with the destination and the apparent lack of success stories
• Insistence on “We’ve always done it this way” and “If it ain't broke, don't fix it”
• PLM’s supposed big-company bias that can translate to: “Basic PDM is good enough for us”
• Antiquated work rules and dubious management incentives
• Endless demands for “further study” generated by PLM’s many critical media and pundits

Each of these objections can be a major obstacle to successful implementation, adoption and eventual maximized ROI. These objections actually can ensure the negative impacts that the resisters claim to fear the most. Whether active or passive, stubborn resistance can derail the implementation and mean that hoped-for benefits may never be achieved.

In the worst case, this may lead to reassignment. (see below)

Implementation objections, however, should never be brushed aside or treated as trivial. Younger users and the newly hired may be reluctant to speak up, but their concerns may point to serious implementation difficulties. Addressing these difficulties can help build support for the implementation team, reassure worriers, and help isolate the foes of implementation.

Sometimes the Only Way Forward Is Reassignment

For the reasons outlined in the main story, small groups of employees will actively resist any technology advance, PLM included. Here are three problem areas and suggestions for overcoming them:

• Adamant resisters may disrupt implementation by obfuscating and confusing requirements. They will insist on what is easiest for them, refuse to give input, and flood the effort with objections. When promptly called out, these tactics are easy to spot and head off.
•  Threats to adoption can arise, especially if an implementation is foisted on employees to enforce “good” work practices. Threats to adoption and ROI become apparent when employees refuse to use a new technology or process. Such refusals can stall a project, so project managers must not be shy about exercising damage control.
• Threats to ROI emerge more slowly and subtly—such as when users’ workflows and data contributions degenerate, or when resisters try to “get by” with minimal effort. This backsliding may require intervention by an organization’s leadership.

These challenges are often entangled and can become quite complex. Outside expertise could mean the difference between success and project failure.

A final caution: If the company culture is already undermined by financial trouble, abrupt layoffs, poor company strategy, or clueless leadership, imposing lifecycle management (or any technology) to force change within an organization will ultimately fail. If the motivated people are already leaving, it may be too late to implement damage control.

Objections and Issues in Detail

Each of the bullet points above has many implications. Addressing them effectively translates into business-unit productivity and enterprise competitiveness.

Job security fears may reflect a basic misperception about technology-linked displacement. Real job security requires getting out of one’s comfort zone and moving into a new one. Employees and managers who continually resist change put their jobs, and those of their colleagues, at risk.

Nervous/fearful resisters commonly try to conceal data silos and info hoards on which crucial decisions may be based. Closely held product, process and organization knowledge confers personal power as well as job security, so info silos and fiefdoms are guarded vigorously in small and medium-sized businesses (SMBs). Poorly understood info in silos/hoards thwarts collaboration and may constitute big security headaches.

Implementation teams should bear in mind that not all of us express ourselves well, especially when we are uncomfortable. Listening and questioning are often more helpful than confrontation. Discomfort fosters critical thinking, which must be encouraged if change is to be embraced.

Managing conflicts in requirements. A risk in implementations that connect many departments and business units is disagreements about wording, terminology and sequencing. These disagreements may point to deeper problems, such as misaligned business objectives. “Who would ever need this?” clashes, for example, with “I need it yesterday!” As with job security fears, listening and questioning are often the best strategies.

By highlighting needless complexity, KISS (keep it simple, stupid) is often a sensible approach. Technology implementations such as lifecycle management are always complex but if oversimplified, KISS may undermine them. To prevent that, GUIs should be tailored to users’ specific tasks and responsibilities. Unfortunately, KISS can be misused to justify the status quo and protect ineffective workplace cultures. In some situations, KISS can perpetuate the use of spreadsheets and even lead to new ones.

PLM implementation is a journey and not a destination—which is why PLM is a business strategy. In today’s marketplaces, change is both constant and all-pervasive, so implementers and users must be in it for the long term—sometimes years. That means PLM’s supposed lack of stellar successes may escalate quibbles. As the project moves forward, incremental gains will be continuous, and some will be huge.

Also, unfortunately, the enterprise value of incremental gains can be easily overlooked. Frequent progress reports to remind users of both improvements and cumulative benefits are invaluable. Reports must be positive in tone and detailed with before-and-after metrics, charts and graphs. Such reports will help boost user cooperation and foster constructive conversations.

PLM is not big company biased, yet this supposed bias against SMBs is an excuse for clinging to basic PDM. Overreliance on fragmented, “legacy” PDM and other PLM predecessors constrains the use of new solutions. These technologies include Internet of Things (IoT) connectivity, digital twins/digital threads, simulation & optimization, machine learning, augmented reality/virtual reality (AR/VR), and model-based systems engineering (MBSE). Each can be vital to the collaboration that innovative product lifecycle management requires. PLM solution providers have many successes with SMBs. Be sure to ask for them.

“Always been done”/“Ain't broke” are where persuasion has to focus. Either can ensure that any innovation will lead to disruption and cost overruns while outdated functions may be further entrenched. An all too common assertion is “X or Y or Z has always been done with spreadsheets, so why change?”

A big part of “Always been done”/“Ain't broke” is an overreliance on spreadsheets and simplistic analyses; both can block the insights needed to solve long-standing problems. Project teams should search out and publicize examples that foster process change along with traceability and impact analysis. Relevant examples should be sought from solution providers.

A closely related difficulty is the persistence of preprinted forms, especially in regulated industries. These forms and reports should be recreated and reimagined in PLM. Once forms are digital and online, they can be filled in with actionable data and delivered to decision makers when needed. The same is true for verifying contract milestones achieved, objections resolved, and needed changes addressed. Ditto for complying with regulatory demands.

Antiquated work rules and dubious management incentives can be quicksand for any technology implementation. At a minimum, these evil twins can provide excuses for inaction, so they should be addressed as early as possible. They can also lead to tracking the wrong metrics. Intervention may be needed by upper management to address this.

Journalists and pundits who continually flag PLM shortcomings are really highlighting steps in the journey to effective lifecycle management, not just finding fault. Implementers should remind wavering users that nitpicking is easy, but real change demands thoughtfulness and focus. The upsides include avoiding “paralysis by analysis” and thwarting any professional internal evaluators who thrive on delays.

Given how complex these problems are, they may best be addressed with the help of outside expertise. Experienced outsiders can turn a potential failure into a solid success. Piecemeal and do-it-yourself efforts are probably doomed.

Persuasion and Listening Versus “Justification”

Any viable implementation plan must address these issues by clearly showing individual users how they can benefit. Users (and workgroups) must be able to see how the project’s promised increases in efficiency and productivity will help them to do their jobs. No matter how compelling the financial justifications and ROIs may be, they must be accompanied by personal ROI—“What's In This For Me.”

Because lifecycle management touches nearly all units of an organization, gains must be explicit and widely understood. CIMdata recommends a persuasion effort with an implementation roadmap and credible use cases that explain new features and new requirements.

Carefully thought out persuasion can reinforce the project by:

• Managing the lifecycles of benefits as they emerge. This is best done by generating status reports, dashboards and key performance indicators (KPIs) that present benefits in the context of their impacts at the enterprise level. These benefits should be aligned with customer needs while taking into account executive requirements and overall business strategy. To encourage implementation buy-in, benefits and new efficiencies should be presented holistically to all users and all stakeholders. KPIs should also be reflected in incentives and bonus plans.
• Using all the enterprise’s communications channels—even an article in trade media—to spread the word about new benefits for the business unit and for individuals.
• Tracking individual contributions to the project and publicly recognizing the most motivated people.

As project data accumulates, persuasion must extend to the rest of the organization. User/workgroup productivity gains must be shared “downstream” with engineering units, manufacturing, Q/A, sales, and service. This is best done by “socializing” the project and continuously describing its achievements. Socializing is an excellent way to show how PLM empowers everyone, which helps ensure team-oriented perspectives and enterprise-wide collaboration.

Any well-grounded persuasion program should also show how a project’s benefits positively impact the enterprise’s customers, for example, how innovative goods and services get into the hands of customers sooner and at a lower cost. Happy customers generate more purchase orders than unhappy ones. Ultimately, top-line revenues from happy customers support each user’s personal ROI with more secure employment and expanded employee benefits. Achieving this personal ROI can be greatly aided by bringing CIMdata in as an implementation project partner.

About the Author