When do you want to know?

I was going to write some more about Data Warehousing today because I got some good feedback from my friend Andy Hayward regarding my last post. But that will have to wait for a couple of days – today I want to talk about email. You know, that enormous bloated inbox that you never quite get to cleaning out, and when you do you just put them all into a folder called “archive”. I’ve got it really bad at work these days because I’m working on a time-sensitive project with limited resources and time and I just can’t find the time for housekeeping or timesheets. That is, just like everyone else.

Bloat doesn’t just happen – we let it happen. We are “bloat enablers” each time we sign up for a news feed or an event notification. My product, which we use at work under the “we eat our own dog food” policy, allows you to sign up to be notified on virtually any event that occurs in the database. For instance, when a Work Item is set to the Accepted state, I get notified because I am responsible for tagging items that should be added to one of our research grant categories. It only takes a few seconds, so I do it immediately. I also get notified of major changes to items belonging to my current project. I get notified when a Request For Change on which I am a stakeholder has been changed. It’s good to find out about these things when they happen.

But there is a category of notification that you really don’t want to hear about when it happens. Let’s say I am starting the design of a component based on reasonably solid requirements, but then one day one of the requirements is changed in some minor way. Yes, I need to see what the change was to ensure my design isn’t suddenly wrong, but I figure I’ll hear about the big changes if somebody upstream knows what they’re doing. Later. I’ll take care of it later. But the problem is, I get the email now! So what to do?

My design document is linked to the upstream requirements via relationships in our database, and these relationships can be tagged as suspect if the system is configured to do so. When I am ready to reconcile my design against the requirements, I go through my list of suspect relationships, see what changed on the other end, and make corresponding changes in my design. Then I clear the suspect flag in case even more changes are made to the requirement. There is a category of work that requires suspect flags – it is generally analysis and often technical. It includes requirements elicitation and analysis, design development, test specification, documentation, and to some extent product and portfolio management. It does not include project management and technical support. Those tasks are predominantly real-time, so email is probably just fine.

But even that’s not quite true. The email does have a habit of piling up. In fact, everybody needs some sort of work management tool that lets the jobs accumulate when there isn’t enough time to attend to them. This way they can take care of the high priority jobs first, or maybe pull off easier jobs at the end of the day when they are tired. As long as the list doesn’t get too long, you are working as efficiently as possible. If the list does get too long, your boss had better figure out how to push the work onto somebody else.

Being able to pull work items off a list – and allowing your boss to know what’s on the list – means you must have a very good reporting mechanism. Efficiently following relationships between artifacts in your database is no trivial task unless you have a good information architecture. Just because you have the data doesn’t mean you can actually do anything intelligent with it. Which is why information architecture as a discipline depends so heavily on user interfaces to achieve its goals.