Top 10 Tips for a Successful Content Management Proof-of-Concept

By Anonymous on September 13, 2007 -- 10:49am

I really don’t understand how CMS vendors can talk about doing a “proof of concept” when it typically costs six figures to do so… Even without server licenses, it can easily cost $50K to do a “proof of concept”, with all the requisite “professional services” for configuration and training.  This is a huge impediment to any real cross-evaluation of CMS products and often an insurmountable barrier to entry.  Small companies simply can’t afford it.  Large companies can’t get budget approval. 

When the content-component CMS vendors finally figure this out, and come up with a way to provide “CMS-in-a-box” prototyping at a low cost (especially now in a DITA-fied world), I’d bet they would see an explosion of new customers coming their way.  Till then, they are leaving piles of money on the table.

By Suzanne Mescan on September 13, 2007 -- 12:25pm

I personally have never known of a POC that cost anywhere near the numbers “Anonymous” quoted. While a POC may require a fee, there are ways to minimize that fee.

My recommendation for managing the cost of a POC is to do your homework, research the options, and balance that with your needs and budget. Options may include using an existing setup (a hosted environment and the vendor’s demo data - the least expensive option), installing a system onsite and having the vendor set up a custom configuration and lots of content (the most expensive option), and many combinations in between. If you are using your own content, make sure it is clean and well-formed for a smoother setup. Time is money, and the faster the setup can go, the less expensive it will be.

By Gary Schaffer on September 13, 2007 -- 2:28pm

A POC is really a shared risk between customer and vendor. Sometines there is money exchanged, always there is “lots of time”. If you have spent six figures on a POC, quite frankly, you have been taken.

The only caveat is a POC where the vendor had to really change a significant portion of the software system.

The only proof that was obtained for six figures was the proof the vendor had a “good” salesperson and your managment did not do its homework.

POC is really try before you buy; or at least buy a little before you buy it all. Its very useful for the customer and the vendor. I highly encourage it.

G. Schaffer
President and CEO
Inmedius
http://www.inmediushorizon.com

By Chip Gettinger on September 13, 2007 -- 3:00pm

Any POC that costs six figures is over scoped on functionality, goals/objectives or timeline. I’ve see several successful POCs costing significantly less. A successful POC teaches you if the applications could work within your environment. While it is easy to control vendor and consultant’s costs, one important option is to look at using a vendor that provides a hosted (or SaaS) model. A secure server environment provides users access over the internet using a secure certificate (i.e. https). SaaS controls your internal costs by not having to provide a server and also reducing IT involvement, expect to certify security of the data for the POC.
Another costs savings is to use a content model such as DITA which is standardized across the authoring, CMS and publishing applications. While you can debate whether DITA is the right content model for you or not, at least it provides a baseline so you can evaluate the true requirements of a CMS such as workflow, content re-use, single sourcing, rendering, versioning, and so forth.

By Bernard Aschwanden on September 16, 2007 -- 11:23am

I’m assuming that before the PoC there was a Request for Information and a Request for Proposal. In the RFI the questions of a general set of costs may have been asked. There may also have been a chance to explore technologies such as DITA, DocBook or other XML standards.

One of the reasons that I really like working with DITA based content is the PoC idea. If content is put into content that is DITA (and therefore XML) it allows a faster PoC.

I’ll admit that it’s not always the right idea to go with DITA, but where it is a fit for clients we promote it for a variety of reasons. Companies like Adobe, JustSystems, PTC, SiberLogic, Bluestream, Vasont and others are working hard to get proper support for DITA. When a client looks at ways to test a CMS it’s a lot easier (and cheaper) to work with what is already built.

DITA allows content to be “pulled” into a CMS for a PoC pretty quickly. We’ve literally handed new files to a vendor *during* a live demo at a client site and said “load this into your CMS as well” to see what they can do. And they do it.

The costs of the PoC shouldn’t be insanely high, unless you ask a great deal of it. If you are willing to ask that people who work for a vendor show you the idea of their software, and the features that exist by default, you still get a pretty good idea of what it can do. If you need it customized then there is a cost.

Anyone who is planning a PoC should consider if DITA does fit into their business model. If it does, then it may well be one way to keep costs down. The vendors have already done the bulk of the development work. The content should generally flow from one tool to another. It should be easy to import it to a CMS.

There are many ways to reduce the cost of a PoC, and DITA is one of them. There are many other things that can be done. However, if a vendor does come in with a 6 digit quote, shop around. I’ve seen many vendors propose all kinds of services in a PoC and they can deliver. However, they bill you for it.

Set the rules early in your RFP. Let the vendors know what you want in a PoC and what you are willing to spend. Many will push it to the maximum if the value is low on your PoC proposal in the RFP (if you suggest you want to spend $10,000, they will push that number… if you suggest $25,000 then you may get more of a range) , but it’s your money. Remember that early on.

Get a signed paper of what you will provide, what they will build into the PoC and what you will pay. Have a way out for either side. If they hit the 50% mark in billing, but only are at 10% of the PoC, bail. If they aren’t suggested as an option by a trusted partner, consultant or co-worker, look around.

There are a LOT of options available in the field. Feel free to ask a vendor who they consider to be a competitor. Or who the top three competitors are. The answers may surprise you. I also ask them to identify features that competitors have that they feel are really solid. If the stock answer is “we don’t have any” then be careful. A good vendor should know the market, should know who they compete with and should know how to build a PoC that is fair to you and to them. That’s a major part of knowing the market and knowing your own product.

A PoC that runs the kind of money that “anonymous” mentioned is the type of thing that hurts the whole industry. I’d love to know who it was and what was delivered. It should be stated that this strikes me as an exception. Most of the vendors we deal with generally do a fair representation of their product. The PoC’s that we have seen and worked on range up to the 10’s of thousands. And they can cost less depending on what you do in advance. The more that is planned, the less it costs.

Finally, the PoC may include things like training. If that is the case, try to learn in a general sense. That is, don’t focus on exactly how to work with one CMS tool. Instead, have the vendor (or a partner they work with) teach the general idea so that what you learn applies elsewhere. Then you can get a return on investment. Even if you don’t go with the vendor, the training may help you make a more informed decision.

To sum up with a ton of initialisms and acronyms:

FWIW… Look for partners (vendors, consultants, online groups, conferences). Consider DITA or other XML standards. Build a clear RFI to learn about CMS’s. Write an RFP. Get good training maximize ROI.

By JoAnn Hackos on September 23, 2007 -- 10:25am

A Proof of Concept (POC) is a valuable addition to the process of selecting a content management vendor. During a POC, we ask that our entire new process (information development life cycle) be demonstrated in the product suite. We usually provide a set of topics and maps with actual content for the repository. We include all project phases, even those that are primarily manual like task and user analysis. We don’t want to restrict the demonstration to the tools alone because we risk missing an important integration point.

Most often, we schedule a POC with a single vendor. The POC is scheduled for very soon after completion of the proposal analysis and before a final decision is made on the vendor selection. Because vendors make lots of promises in their proposals, the POC acts as a check. We want to see the promised functionality in action before making a final decision.

Sometimes, we schedule a competitive POC with more than one vendor. However, rarely is this competitive “bake-off” done with more than two vendors. A larger scale bake-off strikes me as unfair and costly.

During the POC, we prefer to have team members actually interact with the product suite rather than have a demonstration by the vendor only. In some POCs, we have asked vendors to install a system at the place of business and allow staff members to use the system themselves. Usually the vendor provides rudimentary training and has someone on-site for a set time to assist.

We do not ask vendors to assume major production work for the POC. In many cases, we allow the vendors to install the system on their own servers and PCs rather than the company’s. There are often too many restrictions and incompatibilities on a corporate server. We also refrain from asking the vendors to do any integration work during a POC. The integrations are often major efforts that must be carefully scheduled and paid for.

Sometime it is possible to schedule a POC at no cost. Many vendors are willing to put a simple system together for a trial run. Most often, however, there is a cost. Rarely would this cost be in six figures, as someone has suggested. Except for huge, enterprise systems with complex requirements, POCs rarely exceed $15 to $25K. Many are less expensive.

I always recommend that POC be scheduled, even it the choice of vendor is already clear. Testing the proposed process usually uncovers issues that would be unpleasant surprises during a full implementation. In many cases, problems with basics, even with the user interface, are revealed by the POC process.