ECM Implementations – Why do some fail?

Recently we have been in touch with three large clients that are engaging with TSG after having failed with implementations of either a new ECM vendor or new product from their existing ECM vendor.  While we are often brought in to clean up ECM implementations, we don’t often see projects where vendors and their tools were abandoned after considerable effort.  This post will discuss some of the commonalities we found between these clients and their implementations as well as thoughts from other client situations.  For client confidentially, we won’t be talking about the specific product or client.

What is a failed ECM implementation?

Before getting into the commonalities we typically see in ECM failures, it might make sense to define what a true failure looks like.  We would describe a failure as a project that, mid-way through the development/installation effort, the project leaders decide to scrap the project and keep the old system.  The time, effort and cost put into the new system is a wasted effort.

For this post, we are not including:

• An implementation that takes longer/costs more than it was originally budgeted
• An implementation that goes into production but does not deliver all the benefits promised by the vendor

While both of the above are not best case scenarios, they are not the complete failure of a scrapped project.

ECM Failure Commonalty #1 – Thorough Reference Checks

Not conducting thorough reference checks are the most common trait with failed ECM implementations.  Too often, clients, impressed with the vendor or demo, will skip or more commonly do light or limited reference checking.  Software vendors will typically present a “logo” screen with all their clients that can give a false impression that all of the clients on the list are using the product for similar use.  We have seen that many times ECM logo clients:

• Have a significantly smaller implementation. (often just a small department)
• Are on an older (not current) product set.
• Have implemented for a different application.
• Have a significantly less complex implementation. (often 100% “out of the box” with no integration to other systems or even simple customizations)

Vendors and consultants should be thoroughly vetted via multiple reference checks for similar usage and size requirements.  Back in 2001, we had one client that facilitated a life sciences industry group on his own to talk about Documentum’s DCM product.  Rather than rely on the vendor to give him references, he used his own connections to verify other companies progress (or lack of progress) to help with his decision not to go with DCM.

ECM Failure Commonalty #2 – Software Vendor Consultants

While it might seem very self-serving for TSG, on multiple failures, we have seen clients leverage consultants from the software vendor that have substantially contributed to the project failure.  In the past, we have talked about Documentum Consulting but other software vendors are just as guilty.  Issues with consulting resources from the vendor include:

• Lack of Independence – Typically, software firms will have good and bad points about their software suite. Software vendors consulting resources typically don’t have the ability or the experience to inform the client about which components are good or bad.  Failures like stability often emerge at the end of an implementation based on bad decisions that were made at the beginning of the implementation.  Typically vendor consultants have limited experience with other ECM tools resulting in a bias for their own product as well as the inability to understand the capabilities as well as migration needs for the old products.
• How they are sold – Software sales representatives are often known to oversell software as part of the sales cycle. As commissioned resources, they can be very aggressive about getting a sale, particularly at the end of a quarter.  Unfortunately, they will also oversell consulting.  Selling the “wizard” from our “engineering” that can answer all your questions is an easy sell.  Clients should be wary of software representatives selling consulting as they tend to oversell capabilities of individuals.
• Bundled software and consulting sales – Often times, software products don’t have all the features required by the client. An aggressive software firm will promise to add these components to the core as part of a consulting engagement for the client.  While small tweaks to software might be doable, large new product sets are very risky.
• Consultant versus Engineers – Software engineers often times make the worst consultants as they are not used to the client communications, travel and other demands to “make the client happy”. Consultants need a broad skill set beyond just the technical coding capability.  Vendor consultants, that joined the software company as software engineers, might lack the soft skills needed to communicate well with clients.
• Cost – Vendor consultants are usually more expensive than other consulting resources resulting in high cost for projects.

Since TSG does provide software for our projects, we have set up our software/consulting business to try to avoid the above for our clients in the following ways:

• No commissions – we don’t have a commission model for any of our consultants that participate in sales to avoid over selling either software or services.
• No charge for software – while we are moving our model to provide for a light maintenance model, we don’t charge for our software.
• Bundled Software – as an open source provider, we do sell product enhancements and try to limit the additions to small items, not large development efforts.
• References – we provide references for our clients and consultants.

In our dealings with software vendor consultants, we have worked with both good and bad consultants.  If you are still considering leveraging software vendor consultants, clients should always check references of both the company and the consultants.

ECM Failure Commonality #3 – Internal IT Resources and Business Decision Makers

Sometimes, the fault of a failed project is the client themselves.  Typically we will see a mix of business decision makers and supporting IT resources as part of the implementation team.  To be successful, the implementation team needs to evaluate all of the different options with the business and IT team members providing checks and balances against each other.

• Business decision makers need to make sure the software meets the business needs including cost/budget/ROI business requirements.
• IT support resources need to make sure the software meets the technical requirements that results in the ability of the client to maintain, support and enhance the software.

Too often, Business decision makers will inadvertently make technical decisions (for business reasons) and IT will make business decisions (for technical reasons).  For example:

• Business – “I like this demo, let’s implement this ECM product” (despite it being unsupported, old and not scalable technology)
• Technical – “Let’s upgrade to the latest release” (despite the latest release being risky and of no new business benefit to justify the cost and business interruption)

While business decision makers and internal IT resources should be leading the effort, often times they both suffer from:

• lacking the ECM experience to evaluate differences between software vendors and tools.
• having the weakness of being swayed by a good demonstration, one likable feature or a particular sales rep.
• failing to limit user requirements and technical requirements to meet the business need that includes scope control, budget and timeframe.
• lacking the technical experience to understand the differences between technical options.
• failing to listen to third parties or references if they conflict with their own opinions.

Business and IT users should leverage multiple resources, from both inside and outside the company, to make sure all project risks are well understood and mitigated where possible throughout the project.

ECM Failure Commonality #4 – The Company, the Product and Trust

When talking to clients, often times we hear “the product didn’t do what they said it would do”.  Additional thoughts include:

• “They said they would support X vertical (Life Sciences, Insurance….) but failed to add X (Key feature)”
• “They said they would add support for X technology (Chrome, Mobile..) but it was limited or unstable”.
• “They said the new product would allow us to do X but it didn’t”
• “Product was unstable”
• “Product didn’t scale”
• “Product was too expensive to roll out to other business units”

While many of the complaints above are the fault of the software, often times there are decision points within the project to address and mitigate these risks.  As we have always advised clients, you never truly buy software, you rent it.  Good implementations involve trust of the software vendor, trust of the consultants and a long term mutually beneficial relationship where the software vendor continues to enhance the software to the benefit of the client.

Summary

We have presented our thoughts on commonalities we see in ECM failures.  To conclude this post, our best thoughts on how to address these efforts with your own implementations:

• Reference Checks – Conduct thorough reference checks both from the vendor as well as from other resources.
• Vendor Consultants – Consider neutral third party consulting resources to get unbiased advice.
• Internal Business and IT Resources – make sure checks and balances are in place to ensure that both groups are focused on their role.
• The Product – Develop risk mitigation plans based on worst case scenarios. Develop mutually beneficial long-term relationship with the software vendor.

If you have other thoughts on failures, please let us know your thoughts below: