Planning PLM projects and upgrades
Overview
I wanted to discuss some ideas on PLM Projects and Upgrades that I've seen over the years. I've been involved in upgrades as a developer, a consultant and even as an interested observer watching customers do their own projects/upgrades.In house or consultant?
A number of factors will influence the decision of whether to use in-house resources or consultants (either vendor or independent/partner). The risk sharing of using a consultant and also the previous experience of the consultants can be very helpful. It's also helpful if your team does not have the necessary skills.For a customer who has lots of experience and proven success you would probably choose to do things yourself, unless it is a new area where you do not have experience.
Cost versus risk always comes into play in these decisions too; a vendor led project can be costly, but (usually) the risks of a vendor led activity are less since if things are not straightforward they will have more chance of getting development assistance or fixes.
Partners can offer a half way option to a company. They have more experience than internal people would, but are cheaper than using the vendor.
New projects
By “new projects” I mean either starting a new PLM system from scratch or implementing some new functionality or project or adding a new group whose methods or tools are different to what is already in place.Implementation methodology selection
The first real decision in a project is what methodology to use. I think it's easy to just dive into a project but (depending on the size of the project) there is a lot to be said for choosing a methodology and planning accordingly. I'll probably develop a complete paper on methodologies down the line, but for now a few of suggestions/ideas.I've found Joint application development (JAD) as useful in the past for a couple of reasons. I liked the way it restricts scope creep and also involves the business in making decisions on the project/implementation.
Conference room pilots are good for insuring you deliver something that the business can use and are happy with. With iterations it also can show that the voice of the customer is being listened to during the implementation process.
I'm interested in seeing how the SCRUM methodology would work in PLM implementations – but I need to research this area more before commenting further.
Clearly the decision of in house versus consultant will also influence the choice of methodologies as well. Many vendors have their own methods and (hopefully) a proven record of success with them!
Choosing product/vendor
Wow – this is a whole chapter of my upcoming book! Needless to say – choosing a tool needs a lot of investigation outside the scope of this whitepaper.I'd say it really boils down to two things: technology and can you work with the vendor/partner. If you answer yes to both of these you are off to a good start!
What to tackle first
I always suggest “low hanging fruit”. Choose something that will be (relatively) straightforward but also shows some benefits. CAD Data vaulting was one of the favourites for my implementations. You gain benefits from data sharing and re-use; plus Engineering are usually interested in improving this area.What not to tackle first
Don't take on too much at once. It is easy to get sucked into new technology and “try to eat the entire cheesecake” in one go! Be realistic about what you can accomplish and also what you can sell to the business. Many times you can do a larger project second after demonstrating success with a smaller initial project.Things to avoid first in my opinion change management, bill of material management (multi-bom aspects).
Upgrades
In many PLM systems upgrades present a lot of challenges. Many times you are forced into them by the vendor (to fix an issue or continue with a supported platform).Never underestimate the efforts needed for an upgrade. If it is your first upgrade check with other customers about how they managed during upgrades – see my previous whitepaper about building relationships with other companies using the same tools as you. It is amazing what you can learn!
Planning
Do plan for a number of rehearsals. Insure that you develop good test plans and practice back-out strategies in case something goes wrong during the final production upgrade.Rehearsals give you an idea of how long the upgrade will take – this is useful for identifying windows for an upgrade e.g. over a holiday weekend or shutting down your system when there is a quiet period to reduce impact to the business.
Develop a detailed plan of all the steps with best and worst case timings. Also for the key steps you should develop risk mitigation plans.
Insure your vendor knows when you are doing your upgrade and also ask them about weekend technical support (if you don't normally have this). Weekend support is really good if you hit a snag on the production upgrade that you did not see in the rehearsals.
Insure you communicate with the business about outages during the upgrade and get their buy-in. There may be some urgent project that was also planned for the production upgrade period so do not assume your first choice of dates will be acceptable to the entire business.
Lessons learned from previous upgrades
I've seen many companies learn from previous upgrades. Insure you document issues when you do an upgrade and how you overcame them. Documenting this type of experience will help in the future and will insure you can still benefit from the experience even if the people who did the previous upgrade have left the company.Performance and unit testing
Whether it is a new project OR an upgrade testing is critically important. Insure your testing covers all the main areas of the functionality you have or will add. If adding new areas insure that there is sufficient coverage of existing functionality. You don't want to break anything!Testing is really important both as a project goes along, but also during a production go live period. This is really the first time in many cases where all the parts are put together.
Insure that performance is tested.
For new functions insure that the business has tested the functionality and are happy with the performance and workflows (as mentioned earlier conference room pilots are good here).
For upgrades insure that there is no loss of performance on use cases important to the business. Time these use-cases on the pre-upgrade and target system before the production upgrade and also with the new post upgrade system. It is often good to use multi-user load tools to simulate the effects of real world usage levels of the system. Clearly you should just replicate the user loading you see in an average day or for the planned usage levels after adding new users and functionality.
If you seem large degradations in performance you should investigate these before go live. It is much easier to address these before the go live rather than have hundreds of disgruntled un-productive users and their managers pushing you for resolution. It is almost always better to delay a project and fix performance than suffer poor production performance!
Comments