All engineering software vendors publish case studies about successful clients and projects. Good case studies help others understand the specific value a software product or service can be. But what about projects that nobody wants to talk about?
Two recent articles here have discussed the business value of legacy data, and how to decide what data is worth putting into the new PDM.
- Understanding the Business Value of Legacy Data, Part 1
- Understanding the Business Value of Legacy Data, Part 2
Today I want to tell you about an engineering legacy data project that will never make it into a case study. They say experience is the best teacher, when it comes to failure I think it is better to observe it second hand than to experience it directly.
By the way, I know this is a guest post for Synergis, but this case does not involve Synergis Software or any of its customers. I am going to be intentionally vague to avoid embarrassing those involved and to avoid violating confidentiality agreements.
A world-class manufacturer with high brand name recognition hired a consulting firm to prepare engineering data for a migration. More than 250,000 CAD documents (from three different CAD products) needed to move from a PDM (product data management) product in maintenance mode to a newer PDM from another vendor. The manufacturer was changing PDM vendors, but not CAD vendors, so there was was no need to convert CAD data—except for a requirement to change job numbers assigned by the CAD product to a new system created by the client as a result of acquisition. The consultant had done this type of project many times, and considered this job to be of medium size and complexity.
The consultant prepared a detailed report that clearly explained the scope of work and steps required for a successful migration. The report included step-by-step explanations how the consultant would manage:
- Available resources (human, hardware, software)
- Timeline issues
- Backup and recovery
- The need for “data cleansing” (making sure all data was tested and edited if necessary for quality and to match the required parameters of the new PDM tool)
- Quality assurance
The contracts were signed, and the project begun. Confidence was high; the manufacturer even agreed to be the subject of a case study about the migration project.
About half-way into the process, the client told the consultant to stop. The consultant was taken by surprise, but quickly found a way to halt the process so that it could be resumed with a minimum of redundant work. That was in 2011. Today the migration is still on hold. The page reserved on the PDM vendor’s web site for the case study is still online, but there’s no case study to read. The manufacturer is still using the older PDM system it wanted to discard four years ago.
What happened? It wasn’t cost; the budget was well within guidelines. If completed the consultant’s six-figure fee would have represented perhaps 5% of what the manufacturer spends in a year on engineering IT. It wasn’t complexity, nor the quality of work. It turns out the manufacturer didn’t have a clear strategy or top management buy-in.
There were clues from the beginning. In a pre-study prepared for the client, the consultant noted how the client’s business requirements were not complete, but that enough information was offered to allow the project to proceed. The consulting firm also warned that all CAD files should be regenerated and renamed, but the manufacturer did not agree to this additional step in the migration process.
I see two obvious lessons in this failed project. One, when your consultant raises issues, pay attention! The consultant wanted the customer to be more specific about business requirements and to allow for a complete data cleansing process (regenerating CAD files). But being indecisive won over being thorough.
The second lesson is about leadership. Those making the decisions should have recognized the lack of top management support. When somebody in a mahogany office finally realized the project would not deliver results with 100% confidence, things came to a screeching halt. Today this manufacturer is still debating internally about how to proceed.
Both these lessons come from self-inflicted wounds. The consultant did what it could, but this manufacturer did not value the decisions coming from its engineering IT people enough to trust them to do the work right, and to give them the budget to match. Regenerating CAD files was not in the deal because the manufacturer thought it would be trivial to do it themselves as needed.
The final summary of this botched project is simple. When you choose a partner, choose one you know you can trust and then give them the trust they deserve. If you have internal issues, solve them with action, not indecision.
Randall S. Newton is the principal analyst and managing director at Consilia Vektor, a consulting firm serving the engineering software industry. He has been directly involved in engineering software in a number of roles since 1985. More information is available at https://www.linkedin.com/in/randallnewton.