Implementing Global IT Systems: Don’t Skip Stakeholders

With over 30 years of experience working in research and development (R&D) for a variety of companies and industries, I’ve seen my fair share of information technology (IT) systems implemented to support various global processes such as product lifecycle management (PLM), phase-gate, portfolio management, legal and finance.

Having observed these projects from all angles, I began to notice a pattern behind some of the most common mistakes being made during the implementation of large global IT systems in support of R&D or other business processes.

This series provides leading practices for avoiding the top ten most common mistakes.

Mistake #7: Skipping Stakeholders

Ensure that–at worst–users see no increase in workload, while most see a net decrease

Earlier in this series in Mistake #2–Playing the Shell Game, I mentioned the principal statement for a truly successful IT tool implementation:

Anyone who touches the new system will see at worst, no net increase in workload, and usually a net decrease in their workload.

While it’s easy to say that a system implementation will increase efficiency in the organization, it’s critical to ensure that all stakeholders will see the benefits of the system first hand. An increase in efficiency for the organization becomes a moot point if daily users see an increase in workload. Good luck getting buy in from anyone who’s workload increases, and without buy in, you risk the project ultimately failing.

One of the key change management tools used to hold yourself to the above statement is the Stakeholder Analysis. Many functions touch a global PLM, phase– gate, PPM or finance IT system, including:

• Marketing
• Operations
• R&D – Management
• R&D – Product Development ▪ Packaging
• Legal
• Regulatory Affairs
• Product Safety
• Finance
• Tech Transfer
• Business Unit
• Purchasing

While the exact functions and roles that touch a new system depend on the type of system, they always fall into three categories of users:

Approving functions

These folks approve the product or project’s advancement and ultimately the new product’s launch. Examples include finance, product safety, regulatory affairs, and legal. They may not use the system every day, but their role is critical. Stakeholder analysis of approving functions typically uncovers several complaints that a well-designed process and system can resolve. Here are some examples:

• Excessive time is required to check detailed new product designs against the hundreds of relevant rules, coupled with the product developers’ lack of detailed understanding of those rules. A great example is regulatory affairs. A new product may have numerous ingredients or components, each needing to be checked against regulations in all countries targeted in the product launch. A state of the art PLM system has a robust “guidelines and restrictions” module that tells the product developer their formula violates a regulatory rule. The benefit is two- fold as the violating formula never makes it to regulatory affairs and the regulatory affairs approver knows all the common rules have been pre-checked. This was so important on one project I saw that the entire set of regulatory and safety rules for Europe (European Cosmetic Directive), US (OTC’s) and South America (both North and South cones) were preloaded in the system.

• Approvers receive information to review and approve late in the process, in their view. And it’s hard to identify the final product for review as it continues to evolve until late in the process. This is particularly painful if the current process is done by e-mail.

• Finally, these folks often feel the information they receive is incomplete, so they waste time contacting the responsible party for more information.

All of these issues can be addressed through process design and system configuration, simplifying both the approvers’ and product developers’ lives.

Observers

Many people, including R&D management, the PMO, business unit, etc., simply want more visibility to projects currently underway. Their needs are easily met, but a stakeholder analysis is still valuable to understand why for two reasons.

First, many of these systems are sold “by the seat” and are not cheap. Just because 300 people say they would like more visibility does not mean you should buy 300 more seats. And secondly, who wants 300 more people watching their work?

Hard core users

These are the associates who use the system every day, entering information and seeking approvals to keep their project moving. For a global PLM system, these are often the product developers working in the lab. They are the most important people needing a stakeholder analysis. By definition, they will be required to do more work for the good of everyone else as they typically are asked to enter all the data and product design information. It is crucial that their net workload decrease and that they see clear benefits from the system.

Stakeholder analysis often uncovers one or more of these challenges that a well- designed process and system can address:

• Entry of information in multiple systems. I’ve seen organizations where the product developers were expected to put information in up to six different systems over the course of a project. One time, I pointed this out to an IT implementation team, about their project already underway. Their response was “We didn’t budget for any interfaces.” So they became the seventh system for data entry! Building interfaces to eliminate redundant work is a huge consideration that needs to be scoped out during the budgeting process.
• Repackaging the same information ten different ways. Approving functions often want to see the product information in different formats and with slightly different information. This is a lot of non-value-added work for the product developer. Again, a well configured system can present these different views easily.
• Waiting for approvals. Checking a new product design against global regulations can be very time consuming. This, coupled with a backlog of products needing “immediate approval,” causes an excessive turnaround time for approvals (at least in the eyes of the product developer). A well-designed process and system can cut turnaround times from weeks to days or even hours.

A thorough, formal stakeholder analysis is the key to delivering on the promise to make everyone’s life simpler through a well- designed process and supporting IT system!

Stay tuned to discover leading practices for avoiding these ten common mistakes. Being mindful of the challenges and solutions discussed in this series will greatly increase the chances of your next project becoming a sustainable success.

Mistake #8: Skipping the Dress Rehearsal

Download the eBook:

Top Ten Mistakes Made Implementing IT Systems and How to Avoid Them