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:

• reducing product development cycle times by 25%
• improving quality by a factor of 10
• reducing product costs by 10%
• reducing product development costs by 10%

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:

• do nothing and hope that the project team will put things right
• restart the project with a new project leader and/or a new project team
• hire a consultant to tell you what went wrong and what needs to be done to put things right

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.