A reader recently asked me to share perspectives on successful PLM deployments – what are the common themes across successful implementations.
The thought that comes to mind first and foremost is the upfront planning. By planning I don’t mean the development of a project schedule or of the system requirements - it’s the investment in taking the time to really make sure the business justification is well understood.
There is a process I have used repeatedly that involves managing expectations very carefully before engaging the software vendor. Too often it seems that the PLM decision is reactive – as sold by the software vendor, not based upon a clear set of business drivers.
To be successful with the process steps executive level endorsement is critical as it has a lot in common with a business process assessment in that it probes the entire organization, however, the assessment is focused upon the product record, not operations or production. The challenge for many however having someone who knows PLM well enough to be able to see the opportunities is often not a skill set contained within your company. The cost of having consulting done for this stage is often well worth the initial investment when taking into account the overall investment you may end up making in the implementation.
The single most significant thing to be done is to look at the PLM project with the same kind of rigor as a product development project. Too often IT projects (coming from a non revenue perspective) fail to use simple PMO types of processes. It all starts with the business case phase.
But on the successful implementations – the business case stage would include the following activities:
- Take your organization chart and mark every department that handles product related information, identify key external partners that are also interacting with your product records (note – do not count your financial transactions here – just focus on the product information).
- Evaluate each department around it’s handling of product information or the product record look for manual transactions, duplicated entries, printouts, markups, shadow databases, network storage of product information. Include examining what IT infrastructure components are involved.
- Dollarize the impact of the “non-value” added activities associated with these product record related transactions – the caution is that executives will readily let you turn this into a blame game rather than a financial business case – so be careful how this is framed (Read the Dollarization Discipline for more on this).
- As in product development project management practices – develop a high level specification (similar to a Market Requirements Document) that ties business objectives to the functionality requirements – this is NOT where to say it must run on xyz database, or have n tier architecture. This is a market level specification for executive consumption.
- Obtain executive buy-in for the next stage – do not go too deep into specification definition until this phase is approved.
