Implementation methodologies for PDM
In my 15 years of using PDM I've seen lots of ways of implementing PDM/PLM.
These vary from no methodology to rigorous ones.
The first question is why do you need an implementation methodology at all?
The reason you should use one is quite simple - reproducibility. Most people will probably choose a partner to assist in their deployment - often this will be the company that sold them the solution, or it may be a partner of the software developer/supplier. In this case it is essential to be sure that the service you are paying for has some track record of success. If a company does not use a methodology to deploy their solution it will be very hit and miss as to whether your implementation will be a success or failure.
The main failure of PDM implementations is scope creep. The technology lends itself to overstretching and too ambitious views of what is achievable in an initial implementation. So a good choice of methodology would be one where the scope of the implementation is well controlled. So the second question is how does the implementation methodology manage scope creep? One of the best ways I have seen is to make sure that the scope is firmly identified early on in the deployment and is re-visited frequently - in JAD (joint application development) it is agreed on in stakeholder meetings and presented to senior management at key stages in the implementation cycle. When we were working on deployments it was the first thing we did: and subsequently revisited at each checkpoint meeting.
One other problem I've encountered is companies constantly changing their methodologies - this can lead to confusion in the implementers and also means that reproducibility on deployments is compromised.
Some methodologies rely on too much documentation. This can look impressive, but can often hide the problems in a deployment. It is good to document issues and have a good statement of work (showing main deliverables and who is responsible from them); but other documentation can be redundant.
...
These vary from no methodology to rigorous ones.
The first question is why do you need an implementation methodology at all?
The reason you should use one is quite simple - reproducibility. Most people will probably choose a partner to assist in their deployment - often this will be the company that sold them the solution, or it may be a partner of the software developer/supplier. In this case it is essential to be sure that the service you are paying for has some track record of success. If a company does not use a methodology to deploy their solution it will be very hit and miss as to whether your implementation will be a success or failure.
The main failure of PDM implementations is scope creep. The technology lends itself to overstretching and too ambitious views of what is achievable in an initial implementation. So a good choice of methodology would be one where the scope of the implementation is well controlled. So the second question is how does the implementation methodology manage scope creep? One of the best ways I have seen is to make sure that the scope is firmly identified early on in the deployment and is re-visited frequently - in JAD (joint application development) it is agreed on in stakeholder meetings and presented to senior management at key stages in the implementation cycle. When we were working on deployments it was the first thing we did: and subsequently revisited at each checkpoint meeting.
One other problem I've encountered is companies constantly changing their methodologies - this can lead to confusion in the implementers and also means that reproducibility on deployments is compromised.
Some methodologies rely on too much documentation. This can look impressive, but can often hide the problems in a deployment. It is good to document issues and have a good statement of work (showing main deliverables and who is responsible from them); but other documentation can be redundant.
...
Comments