Some lessons out of ECM vendor demo hell

Self immolation is a rare, some may say mythical event.  Yet in the world of content management it is more common than you might think. For example, I witnessed three major ECM Suite vendors burst into flames of their own earlier this year during a week of day-long demos for a large customer.

Many lessons came out of the week, both for vendors trying to sell high-end systems in a tough market, and for buyers ensuring they don't commit to the wrong technology or supplier. And in ECM you do commit: for a very long time and a hell of a lot of money. You almost never have the option to turn back or change your mind.

To give a bit of background to this story, while protecting client confidentiality and the innocent (if there were any innocent parties), let me give you the following details. The client is a large and very well established "blue chip" publisher. Let's call them Acme Inc. The budget for the project will come in around $2+ million for software alone, as Acme deals with hundreds of millions of documents, with maybe 300,000 chugging through complex workflows at any one time.  In short it's a typical large (though not huge) ECM situation.  

Due to complex legacy application dependencies and various in-house technical complexities, Acme shortlisted Alfresco, Oracle, IBM, Objective, and EMC Documentum.  Together we reviewed a couple of other systems, but due to various support issues were unable to shortlist them.  Of course these five players often compete against each other in larger deals, so frankly the shortlist was no real surprise. In the end, three of the five elected to bid and demo. I'll call them Vendors A, B, and C.

Acme wrote an excellent RFP: concise, focused on scenarios.  In fact one vendor went as far to say that "This was the best RFP we have ever seen...life would be a lot easier if they were all like this." And indeed they are right; hundreds of pages of check-lists deliver no value to anyone.  Acme went further than most by providing a detailed guide to how they wanted the onsite demos to run. This included a precise agenda, and very detailed demo cases (no PPTs).  Acme could not have done more to help the vendors.

Yet the three days of demos were close to disaster.

Vendor A arrived and got off to a storming start, with an excellent intro that showed deep understanding of Acme's needs. The senior account rep then turned to the specialists to run the demos.  And for the next three hours a group of 30 Acme managers watched a platform die slowly on stage. The senior account rep may have understood Acmes needs, but the ECM specialist was clearly out of the loop.  When the BPM specialist took over it only got worse. Instead of showing Acme how to build and manage business processes, he tried to construct a Web Service. Nobody figured out why.  Perhaps that's what he knew best. Things got worse when the demo moved to the part where Vendor A had to build a simple GUI.  Their GUI-building scenario revealed byzantine processes dominated by a proprietary scripting language, and the end result was a blank screen reading "Remote Server does not Respond."

Could things get any worse?  Yes they could.  At a wrap-up session with a smaller group of decision makers, a short critique of the day was provided, but Acme threw a bone to them. "Clearly things didn't go well and the ball is in your court now..." The most senior Vendor A rep proceeded to throw a hissy fit, became exceptionally rude to the Acme team, and then stomped off early, leaving junior salespeople to try to pick up the pieces.  

So, this vendor displayed exceptional arrogance, was rude and demeaning, delivered a horrible demonstration, wasted the time of 30+ managers, and qualified themselves out of the process in spectacular fashion.  Ironically Vendor A probably had the best technology fit among all the competitors on the short list, but nobody at Acme ever wants them to darken their door again. This particular vendor has a reputation for arrogance and bullying. That is a tactic that may have sufficed in the past, but does not work in a buyer-empowered market. A bit of humility and co-ordination would have gone a long way, but clearly Vendor A didn't think they needed to bother.

Lesson #1: Major vendors are simply not used to the buyer being in the driving seat. They are still used to taking a few senior people out for golf, and then coming along with a canned whiz presentation. But that is as much the buyers' fault, as you have acquiesced to that preposterous situation for too long.

Lesson #2: If the vendor with the best technology can't grasp your needs in a full-day pitch demo, they are unlikely to make a good match over a multi-year relationship. Although you can over-emphasize "chemistry" in the sales phase -- after all, copasetic salespeople will go away when the real work starts -- the vendor's preparation is an important indicator of how good a match they think your project makes.

Then came Vendor B. They did fine at first, demonstrating their capabilities by following the scenarios faithfully. But a day is a long time -- enough time for the audience at Acme to start to see the serious complexity of the product emerge.  Again proprietary scripting languages emerged at inopportune moments, and the bewildering complexity of the BPM modeling environment left many in the audience fearful of what might happen if this thing was let loose within the organization. That said, the product worked, and Acme got to see it warts and all -- a good thing for both parties.

Where things really went wrong was during the business discussion.  Vendor B was at a loss to explain the rationale for seven line items in their bid, totalling an additional $150K. Then they admitted (or rather we pointed out to them) that they demonstrated various essential modules without including them in their financial proposal.  The defense from the vendor was, "It's difficult for us since we have nearly 150 items in our price list." Uh-oh.  The buyer was left wondering if the complexity in the company's pricing was deliberate. For while other vendors bundled all the essential functional requirements into a single priced package, Vendor B offered up nearly 30 line items.  And yet in the end, the quote contained items Acme didn't need, while missing key modules that were crucial to fulfilling the demos.  Acme could actually cope with this product's technical complexity (though many could not), but the pricing discussion left Acme wary and distrustful.

Lesson #3: Always make sure to align technical and price proposals, and continue to do so all the way through the selection process. Vendor product lines are complex, their own salespeople frequently don't understand them, and, unfortunately, sandbagging is rife in our industry.

Now Vendor C. All they had to do was get to the end of the day in one piece and they could proceed to the next phase.  Like the others, they off to a decent start.  The first couple of hours (with the exception of an excruciating sales pitch intro) went very well. Acme selection team members were looking around the room with eyebrows raised, seeming to say, "Now this is more like it!" Vendor C followed the scenario scripts closely, eased by advance preparation in developing an impressive mock application. Unfortunately, this application seemed to be riddled with bugs and simply ceased to work after an hour or so into the demo. From there, things went from bad to worse, and Acme never got to see everything they needed to review.

Lesson #4: There's a reason you build demo use-cases and make vendors stick to them. It allows you to actually test the solution, and enables you to compare complex platforms in an apples-to-apples way.

For Acme, all the pain was not in vain. The demos were difficult to watch at times, but Acme really got to learn about the vendors and products -- the good, the bad, and yes the ugly. They saw three teams work under immense pressure. In one case it was easy to say "Your fired!" Yet out of the other demo debacles Acme probably found an acceptable supplier.

Perhaps more importantly a very clear picture emerged of the work that lies ahead. Acme is in a much stronger position than before. They have a deeper understanding of three very different technologies and three very different vendors -- offerings that according to the Magic Quadrant all sit side-by-side.  Acme also has a much more profound understanding of their own requirements and capabilities.

The selection process isn't over. Acme will continue to test carefully before they spend their money, but I have high hopes for a successful project. Yet without the blood and bruises of the demo week, the chances of success would have been far lower.

Other ECM & Cloud File Sharing posts

ECM Standards in Perspective

In real life I don't see ECM standards proving particularly meaningful, and you should see them as a relative benefit rather than absolute must-have.