Not signed in (Sign In)
The Intervals Forum is read-only
Please head to for help articles and guides. If you have any questions, please contact our support team.

New to Intervals? Have questions or need help?

Modules over Task Types

Bottom of Page

1 to 4 of 4


    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.


    Using modules to group the types of work should definitely work. It is a way to organize and group the tasks. Without tracking time most of the reports will be blank since they are time centric in nature. If you were tracking time it would allow you to report by those modules for individual clients or across clients. For example, you would be able to see that for Client #1 you tend to do a lot of web updates but across all clients web updates are pretty even with signage, etc. Without time tracking the task list can be filtered to get at some of the data as well as the advanced search to search on closed tasks.

    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!


    thanks for your advice, i think we're going to try this for a bit to see how it plays out. We just got away from tracking our time, and aren't in a hurry to go back. Mostly what happened is that people wanted to know why we weren't working on their projects 8 hours a day.

    This does give me some more insight into how modules and task types work, so hopefully we can integrate them in a manner that works for us.

Comments are closed.
For more Intervals help documentation, please visit