We intend in this 2-part blog post to give you a check-list of the main risks you face in any Product Lifecycle Management solution implementation project. This first part will cover “pre-project” considerations that ensure you and your PLM supplier collaboratively head forward in the same direction. PLM solutions have such a wide functional scope and cross-departmental impact that consolidating as strongly as possible initial expectations, requirements, responsibilities, milestones, and so on, is vital for the project success.
1. Unrealistic expectations
˫ Expectations not aligned with the initial purposes of Product Lifecycle Management solutions may somehow be met by some PLM software on the market. However, any good solution provider should alert you when your requirements are off-tracks with what its software was actually designed for. May its solution fulfill your technical needs at first hand, chances are high you’ll get stuck when scaling up or when in need of some flexibility to adapt to your specific business specifications.
˫ Setting and not compromising on PLM requirements that are not aligned with your supplier’s standard solution will cause a longer and more delicate implementation and eventually lead to long-term maintenance complexities.
Mitigation: Thoroughly define your needs, consider different suppliers’ offers, assist to live demonstrations and take time to properly assess how one solution can be a good fit for your needs.
*While this may trivially sound like any RFP process, many of our clients show difficulties to accurately define their needs or understand how they can translate into a software solution. This is a critical step we successfully assist our clients through when they need to.
2. Gap Analysis
Even when your needs perfectly match what a PLM solution is designed for, you will always suffer a delta between your ideal and what the supplier you chose can actually provide through its software. If not properly assessed, this gap will lead to a very frustrating situation where you can actually use the software but will considerably lose efficiency because of its poor adaptation to what makes your innovation process unique.
Your supplier must talk in detail with you to understand the singularities of your activity, your specific processes, the deliverables you expect at stage gates, how responsibilities are assigned inside your organization and so on. They will leverage this to lead a gap analysis between your business requirements and their software standard capabilities to see what level of configuration is needed.
3. Project planning
Poor project planning consequences have been widely discussed and are well known but in the specific case of a PLM project, it may:
˫ Users won’t adhere to the adoption process and may turn into opponents to change. It’s a higher risk considering the central part that a PLM solution plays into your teams’ daily business and IT landscape.
˫ You will inefficiently mobilize your teams, affecting the long-term ROI of the project while slowing your innovation capacities during its execution.
˫ The specificities of your processes, the responsiveness of your different levels of responsibilities, the trustworthiness of your approval cycles won’t be properly rendered into your solution.
˫ Once again, it is crucial that your solution provider’s teams give importance and time to know your teams and how they work.
˫ A RACI (Responsible, Accountable, Consulted, Informed) matrix must be accorded upon for all sub-tasks and approvals of the project.
˫ Timelines, milestones, steering meetings and expected deliverables from both sides have to be defined and respected. It is easy to blame the solution provider for the delays but as we’ll see in the next part, SMEs’ (Subject Matter Expert) involvement is a critical element of the project success. A PLM will ultimately engage your whole design chain. You can’t afford to see it as a minor IT project.
In the next part, we’ll talk about risks most likely to occur after the project kick-off.