Successful PLM approaches

Introduction

I thought I'd like to put some ideas down to help people be successful in their PLM implementations. I've come up with some suggestions I've seen that have helped me in the past, also some of the unsuccessful implementations where using these approaches would have helped.

Voice of the customer - insure buy in

Making sure that there is adequate involvement in the process is key to any PLM implementation. There are going to be many changes to the fundamental way people do their jobs in an implementation and keeping everyone on board is key to being successful. Remember that all users of the system are effectively customers and you need their buy in for the ultimate success of the venture.

All through implementation

I've seen many implementations that start off including people from various departments for example during the definition of scope and requirements. But this is just the beginning. If this is the last contact with end users the project could well encounter problems. You need to insure that there are not only regular updates on progress but substantive consultations and actual actions on people's concerns and ideas throughout the entire implementation.
I'm a big fan of conference room pilots (as you will know if you have read some of my other postings!). These allow people to see what they will actually be expected to use to do their jobs in a controlled environment. Often the first time a large number of users see the system they are going to use if during training, often the week (or two) before the go live. At this point there is really no opportunity for people to raise concerns and have them addressed. In a conference room pilot people interact with the “to be” system and can then provide comments and suggestions. These types of engagement show teams and departments

1. Things are not set in stone and can be changed/improved
   
2. The implementation team cares about the people who will have to us the system
   
3. Problems can be addressed before day one of the go live
   

Often companies plan a serous of conference room pilots in a project to allow people to see the solution evolve; for example in a data migration project an early look might to see how the migrated data will look and a later pilot might be to check processes in the new envirnment.
Insuring that people are kept in the loop can avoid embarrassing omissions and errors in the new system.

Define scope

Scope is a key factor in determining if your PLM project will be a success or not; bite off too much and you may never complete, too little and you may never show enough return on investment (ROI).

Low hanging fruit

I always propose starting PLM implementations with low hanging fruit. This way you can show some benefits and get some early momentum/successes before you try more tricky areas.
Most companies have a problem area they would like to solve but often these are not very easy to address. One area I've used in implementations is CAD data management. I would suggest working with your vendor to see what they would recommend – see other sections of the whitepaper too!

Main pain points

If you have some pain points that you specifically identified in your requirements gathering you could attack these first, but don't try to do too much at once! You would need a reasonable area and chose one where you think the team would be amenable to change and a new tool. If your main pain point is a department that has a history of pushing back on new ideas and “have always done it this way” you might have a hard sell and not get the engagement that is critical with a new tool.
A good sales pitch with a troubled department might encourage them to see that a new tool to address their problems could help, but be reaslistic.
I'm a big fan of technology, but it does not solve all problems. My example here is – if you have a messed up process all that automating it will do is mean you have bigger problems and faster – so fix processes as well as just implementing tools.

Phased approach - don't do too much too soon

Using a phased approach works well in most cases. You would need to decide what phase contains which issues and areas. A common implementation strategy goes

1. Data vaulting
   
2. EBOM management
   
3. Change management
   
4. MBOM and ERP integration/Manufacturing Execution Systems integration
   

Clearly there is not a one size fits all here and also I'm a big fan of ERP integration early in implementations. A lot of this will be determined by how mature your processes are and how much change is needed. You might already have done many of the earlier phased already.

Have a methodology

This might sound obvious, but there are a many implementations that rely on the skills of the team to work together without any structure or methodology. I used joint application development (JAD) a lot with implementations in the late 90s and I've seen a lot of newer methodologies which can also help. Just choose one and stick with it. It also helps if they are lightweight and flexible so that you don't spend all your time on the methodology documentation at the expense of the implementation.
I've seen customers recently starting to use SCRUM too and I think this could work well.

Cross functional team

I'm a big fan of creating teams where people from different parts or the business can all participate in the decision making process. I've referred to this in other white-papers too; if you impose an IT solution on people it is likely that there will be push back.
Cross functional teams are good since you need to know what problems each discipline and group in the scope of the solution need to address. Making them part of the solution insures you will not implement a solution that is suitable for most areas of the business but impossible for one area. In my experience this often happens when an “engineering” solution is “imposed” on “manufacturing” folks and does not fit in with the way the manufacturig team produces actual product! If manufacturing folks were part of the team they can direct folks away from these common pitfalls.

Experience sharing

The old adage of not “re-inventing the wheel” applies to PLM solutions too. Unless you are in some niche area it is likely that someone someowhere has done something similar before. There is of course a fine line between experience sharing and stealing/plagiarism but learning from other like minded individuals can always help.

Talk to other companies to learn from them

Industry associations and vendor user groups can be great forums for discussing problems and understanding how other people have developed solutions.
I'm a big fan of these types of discussion since there are people at the coal-face who are trying to make these solutions work in a production environment who you can talk to.
If you can't find one of these groups locally you might want to consider forming one yourself. These groups are very valuable. Also they will show you that you are not alone and that others have the same problems/solutions/requirements as you do.
Sometime you will find someone local to you who is very experienced and can help mentor you if you are new to the field.

Work with vendor on best practices

Most vendors want you to be successful with their products! So ask them for help/guidance. The best time for this is during the pre-sales process, after buying it might be more difficult. Vendors can also help you in getting in touch with other users of their tools. It is always worth asking them to help you with establishing links with other customers of their tools. Once established try to make regular contact with other customers e.g. on a quarterly basis to find out how they are getting along.
Establishing good contacts with vendor experts is also a great idea to help get experience sharing going. This can be tricky with the implementation teams of a vendor since their business is consulting. Be pragmatic here – if you need a lot of help it really is worth considering paying the vendor to help you rather than risk failure of the project.
There can be a happy balance; for example if you are implementing some new functionality in a vendor's tool they may risk share with you and supply free (or low cost) implementation support. As always though be sure that you look out for your best interests here...

Understand what problems you are trying to solve

I think a key pointer to success in implementations is to insure you know what problems you are trying to solve and focus on these areas. Make sure you clearly document these and make sure there is buy in from senior management (and the vendor if at all possible). I mention ROI later, but be as specific as you can about the problems and cost savings expected.

Create Engineering/Mfg/Quality/Production solutions not IT ones

As I mentioned in the cross functional team section insure you make business solutions rather than ones that are pushed down from IT departments. You need to insure that the voice of (internal) customer departments are heard.
The more that a solution has a consensus between departments, the more likely it will be a success.

Manage risks

Managing risks is not just about having an issue list! I see many projects (not just PLM ones) where risk mitigation plans are either superficial or non existant. When documenting risks insure you have risk mitigation plans and also estimates of the likelihood of a risk occurring and the impact if the risk does happen.

Identify and measure metrics before and after implementations to insure ROI

This fits into the problem statements section. I am amazed at the number of projects implementing new tools or upgrades where people come back after go live and say X takes longer now than before we upgraded/implemented something. Often these comments are subjective since no one times how long X or Y took before the new tool was introduced.
If you identify problems to solve or are implementing or upgrading something be sure to benchmark the existing system before pulling the plug on the old system. Make sure you define good use cases to measure to demonstrate the ROI. The same goes for upgrades. It is better to discover the upgraded system is slower for X, but MUCH faster for Y and you do Y a million times and X only once before going live so you can be prepared for user comments. Again conference room pilots can help in determining these “To be” issues before you go live.

Communication plans

Keeping everyone in the loop is key to successful implementations. Develop a good communication plan. Decide who needs to know what and when and how you will get the message across. Communication plans cover a multitude of areas from broadcast messages that “something” is happening down to training plans and seminars to explaining what to do before leaving on the day before the go live and how to work when you get in after the go live.

A good plan well executed will alleviate a lot of the fear, uncertainty and doubt (FUD) that goes along with change and fear of the unknown.