A Wandering Mind

Yes, you heard me right. I have committed the ultimate DBA sin: I used Microsoft Access. And dammit, I enjoyed it. Somewhere, Brent Ozar, the king of Access, is plotting my violent and painful death.

Here’s the story: I’ve been using SharePoint extensively for tracking project work in my new role. It’s critical that I’m methodical and completely transparent here, because demand for my time is high and people aren’t going to take “I don’t have time to work on this until March” at face value unless I can prove it.

Overall it’s worked really well, but one frustration is the lack of things like sub-forms in SharePoint. That is, it’s really hard to be looking at an item in the Project list and add a related item in the Task list without a lot of clicking and copy / pasting.

And this is where (in the tradition of the great Emeril Lagasse), I said to myself, “Self! Remember when you were a fledgling programmer and used Access? Remember those nifty and very easily created subforms? You could use them here!” And use them I did. I set up a couple forms and nested subforms for easy addition and querying of related items, with some filtered drop-downs as well (another lacking feature in SharePoint). All these were bound to SharePoint linked lists.

And here’s why I feel mostly OK about it: it’s a tool for me to use, and it makes entering and tracking my time a lot simpler. That is going to benefit me and my clients. Yes, it’s not perfectly architect-ed, super robust, and well documented. But for now, since I’m pretty much a team of one, I’m good with that.

But still, like the shrimp in Finding Nemo says: “I am ashamed.” And I need to go take a shower now. Because I am a dirty, dirty boy.

With the market trending as it has lately, I’m sure that many companies are feeling pressure to cut costs and make more efficient use of resources. Being in IT puts us in a position squarely targeted in this kind of a situation; after all, technology units are often basically glorified cost centers.

Given the gloomy outlook for the coming months, I thought it might be appropriate to post some thoughts on how we (as GTD’ers, especially in IT) can add as much value to our services as possible. Think of this as an expanded framework for determining what you should be spending your time doing, now that resources are likely to be tighter than ever.

One thing about the tightening budget strings is that it brings things like evaluating priority and value of work into clear focus. Now more than ever, it is important to approach your daily work with a rational, methodical, and clear-headed approach, as opposed to simply giving in to whatever is yelling at you the loudest. Needless fat must be trimmed in order to ensure that we are providing the maximum of value, with a minimum of cost.

In my job previous to the current one, I worked on a development team that followed a model of total baseline operation. That is, the only “cost” associated with our efforts was that of the set staffing; there was no “discretionary” bump in resources when the list of projects grew too long. As a result, we needed to adopt a method of carefully choosing how our time was spent, to ensure that we were providing as much value to the business as possible.

Each project submitted for possible work had to be justified in four key areas:

1. Reduction of risk – perhaps the project would allow for closer scrutiny of certain high-risk areas of operation, such as large dollar transactions, or fix a bug that had the potential to cost thousands in errors.
2. Direct cost savings – by automating a process, it would eliminate the need to hire additional staff to cover an increase in volume or additional services offered. Note: while we didn’t like to think of it this way, the opposite was also true, in that some of our projects likely got people laid off.
3. Client service – the project might fulfill the request of an important client or set of clients. Or, it might allow the company to provide services not yet offered, thus enhancing our appeal.
4. Reduction of system load – because a great deal of the processing work for my company takes place on legacy mainframe systems, increased system load can almost directly equate with increased expenditures (more MIPS = more $$).

If a project didn’t meet merit based on the above four-tiered evaluation, it was unceremoniously dropped from our list of work. We had to be brutually efficient at this triage; with no cost for our efforts, the projects poured in. Even today, I still consider it one of the best frameworks for evaluating potential projects.

So the next time you’re trying to decide how to spend your time, look at your project list with a critical eye, and consider what value it truly adds for your clients.