In this exclusive guest blog, Rob Smith, Operations Manager at the Product Development Partnership and fully-qualified solicitor in England and Wales, examines some of the common pitfalls and challenges of implementing a PLM solution.
He also goes on to look at the differences that exist between implementation methodologies, and weighs up the strengths and drawbacks of each.
The many benefits of implementing a product lifecycle management (“PLM”) system are well-known and well-documented (in publications like the WhichPLM Annual Review 2012) and I do not plan to rehearse them here, but one primary value of PLM I would like to draw attention to is a reduction in the lifecycle time of products (whether it be white goods, apparel garments, or accessories). The adjacent Figure 1 is an illustration I often use to demonstrate this improvement. It shows how, once implemented, a PLM system provides a platform for future process improvements. Following the initial ‘go-live’ of your first PLM system you will have achieved a new cycle time for your products (i.e. time from design to fulfilment) which is definitely going to be shorter than what you had previously. You may require further down the line that your cycle time needs to be more competitive (particularly in fast fashion) and already this is achievable by having PLM in place as a platform; You can further optimise particular areas of the lifecycle in bite-sized projects without worrying about the knock on effects down the line.
For example you may use Corel for your apparel product design and may even send Corel files along with your tech pack to suppliers. Without PLM in place, replacing the design software would be an issue that would impact at different points in the lifecycle and turn into a larger project than anticipated and/or required. However with PLM active in the business, these issues are minimal as you will have dealt with these bottlenecks in the project, meaning that suppliers now access the product detail in a standard format delivered from PLM without any additional design files. Replacing the design software is as simple as purchasing the licences, re-training the design team and configuring the collaboration to PLM at the point of design (most vendors now offer this OOTB). It is worth re-iterating that these process enhancements becomes far easier to realise once you have the PLM platform in place, but of course actually implementing that platform to start with can be a challenge in itself – one that, if handled incorrectly, can cause significant problems further down the line.
[quote]I can guarantee that the cost of getting it wrong will always outweigh the cost of doing it right first time.[/quote]
So, how should organisations looking to achieve cycle time reduction (amongst the other benefits of PLM) approach an implementation?
When implementing any new software solution for a client, the Product Development Partnership (“PDP”) will look at two different approaches: a stage-gate model and a sandbox model. Both can be directly linked back to standard software project management approaches: waterfall and agile, respectively. The two differ from each other quite substantially, however, so I would like to set out the major points of each:
- Within the stage-gate model the consultancy would build the process requirements and the solution specification in advance, through user workshops and requirement gathering techniques. Once a clear understanding of deliverables is reached, the consultancy would then move onto solution configuration, which occurs in a single sitting and is always based on the original requirement specifications.
- Using the sandbox approach, the consultancy would provide a client with a basic system and then run a number of shorter user engagement exercises and workshops to gain insight into the configuration and customisation required. As well as providing that insight, these workshops also serve as an opportunity for configuration to take place on an iterative basis rather than in one single stage.
Both implementation methodologies have their benefits and drawbacks, and there is no ‘one size fits all’ approach. Different clients have different ways of working, and the implementation of the PLM solution itself should be as unique as the business that will be using it. Broadly speaking, most businesses will already have an understanding of which methodology would be best suited to their unique requirements – basing this on corporate culture and the availability of internal resources, both of which are vital for a successful implementation.
[pullquote_right]A PLM project is not an easy project to manage. It takes significant planning and a significant investment in resource to ensure the correct amount of due diligence is undertaken.[/pullquote_right]Some clients prefer the systematic approach and the ability to clearly define deliverables at an early stage. Generally these will be organisations with a more risk-averse culture, where an understanding of system boundaries can be extremely beneficial. Conversely, other organisations may wish to change the orientation of their implementation project linked to take account of advances in technology, or to provide more flexibility for the internal teams handling it? Still other businesses prefer to sit somewhere in the middle, with a bespoke project methodology which tries to deliver both flexibility and structure.
Whichever approach is adopted, the choice of implementation methodology is something that should not be taken lightly. Planning the ‘plan’ and structure is just as important as planning the actual project, and, as with the selection of the solution itself, this choice of implementation approaches warrants significant resource and due diligence from the internal project team.
That said, irrespective of the chosen implementation path, there are a number of potential pitfalls and concerns that are common to both, and that can easily be avoided where proper implementation planning is conducted:
Strategic importance – Treat a PLM system with the importance it deserves. Within the majority of businesses (certainly 100% of manufacturing business), a PLM system (or PDM in times gone by) should be treated as one of the key strategic business IT systems (alongside ERP, CRM and SCM). It is not just a solution brought in to assist the design team, or a solution designed to make product development easier to financially qualify for the finance team. It is a cornerstone of your business infrastructure, and one that will impact over 75% of your employees in one form or another.
The executive management team should fully understand the benefits of the project and evangelise by example. It is much harder to qualify the benefits that PLM can bring to business when compared to, say, ERP; and let’s be honest most of the time we are talking about financial benefits or efficiencies translated to financial returns. But if you don’t have the support of all of the executive team, the implementation (regardless of methodology) will become much more difficult – most of all because PLM will most probably bring about change management, and change management is not something that is easily done without that level of executive support. The consultancy would always advise that implementation project leaders take the time to explain the benefits of the PLM system to their executive team or co-directors and ensure that they share the same common goal.
[quote]When we undertake projects, these kinds of scope changes come up frequently – and they can range from the sensible to the absurd.[/quote]
Best practice – Every business is different and in terms of internal processes, every business will implement a slightly different process in order to achieve the same goal. This is perfectly acceptable and PLM should be flexible enough to cater for those specific process requirements. However that doesn’t mean to say that clients should simply map their processes ‘as-is’ to a PLM system; quite the opposite. Implementing a PLM system is a fantastic opportunity to go back to the roots of the process and question ‘why’? Why are we doing this the way we do? What is the objective of this process? Do we really need all these steps? How can we make this process leaner and more efficient? Adopting a best practice approach (typically delivered through most out of the box solution configurations) to process standardisation will nine times out of ten, actually provide the framework for achieving process objectives without a significant investment in re-engineering consultancy. If a business feels that it should deviate from best practice, then the consultancy would advise it to perform a GAP analysis and provide the business case for why their business requirements are different. If there are other efficiencies and savings that perhaps aren’t as obvious then of course the organisation should ensure these are catered for. However these deviations often take the form of: “John in accounts prefers an Excel print-out that he can annotate because that’s how he has done it since 1997”, which is indicative of inefficiencies in the business itself, rather than the solution.
[pullquote_right]Remember that PLM is not just an internal system, but rather a system that will also influence your supply chain around the world.[/pullquote_right]Return on investment (“ROI”) – In most cases this will have been a requirement of the initial solution pitch to the business CFO, but it is always worth ensuring that ROI calculations are well thought out, and that sufficient time has been invested in building the structure that will help to contain and quantify those returns. This will entail looking beyond direct cost benefits and taking account of the significant productivity gains that come with the aforementioned reduction in cycle time and improved collaboration – not just internally, but throughout the supply chain! Furthermore, an ROI analysis provides an opportunity to look at creating achievable profit margins and revenue growth, as these two facets of business will definitely be impacted by the PLM implementation. While these are unquestionably the major areas in which PLM can be expected to deliver value, I would always advise businesses not to forget that PLM, properly implemented, can present a number of value opportunities and potential optimisations to existing business initiatives. Finally, once a PLM project is underway, organisations tend to neglect their ROI analyses as the project has already been signed off. This can lead to a situation where necessary steps to achieve key returns are neglected – delaying the expected return on investment for the project as a whole. I would always advise business to look back over their ROI analysis both during the implementation and once it has been completed, to see where the system fulfilled the initial expected returns and where it may have fallen short.
Stakeholder engagement – As I mentioned earlier, a PLM solution will eventually make its impact felt to most members of a workforce. If those end users do not adopt the solution as standard practice (or do not use it as envisaged) once it is live then there seems little point in putting it in in the first place. From our experience, the optimum way to achieve employee sign on is to get those end users engaged early, and keep them engaged throughout the project. We would always advise implementation teams to keep their users abreast of the benefits of the new solution, and ask for their input into its delivery. If there is a contingent of users who seem opposed to the new system, then it is the role of that implementation project team to try and understand their concerns. Some people just don’t like change or the prospect of change, and the easiest way to overcome that is to engage them and make them part of the process. Remember that PLM is not just an internal system, but rather a system that will also influence your supply chain around the world. The end goal for almost all PLM implementations is the creation of collaborative supply chain system in which suppliers can access part of the system to obtain the information they require (or that the business may require of them) at any time, so the PLM project team should ensure that they talk to key suppliers and understand what limitations they may have. If anything, they may find that the large majority of their suppliers already use or are familiar with a PLM system, which can have significant training benefits later in the project.
Scope management – This is one of the main problem areas for PLM projects, and one that we often see in our role as consultants. At the start of the implementation (whichever methodology has been adopted) user workshops will see the project team inundated with requests for functionality from their user groups. Of course the team will want to ensure that they are delivering a system that benefits the business as a whole, and it is a great feeling knowing that you are delivering something that your peers want, but if not properly managed, this pervasive desire to improve can get slightly out of control. For instance, when first implementing a PLM system, virtual merchandising or Adobe Illustrator connectivity are exciting and productive items to have, but the project team should ask themselves whether both are requirements of the current project scope. The team should examine whether those items will provide the greatest returns in comparison to all the other functional deliverables that need to be managed alongside them. It is the project team’s role to ensure that they retain a clear focus on what it is the project is designed to provide, and also to ensure that they try not to deviate from it too far. Of course, those adopting an agile sandbox approach will be open to make some of these changes as the implementation proceeds, but the basic principles still remain: What is the benefit to the business? Is there such a short value window that we have to do this in this current phase? Will it provide significant value returns to the project for the additional time and resources that must be spent to realise it? When we undertake projects, these kinds of scope changes come up frequently – and they can range from the sensible to the absurd. Put simply, we ask for the request and the requesting party to provide a business case for each such change. Again, nine times out of ten they fall back to the category of ‘Nice to have’ rather than ‘Must have’; and the ‘Nice to have’ requests are far easier (and ultimately cost effective) to deal with once you have a functional system up and running.
As I hope I have articulated here, A PLM project is not an easy project to manage. It takes significant planning and a significant investment in resource to ensure the correct amount of due diligence is undertaken. Once the project is on-going, you’ll find the resource investment will increase significantly and added complexities that you never possibly imagined will surface. It is a real challenge to ensure the project meets both the planned go live and budget expectations, because this is an all-encompassing system that requires involvement from every aspect of the business. A PLM project can also be an expensive project to implement, but no matter how you stack the figures, one thing I can guarantee is that the cost of getting it wrong will always outweigh the cost of doing it right first time.