If you are the CEO or the Engineering VP of a fast-moving successful corporation, youíll remember that some time back you were asked to agree to a large investment in a new type of technology - a Product Data Management (PDM) system. You were told that PDM was a strategic technology, and given examples of how similar corporations were investing in PDM.

Youíll remember that you were told of the many benefits that would result from use of this technology:

You agreed to a project to implement PDM as these benefits were exactly the type of improvements you were looking for, and you could see that they would complement your Business Process Reengineering initiative. In addition, the project promised an 18-month payback.

Since then youíve had a lot to do - acquisitions, bringing new products to market, hiring and firing, preparing plans and budgets, and communicating financial results. So youíre probably not aware of the progress of the PDM implementation project. Perhaps you should take a close look - for 5 out of 10 PDM projects fail. The problem isnít the technology - for many PDM projects do succeed and do provide benefits in areas such as document management, engineering change management, workflow automation, component management and reuse, and Concurrent Engineering. PDM project failure is usually due to a poor approach to implementation.

Youíll probably find it difficult to know if your PDM project is succeeding or not. Itís not likely that the project team members will tell you that the project is a failure - usually they want to keep their jobs. And itís not likely that the PDM system vendor will tell you the project has failed - the vendor is unlikely to want to lose the expected revenue.

So how can you know if the project is succeeding or failing? One tell-tale sign to look for is the publicity given to the success of the project. If no-one is shouting about project success then thereís a high probability that something is wrong - so you need to take a closer look. You may also learn about lack of project success from the Product Managers who volunteered to use PDM on their projects. They are under pressure to get products to market on time and within budget, so theyíll be badly affected by the failure of the implementation of PDM. They may identify lack of PDM availability as one of the causes of their problems.

People may not openly refer to the PDM project as a Ďfailureí, but if the PDM system doesnít work, or it doesnít meet specifications, or if the specifications, objectives or scope have been changed since you agreed to the project, or if project meetings are being postponed or not reported, then failure may be the word to use.

If you do find that your PDM project has run into problems you have three basic options:

The first option isnít going to solve anything. Itís highly unlikely that the people whoíve failed can get themselves out of their problems single-handed. If they could, they wouldnít have got into them in the first place.

The second option may look attractive, but is likely to lead to another failure. Itís an option that implies that all the causes of the problems lie with the people in the project - but thatís rarely the case. A lot of the causes are usually related to corporate and departmental culture - and they wonít be solved by changing the project team.

Thereís a lot to say for the third option - getting someone experienced to review the situation and set the direction for the future. Itís much easier for an experienced outsider with nothing to fear from internal politics to come in, investigate project progress, report on the true project status, and put the project back on track. This option is likely to be quick, low-cost and successful. Above all though, it offers you the best chance to achieve the big benefits you were promised.


Copyright (c) 1998 John Stark