Laura’s Winning Ideas

Guess what!

Information you lust for is laying around in other corners of your organization.

Imagine a resume database that updates each week without you pestering a single person for an update.

Where is the information?

Heck, accounts receivable knows who bills out to which client and project. Payroll may also know, but start sniffing in accounts payable. What is the route used to create invoices? Is there a place (or several) where a report could be generated that would transfer data to your resume database?

You going to finish that sandwich?
Be sure to ask about all the fields of data they track. There might be some goodies like technical area or client type you could tap into.

Imagine a resume that ends with a stream of notes of additional projects on which this person has worked, reminding them of EVERYTHING when they are ready to write up some paragraphs for the next proposal they participate in. Imagine being able to search resumes to match people to the location or client.

Imagine a project summary database that is error free because the skeleton of data automatically comes over from your accounting with the client’s name, project name and number, location, and list of personnel working on the project? You’d just be left scanning the list of personnel to find someone to write out the details when a project seems needed for a proposal. Poor baby.

You are almost ready to start talking to vendors, but not quite yet!

First step in designing the architecture for your proposal databases is to understand where you are in the eco-system of data. Proposal data and CRM is pretty far downstream.

Though our purpose is critical to the survival of the organization, our data needs are second or third tier. You see, others dictate the requirements for the upstream databases. Payroll and accounting must satisfy the appetite of regulators at the SEC and agencies like the IRS. Sarbanes Oxley is keeping your CFO up at night, so stay out of their way.

Second, our data needs are historical not real time. HR, payroll and accounts payable must be realtime. A week or month delay in relaying data to your system is not really a problem.

So, do not try to change the existing database environment in other departments to suit your new database nor software. This is unnecessary.

Document the systems in use, and ask whether they anticipate any major changes in their system. Keep your plug-in points simple. Don’t plan any upstream data change.

Looking out the window here in Wisconsin, the leaves just turned color. We have a beautiful tapestry with all the riotous colors of fall and a nice sunny day to enjoy it.

The beauty of fall colors is the diversity of color and texture. It just wouldn’t be the same if someone had carefully planted all the maples together and all the locusts together. The color is better in a woods that has them all mixed up together, and ecologically, that is more sustainable and healthy.

Same goes for database design. On the one hand, you want to be able to quickly find what you need, on the other hand, you need to have a wide variety of information in your system.

Some folks segregate the data: Resumes are here, project summaries are there. Very little if any overlap occurs. This method denies some important opportunities. For example, say a key player is unavailable to lead the technical team for a project. With segregated databases, you can’t tell who is the next best candidate. With an integrated design, you are two clicks from the next best candidate no matter how large your firm, AND have the data to prove it to the customer.

There are lots of fancy software that claims to automate the process for you, but I’ve found the best database must begin with an architectural design first, rather than buying the software and trying to get it to work for you.

Yikes! This is a big topic so I’ll stop here and spend the next few times talking about one aspect of Database Design. Stay tuned.

(If you aren’t a subscriber, this would be a good time to get subscribed by using one of the selections on the right.)

I just packed a box of documents, and remembered all we’d learned about shipping proposals. We usually use 3 ring binders for proposals.

Originally, this was for our convenience. Last minute page changes were easier with 3-ring binders than with other binding methods that required special equipment. In a pinch we could put a whole team around a table and switch out pages in seconds.

Then, we started seeding the debrief questions so we could find out more about the impression we made with clients.

The bad news was that we found 3-ring binders could be a problem. With the shifting around during shipment, the binders could come unhinged, causing pages to pop out of place. (Read on ...)