<!-- Content Here -->

How to make the most out of a vendor demo

After you watch a couple of vendor demos, it doesn't take long to realize that the performance of the demo (how well the presenters know the product and how well they understand and connect with the audience) plays as much a part of the product impression as the quality and the capabilities of the product itself. Given that the sales team probably is not going to be around during your implementation or when your users first start using the system, this should scare you if you are basing your selection on the product demo. While it is important that a software vendor cares enough about your business to put some thought and effort into showing you the product, you also want to build your system on the the most suitable product. Here are some tips to manage vendor demonstrations that will isolate the important aspects of the vendor and the product and filter out the extraneous information that may confuse or distract you. For those software vendors out there, I hope that you read this and also Tony Byrne's advice.  For people selling and evaluating open source, there are some slight nuances that I will mention at the end but probably cover more thoroughly in a different post.

Preparation

A successful demo is all about preparation. You need to prepare the vendor (or systems integrator or in house staff if you are evaluating non-commercial software) with the information they need so they can do their best. You also need to prepare the audience on what they should be looking for.

• Only do demos with a short list of vendors. Work with someone who knows the market to give you a short list of products to look at. That doesn't mean asking someone "what are the best CMS." If they know anything, they will tell you that it depends on your requirements. If they have an opinion. Well, it is just going to be that: an opinion. You need to focus on a short list for two reasons. First, if the vendor knows that he is in a field of 10 candidates, he is not going to invest as much in the demo. He will have a junior sales team give a generic demo. Second, when subjected sit through 10 demos, your staff will not invest as much of their attention in evaluating each product and they will start to muddle the products together.

• Clearly define what you want the demo to show. Because content management systems (especially web content management systems) are so flexible, a demo should be a prototype that you define according to your requirements. Just like a prototype, you need to clearly specify what it needs to do. The approach that I find the most effective is using scenarios that describe tasks that need to be accomplished using the system. The demo should show how the user would accomplish that task using the product. The demo should also recognize the constraints introduced by your architecture. The vendor should not know you features that would not work in your architecture. Neither should they show features that you don't need. The demo should show your content. Ask the vendor to configure a content types that matches the the most complex content type in your content model.

• Validate that the vendor understands your requirements. Have the vendor prepare a written response describing how their product can support your scenarios. Review it and give them feedback with ample time to adjust their demo in case they misunderstood what you need.

• Prepare the audience. Prepare your audience for the demo by telling them what they should be looking for. A scorecard that lists the scenarios is useful for keeping people's attention on their needs, not gimicky features. If the audience does not understand basic content management theory (separation of content and layout, re-usability, content lifecycle, etc.) address that before the first demo. Vendors are actually pretty good at explaining that stuff but there are more effective uses of their time.  Also, vendors tend to up their game when the realize they are dealing with a sophisticated audience.

During the demo

The demo should use everyone's time as effectively as possible and should be organized to ensure that vital information is communicated to the right people.

• Limit company background information. The vendor should be able to introduce their company and make the case that it is a stable company, it gets content management, and knows your industry. However, you need to contain the amount of time that they take to do it. They should be able to build a level of credibility and comfort with the audience but not infringe on the time they have to talk about their product within your context. Hopefully your short-list exercise already pre-qualified the vendors along these lines.

• Mind your manners. Even if your corporate culture thinks it is OK for staff to attend meetings in-body only, keep distractions to a minimum. Ask your audience to put aside their email, blackberries, and cell phones and pay attention. Give the vendors every opportunity to engage with the audience. If the vendor is missing the mark, don't tune out. Instead, help steer them back on course. If you can't do that, politely end the meeting as quickly as possible and be happy that you were able to eliminate an option in a very hard decision.

• Mark your scorecards. Without making it feel like a Bingo hall, have the audience take notes in their scorecards so that they remember what they saw and their impressions. By the time they have gotten back to their desks and answered their first of fifty waiting emails, they will have forgotten half of what they saw.

• Break up the meeting. A thorough demo is enough to tax anyone's endurance. Not everyone needs to hear everything and people tend to lose focus after sitting for long periods of time. I usually break up demos into three main sessions. The first is the company background and functional session that all the stakeholders should attend. This is when the vendor walks through the scenarios and helps business users visualize using the product to get their jobs done. The next session is the technical session that shows what is going on behind the scenes and how the system can be customized and integrated. All the business users that are still awake can leave for the technical part. If they are asleep, leave them alone and let them dream about life with better content management tools. They can use the rest. The third session is the project management and licensing part where the vendor talks about the licensing needs, cost, and professional services. Your project management people and tech leads need to be part of the discussion. Everyone else can go back and extinguish the fires that have probably ignited during their absence.

• "Yes" is not a good enough answer. When you ask if the system can do something, don't let the vendor get away with a simple "yes." Have them show it. And if they are not prepared to show it, have them describe how it would work and how much effort it would take to get it to work like that. You could also ask to speak to other customers that are using the product in that way.

Follow up

Don't let wait long to get feedback from the audience. It doesn't take long for people to forget. Follow up and plan the next steps as soon as possible.

• The post mortem. As soon as possible, get everyone in a room and have them express their observations and impressions. Ask them what they didn't see. Hopefully, they have notes on their scorecards. There were probably some scenarios that were not adequately explained. Get this information so you can follow up with the vendor.

• Schedule follow ups. Talk through what additional information is needed with each of the vendors who earne
  d further consideration. For the vendors that didn't make the cut, explain why. If the demo was a disaster but you think the product still has potential, you could give them another chance or you could take it as a sign that they are not prepared to support you. Remember, after the contract is signed, things are only going to get worse.

• Prototype. If there is a question about something, build a prototype and allow users to bang on it. Different vendors will have different policies around this. Some create hosted sand boxes and allow business users to experiment. Others provide trial versions of the software so that a customer can attend training and try to build the prototype themselves.

Conclusion

Demos can either clarify or confuse, inform or misinform. If run properly, they can be the most important part of the selection process. At the end of the day, both you and the vendors are after the same goals. They want customers that are successful with their software. You want to be a customer that is successful with their software. However, that doesn't mean that a sales team can't get swept up trying to win a deal. It also doesn't mean that business users will not lose sight their goals when distracted by flashy features and a compelling demo performance. Be up front with this and try to work together to achieve this goal.

What about open source software? For the commercial open source products out there, this advice still holds. You just want to be even more sensitive about using the vendors time efficiently because they have less to gain in terms of licensing revenues. Assign some of your technical staff to dig around the product (and the community) for themselves.  If a commercial open source vendor is able to invest in large sales teams, you can be pretty sure they have a pricing model (around support and maintenance) where they can collect revenues that are equivalent to commercially licensed software. Either that or they haven't had to think about building a sustainable software business yet. For community-based projects, you are not going to get a sales team. You should form an internal team (or pay a systems integrator) to build the prototype and play the role of the sales engineer. You probably need to do more homework to decide what platform(s) you should evaluate and be even more diligent in documenting your requirements.  Otherwise, your developers will get drawn to nifty architectures and technology buzzwords and neglect what your business users need.

Now THAT is a Domain!

I was Skyping with someone a couple of days ago and he was referring me to a URL that he decided it would be better to type. One reason was it was not in English and I have no foreign language skills. The other reason was the URL was http://www.maatschappelijkverantwoordondernemen.be. Now that is a URL. I recently saw a presentation by David Esrati from The Next Wave where he talked about his 80-40 Rule. The basic idea is that URLs are less important because 80% of browsing starts in the search box. 40% of users are so clueless that they type the URL in the search box. If this is true, having an awkward domain name is not so much of a problem. Social bookmarking and blogs probably help too. But I assume that there are limits to acceptable awkwardness.

BTW, kudos to J Rulnick for having the foresight to register chargoggagoggmanchauggagoggchaubunagungamaugg.com after the longest place name in the United States! He gets the 80-40 rule! I think?

Site Registration

I was very happy to read Marc Osofsky's very well reasoned and well written article about setting content free. In the early days at a company that I used to work at ;) we had a simmering debate about whether or not to require registrations to gain access to our white papers. As you might expect, the consultants (who joined the company because they got the concepts behind open source software and Web 2.0 and also wrote the white papers) wanted to make the white papers freely available. The sales organization, whose business process centered around processing leads, couldn't see the logic of not getting contact information whenever possible. For a long time the company had a required registration and our sales guys made qualification calls to "Superman" and "Mickey Mouse." Hey, a lead is a lead. Right? Actually, the sales guys did get frustrated as you can tell from this blog post.

Web 1.0 expanded markets by allowing traditional business models and practices to be less geographically constrained. With Web 2.0, communication has surpassed the point where it can be directly and centrally controlled. By producing good content, companies are able to extend their reach beyond the realm that they can actively participate in. People download things, try them out, blog about them, and talk about them in public and internal forums (physical and digital). If they like what you have to say and have problem that you can solve, they will find you. Maybe 1 in 10,000 contact you. That is pretty good if you are reaching millions. Furthermore, the 1 person that calls has already spent a lot of time pre-qualifying himself saving you a lot of work. A great example is all the companies that put their product videos on YouTube. I am seeing more software companies making their documentation available but there is a concern that their competitors will have access (as if they don't already).

All this doesn't mean that you can forget all of your traditional prospecting work. That is, unless you have an amazing product that just sells itself. You need to keep a balance. Keep your sales guys getting their leads and working on them. Just don't constrain the power of your published information by controlling it with a pre-web mindset.

Come see me at DocTrain in October

On October 18th, Bryant Shea from Molecular and I will be presenting at DocTrain East in Lowell, MA. The topic of our talk is "New Documentation Strategies For A Web 2.0 World." Here is our descriptive blurb:

The web is changing the way people consume information and creating new opportunities for documentation and other product content to reach out beyond the manual and engage users. The web is also giving voice to others who have something to say about your products. To navigate these new dynamics we must change our mindset about what documentation is, our relationship with our audience, and our control over the information. This session will introduce technologies for reaching and conversing with the your audience to create knowledgeable and passionate users. We will cover blogs, podcasts, annotations, and wiki technologies and how to turn a vocal community into an ally rather than threat.

I just got off the phone with Bryant and we were pretty excited about how Web 2.0 trends and concepts are transforming the world of technical writing and communication. Come and join us to learn more.

CMS Gallery on del.icio.us

I subscribe to a bunch of open source WCM mailing lists. Occasionally, someone announces a new site that he/she built on top of the platform. When I read this, I usually tag the site on del.icio.us with a tag like <cmsname>gallery. For example: "bricolagegallery". Many open source WCM project sites already have nice reference site galleries with descriptions about the technology used. I find del.icio.us tagging useful for sites that are not on the public galleries. Here are some tags that you might find useful:

The Importance of Vendor Neutrality

I was just reading CMS Watch Commentary today and noticed Alan Peltz-Sharpe's post about the Department of Justice suing Accenture for allegedly (who are we kidding, we KNOW they did it!) colluding with a software vendor and recommending the product based on kick-backs. See full story. These are the times it feels very good to be a vendor neutral technology strategy consultant. The collusion between systems integrators (and some large analyst firms) ranges from trivial to flagrant.  Even if there are no monetary kickbacks on a software deal, there is usually some kind of bias. A systems integrator (or more accurately, individuals on a sales team) is going to pitch the product that they know best in order to reduce their risk. In fact, you don't necessarily want a systems integrator to propose a solution that they are going to learn on your billable time. Software vendor partnerships may exert pressure to prioritize a certain solution. My recommendation would be to accept that systems integrators are biased (that they need to be biased) and put their recommendation within that context. Maybe talk to a couple of SI's that specialize in different products. Or, better yet, talk to someone like Content Here who can afford to be vendor neutral and have them connect you with the right technology and  the right integrator. There's my bias talking!  Seriously, it was probably foolish for the Department of Justice to expect an unbiased recommendation from Accenture. I just hope they didn't waste too many tax dollars buying it.

Daisy 2.1 Release is Official

Outerthought just announced the official release of Daisy CMS: version 2.1. For those who are not familiar with Daisy, it is a fairly simple, easy to use Java based WCM platform. The front end is styled after a wiki although it supports more comprehensive WCM functionality such as structured content types, decent access control, and workflow. The repository is de-coupled and is accessible through a ReST style interface so the more ambitious or Cocoon-phobic (the user interface is written in Cocoon that has a steep learning curve) can write their own management interface and front end.

Daisy is primarily used for basic informational sites, intranets, and knowledge bases. Some companies use it to create documentation because of its XML oriented architecture, its book publishing features, and also its powerful versioning and localization functionality. Thanks to a partnership with the Belgian systems integrator Schaubroeck, Daisy is widely used for local and regional Belgian government sites. Daisy development is managed by Belgian systems integrator and software developer Outerthought which also sells support packages on the platform.

This new release is supposed to be easier to configure and manage (thanks to a new Spring based runtime container) and includes a very cool visual version diff'ing tool. Unfortunately Daisy is still missing user input validation out of the box. You can only set whether a field is required and the size of the input box.

If you have been looking for a basic, mature Java WCM and have been turned off by the complexity (in terms of user interface, architecture, and social dynamics of the community) of Apache Lenya, you should give Daisy a look.

How easy should installing enterprise software be?

There has recently been an interesting conversation on the Bricolage mailing list in reaction to a review posted here. I like reading these threads as they progress from indignant rejection of criticism (some major inaccuracies like that the project is dead and also some constructive feedback) to introspection and the acceptance of new ideas and input. On the point of the project being dead, the mailing list started to think about ways to keep the website more up to date and be more vocal about new developments - not everyone, including some software reviewers it seems, reads the mailing list. One of the very valid points was how difficult Bricolage is to install. Having installed it several times on various platforms as well as many other open source CMS, I can confidently say that Bricolage is one of the hardest installs that I know of. I remember Midgard also being pretty bad but that was a long time ago and they may have improved. The general consensus within the list was that installing Bricolage is pretty much a nightmare unless you are running Debian.

While reading the thread, I was thinking about how in the not so long ago past, no enterprise software installation was a trivial task. Installing these systems required a significant amount of time by even experienced engineers. When I worked in professional services for a CMS vendor, our teams were always deployed after an installation engineer (who did nothing but product installations) took three days to install the product. And that is after the customer could demonstrate a fully operational database and J2EE certified application server. Perhaps we shouldn't abandon this expectation altogether.

There have been many observations about "consumerization" (BTW, I thought I made that word up but it looks like Gartner beat me to it) of enterprise software making it simpler and more appealing to casual users. This is mostly in terms of user interface but I think it also applies to installation and management. Enterprise software is being held to a new standard by business users who are no longer satisfied with the explanation that the software stinks because it is "enterprise grade."

Many of the open source CMS that I track have packaged installers or self contained bundles that you can just download and run. Open source applications should definitely have this capability. Otherwise, the primary advantages of the open source model (cheap distribution and accessibility for experimentation) are lost. It doesn't take long for a user to give up on an application if he is presented with roadblocks before even experiencing the features of the software. Many products take this accessibility one step further by setting up hosted installations so that business users can try out the software without even installing it.

Of course, you should never use these installations in a production environment but they are good for trying out the software and, perhaps, for a development environment. If you want to run a production system, you need to really understand the application, its vulnerabilities and how it behaves. Arjé Cahn, from Hippo CMS has a very good blog post reminding us about how important it is to pay attention to software configuration even for software, like Apache, that has a reputation for being secure. In the JBoss administrators class, you learn that JBoss "out of the tarball" is totally insecure and can be shut down or compromized by anyone with network access to the box. For tips on securing your JBoss installation, go here. Shipping JBoss this way makes a lot of sense. With all the security turned on, your average developer is going to constantly run into obstacles and not know whether it is his code or something else. It is the system administrators job to lock it down... and then break application ;). TYPO3 does a nice job of keeping vulnerability warnings in your face until you change the password from the default and delete the setup files. Some products like eZ publish allow you register your site and have services for monitoring your application. This could be a good way to provide a vulnerability report service.

I think the message for all enterprise software should be to keep the hurdle to experimentation as low as possible but be very clear about what it takes to establish a robust, secure production environment.

Get ready for Plone 3.0

The GA release of Plone 3.0 is right around the corner (due out August 21) and there are many new features to look forward to. Unlike 2.5 which was a primarily architectural release, 3.0 focuses on the user interface. Jon Stahl does an excellent job of summarizing the key improvements in his post "8 Really Cool Things About Plone 3." You can download release candidate 2 here. The features that I think are the most significant are:

• versioning, staging and locking

• more granular workflow control

• a dependency manager called "link integrity" that prevents broken links

• and lots of improvements to the Kupu rich text editor.

Alfresco/OpenCms Integration

There was a recent announcement on the OpenCms mailing list about a new Alfresco add-on that allows you to publish content from Alfresco into an instance of OpenCms. The project is called Alfresco-OpenCms. You can get the documentation here. I haven't tried it out yet but the documentation shows examples in a normal Alfresco "Space" rather than a "Web Project." Web Projects are still relatively new and do not yet have all the capabilities that normal Spaces do so I am not sure that the module would work for a Web Project.

Perhaps the key value to this component is that it allows you manage content within Alfresco's sophisticated repository and leverage OpenCms's more mature web content delivery functionality. For example, maybe you use Alfresco for internal collaboration and document sharing and then you publish some assets to your OpenCms powered corporate web site.