We’re moderating a session entitled Successful Processes for Selecting a Content Management System: How to Become an Expert in Technology Acquisition at DocTrain East 2007, Thursday, Oct 18, 3:30 pm to 5:00 pm.

The session begins with a discussion of why technology acquisition is not about tools, but about assembling capabilities that lead to competitive advantage for your organization. We walk through two scenarios that draw on our recent experience helping users acquire XML publishing and web content management technologies. The fun begins when we turn to a panel of experts who will share what they’ve learned about making a business case, distilling requirements, crafting great RFIs and RFPs, developing the short list of suppliers, and scoping a successful proof-of-concept. We’ll also look at acquiring software as a service and how the acquisition process is different from acquiring licensed software solutions.

The goal of the sesson is show attendees how to develop the skills to lead a successful technology acquisition process. If you’re interested in the topic but can’t make it to the conference in Boston this week, send us email and ask for our presentation materials. We also welcome comments from readers who’d like us to address a specific question during the session.

While WCM needs-analysis and generation of a master requirements document (MRD) usually prove to be quite in-depth undertakings for most clients, the RFP submitted to vendors should aim to be as simple and concise as possible. Here’s why.

When vendors receive a very long, nuanced description of a functional requirement, it becomes easier for them to craft a response that technically satisfies the requirement and simultaneously to withhold other relevant and more meaningful detail. On the other hand, when vendors receive a brief description of a functional requirement or category, along with specific instructions to provide as much detail as possible (at risk of not receiving credit if enough detail is not provided), they often feel compelled to write as much they can. The abundance of information found in such responses usually allows the customer to discern just how well a vendor’s products or solutions match line items in the MRD.

Recommendation to Gilbane clients: After detailed needs analysis and creation of an MRD, pare the language for each functional criterion in the RFP to a somewhat general level. For example, rather than inquiring specifically about content locking models (along with the other 20-30 minute components within library services) ask instead for a complete description of what the vendor’s solution provides in the library services category. It is essential to state that more detail in the response is better than less, and that if a vendor omits relevant information, they may not receive full marks for that category. Following this suggestion, you will be surprised at how much more insight you gain from vendors RFP responses.