Why Database? Part 1

Imagine you have two piles of rocks; your clients wants them all in one pile.  (Those of you already rolling your eyes - welcome to consulting, people.)  Could be two bodies of water, whatever.  But you need to move stuff from A to B.  Now.

Let's explore some options.  You could 1) grab your bucket out of the truck and start moving rocks; 2) design/ build some nifty conveyance system (belt for rocks, or pipe if it's water, you get it) and let it do the work for you.  You see where this is going.

Option 1, or the Just Lift It approach.  This works well if:

• this is a one-time job;
• you're blessed with inexpensive help; or
• some slop is acceptable (you're gonna drop a rock, splash some water, as you get tired).

Option 2, aka Process Engineering:

• the pile of rocks will reappear tomorrow;
• you are priced as a Boutique Consultancy; or
• accuracy, thoroughness, whatever, is critically important.

Option 3.  Work Smarter -- know when and why to pick one of these ways of working over the other.  If this were as obvious as it seems we would do it.

How can we distinguish when it's time to react quickly to a client's need, and when an opportunity to improve processes?  Vision.  Ultimately, it seems to me, some well-defined, efficient, flexible processes should provide the best value to your clientbase.  I've found this challenging when I become (or my company's visionaries are) over-attached to either option.  They are two ways of working -- not complimentary, but exclusive of one another.

So this leaves the challenge of finding the point where one approach becomes more efficient and sustainable than the other.  You need to be able to measure the costs of each -- find where the cost-benefit (or time-effort) lines cross.

Most consultancies do a great job of measuring the individuals performance with respect to invoices -- your utilization -- which helps find slow typists, not-so-bright bulbs, people who spend more time on Facebook than OWRD websites.

Not many firms in our industry measure this.  But I think it's a concept worth playing with this weekend.  To be continued!

UPDATE: Yes, an example is a good idea; download this sample database (contains fake analytical data from mythical "MW-5").  This is a Microsoft Access MDB file (2002-03 version) which is what I figure most of us have; can be opened on SQL Server of course, imported to MySQL, Linux with MDB viewer and/or OpenOffice "Base"; has a couple small examples of normalized tables and not normal tables.