Laura’s Winning Ideas

Use natural vocabulary

When search software was less competent, we used tags to categorize database entries. A tidy database was admired by all, so proposal team leaders would work hard to pigeonhole data into tidy packets labeled with key words.

Here’s why you SHOULD NOT do this in your databases:

1) New technical references will emerge before you can create a new category, and this is valuable in beating the competition to offering new technology.

“No Virginia, the scientists and engineers know about new technologies long before they can translate it for management and sales.”

(Read on …)

This just arrived in my in-box and it is a beaut.

These folks should learn not to run with knives and pens.

- Operationalizing your taxonomy

Join us for this month’s Taxonomy Community of Practice conference call on operationalizing taxonomies.

Bringing a taxonomy to life is not an easy job.

Operationalization often requires juggling multiple perspectives, such as those of designers, content publishers, application developers, not to mention consumers.

These groups all have different views on what taxonomy is, how it should be applied, managed, integrated, etc. So, knowing this, how do you roll your taxonomy to the enterprise?

This session will present taxonomy operationalization strategies that take into account this multiplicity of views.

Learn about:

Different taxonomy formats (controlled value lists, reference data, etc.)
Implementation issues
Cross-project perspectives
Communication and education
Governance and standards

Where is my red pen when I need it?

Once you’ve found the juicy data you’d like to import, you can issue an RFQ (Request for Qualifications) to vendors. You want to narrow the list to those who can plug and play with your existing systems.

The last time I did this, we started with a list of 60 potential vendors, and this first step narrowed my list to about 30. You are looking at all CRM, Enterprise management and proposal management softwares. There are probably over 100 firms you could invite.

Then, I create a sample database from the existing system. This will be used for testing all prospective software, and I let the vendors know this in my outline for the next steps. At this point several vendors who knew they were joshing when they answered the RFQ, dropped out. (Read on …)

Avoid software from whence your data cannot migrate.

Vendors hate the insinuation that their platform might become obsolete or that you might decide later to use a different software configuration. In fact, I’m sure most of them count on you not understanding how they can corrupt your data in ways that prevent migration to a competitor’s system.

I call this Cul-de-sac software. You enter, and must remain because there is no path through to other streets. You are limited to data in and reports out.

Insert an interim step to copy data to a wide open platform before entering the data in a proprietary database. I’ve used MS Access and My SQL. In one case the extra labor needed for this stepped migration was mitigated by automated data massage programmed at each transfer.

This extra step is a good clean-data test as well. You are more likely to crash your system on a virus or corrupt data entry when you are still in your interim platform. This saves you going off-line because something corrupted your proprietary database which everyone in the company is depending on to keep proposals flowing.