Show Me the Demo!

That's the cry of the aspiring information architect. Unfortunately, success isn't about the technology

A techpubs department is a techpubs department and one is not so unlike another. At a certain level that's true, but the devil's in the details as we all know.

I've found, over the years, after watching countless techpubs departments implement single-sourcing solutions of all kinds and using products from nearly every vendor: Those who go through a true, enterprise-wide discovery process have a far higher probability of, not simply succeeding, but realizing their return on investment. Not only do they realize ROI on the technology, buy they see that return in their staff costs, their implementation costs, and everything related to getting a project like this done.

We've found that those who don't go through this rigorous process, end up spending a far greater amount of time and money in the end than those who do.

Choosing an end-to-end system like Arbortext, discovery is critical for us and for you. To assure your successful implementation over the long haul, you want to understand three things:

1. The technology
2. Your existing processes and business goals
3. Your people, skill sets, and their interests

We all know that when you implement Arbortext, it's not just about the technology. In fact, the technology is only one of the three major legs supporting an implementation like this which has lasting, process-level change effects on the entire enterprise. You've got to look at the processes you have in place today, your organizational culture, and your people—the skill levels, what you have, what you need.

It's not just the technology you're looking at: You've got to look at all these different things, together.

Asking for a demonstration before you understand exactly what it will take, from an organizational perspective, to implement single sourcing in your enterprise is no different than watching a video or reading a white paper (both of which take less time and cost less in terms of your resources).

Rushing into a demo reduces the conversation to the technology, internally and externally. Management will give you less resources, reducing the chance of successful implementation because your business case is weak. It's technology-focused rather than business focused. (And, let's face it: business-focus is what drives budget allocation.)

In addition, a generic demo doesn't serve you very well. Vendors show generic features and maybe they hit on the one thing you're looking for and maybe they don't. You and your team sit through an hour (or two or three) of features and functions of a very complex system and set of applications. (If you've got 8 people sitting in a 1-hour demo, you've just wasted 8 hours.) Looking at generic features, you can't possibly know what ripple effects the technology that you didn't see will have? You also don't know what will help bolster your case because a feature you didn't see helps someone else in the organization.

In all the work we've done with customers, we've often found that while other parts of the organization currently don't use the documentation in it's present form there is a desire to do so if the documentation could be easily customized or configured for their purposes.

Don't get me started on the ripple effects of seemingly simple process changes.

The goal of any vendor evaluation is not to see whether the product works. Software always has bugs; there's always a learning curve; and, unless you're dealing with an out-of-the-gate startup and haven't spoken to the vendor's references, then you know it'll "work."

What you're really looking to understand, in the most efficient way possible is this: What will let you advance the sales process or end it. What will get you what you need or get the sales person to stop calling.

What tells you that?

A clear and precise understanding of exactly why Arbortext applies to your unique situation, processes, people, and business needs. Without that, a demo doesn't add value to your conversation.