Modules over Task Types

Hi there,

We are and internal design/marketing department and therefor have no billing and no time tracking. We do however, want to be able to report back to each of our internal clients (we're a university), what types of work we are doing for them. So, we are considering using Modules in a "work type" scenario. IE, ad, web updates, collateral, signage etc.

Can you see any problems with this? So far i think this will work well, but i don't want to get six months in and discover that reports aren't accurate.

thanks

We're an internal department also and the billing stuff doesn't work for us either. I think you'll eventually find you will want to use the time logging though -- "this year for department Z we built and published X and launched campaign Y. X consumed 16 person days while Y took 45".

We set default hourly rate for all work-types to be $1. This way we can still sort of use the budgeting tools, mentally translating $500 into 500hrs (custom currency symbols would help). It's not great, still a kludge, but it works more than not.

Modules and work-types have proven to be very squirrelly beasts. Like true rodents, they refuse to fit nicely into any the of structures we've tried to build for them. I appreciate and despise them at the same time. We went through a very extensive modelling exercise with Intervals, devising 3 different models of Modules and Work-types and their associated definitions and then using them for a time. After a number of months we threw out the whole database and used what we learned to make the best fitting model we could.

Now 6+ months later, we're once again in the position of pondering whether we should close the books and starting again. The fact is, as a creative agency we just don't work from a Modules and Work-types mindset. Trying to decide at what point a given project or task shifts from Meeting to Design to Planning to Research to Technical Support to Whatever is a highly subjective endeavour. I might categorize a day of sitting down with a client and mapping out the wire-frames of the next publication as Planning or Meeting, while a co-worker considers that Design, pure and simple. Neither of us is more correct, yet as we don't consistently use the same labels -- even the same person will use a different work-type from one day or week to the next for the "same" activity -- the reporting is skewed at best, misleading at worst.

In any event I've decided that deciding what module and work-type a given "thing being done" should be recorded as is daily menial mental suffering that expends energy and time to no great effect.

And yet, I'm still here, and still using Intervals (after seriously trying a number of other tools I might add). There is value here, it's just not easy to extract.

-----

My advice, such as it is, is start with as few Modules and Work-types as you can possibly get away with. And I really mean few, as in:

Module: work
Work-types: thinking, doing

...and at the end of every reporting cycle, e.g. monthly, look back and consider how it might *usefully* be subdivided further. Perhaps:

Module: work
Work-types: thinking, talking, doing

write that down, but don't create the extra work-type! At the end of the next reporting cycle repeat the hindsight analysis, and see if "talking" really is still a useful category, and only now, perhaps, create it.

Rinse, lather, repeat.

You could just as easily invert this, a few Modules and only one work-type, "doing" (that might be more sensible actually, as modules are cross-project). The important principle is to extend only one category class, and to do it slowly, and in response to actual activity that's happened as opposed to what you think your activity will be like in future. Humans are really bad at prediction.

It's tempting to think 2 Modules, 3 Work-types, has the same complexity as 1 Module and 4 Work-types, they both have 5 classes. Far from true: the latter has 4 possible combinations and former 6. Add just one more class, 3:3 vs 1:5, and the possible combinations climb to 9 and 6. Go to 3:4 vs 1:6 and we get 12 and 6, or double, and we're only 3 steps from our starting point. (Don't forget we're nesting these inside projects, each of which can have their own classes, adding at least one more combinatorial layer.) Another way to approach this is to ask "How many report types do we really need?".

Before you know it you're at the mind numbing menial suffering I mentioned earlier. We currently have 5 default modules
23 default work-types, or 115 possible ways to record activity, just using the defaults. Add in the active projects which have extra modules work-types and we're well over 200. This is after going through a round or two of reducing complexity. In other words, we have met the enemy, and he is us!