Discussion Forum > Master List?
Thanks for the query, Dave.
It rather depends what you mean by a master list. If you mean a list of the projects which you want to get round to some time, then I certainly would agree with that. A list like that can be very useful when deciding what your next Current Initiative should be.
If on the other hand you mean a list of all the things which you are behindhand on, then I would call that a "backlog" and you should deal with it as such.
It rather depends what you mean by a master list. If you mean a list of the projects which you want to get round to some time, then I certainly would agree with that. A list like that can be very useful when deciding what your next Current Initiative should be.
If on the other hand you mean a list of all the things which you are behindhand on, then I would call that a "backlog" and you should deal with it as such.
May 24, 2007 at 15:43 |
Mark Forster

I've just read DIT and have found it extremely useful, particularly for ensuring that emails don't mount up in the inbox. (As well as dealing with yesterday's emails today, I'm clearing 100 old emails per day as my current initiative.)
I have also been experimenting with a master list, as I typically have a number of projects on the go at once - although I wouldn't say that I was always behindhand on them. I don't want to add them all onto the will-do list, as I can't commit to working on all of them in one day. Keeping a master list and then deciding which tasks to transfer from it to the will-do list seems like a sensible option.
I'd be very interested to hear your thoughts on this.
I have also been experimenting with a master list, as I typically have a number of projects on the go at once - although I wouldn't say that I was always behindhand on them. I don't want to add them all onto the will-do list, as I can't commit to working on all of them in one day. Keeping a master list and then deciding which tasks to transfer from it to the will-do list seems like a sensible option.
I'd be very interested to hear your thoughts on this.
November 8, 2007 at 13:09 |
Paddy

I keep a list of all things are not scheduled for some particular date. I don't like scheduling tasks many days in advance, because it is hard enough for us to determine how much we can do the next day let alone a few weeks. It is inevitable that tasks scheduled well in advance will get postponed come the day as we "surprisingly" find we are carrying other uncompleted items we have to do.
One thing I am wondering if there should be separate lists for "have to do" and "could do" items. Didn't DIT talk about prioritising at this level?
Also it sometimes is a bit hard to say if some task should be declared as a backlog or included in the aforementioned list. Or is the "have to do" section actually a backlog?
One thing I am wondering if there should be separate lists for "have to do" and "could do" items. Didn't DIT talk about prioritising at this level?
Also it sometimes is a bit hard to say if some task should be declared as a backlog or included in the aforementioned list. Or is the "have to do" section actually a backlog?
November 14, 2007 at 14:38 |
Nick

One of the major points made in "Do It Tomorrow" is that one day's incoming work should equal *on average* one day's outgoing work. If this basic equation is upset then things are not going to work.
Therefore I'm always concerned when people talk about scheduling tasks in advance - if this means trying to schedule them for a time when one has more time available. This can only too often simply be a way of trying to get round this basic equation.
So to my mind if one is trying to work the "Do It Tomorrow" system then projects fall into the following categories:
1) The project is behindhind. In which case the tasks relating to it are part of a Backlog and should be treated as such.
2) The project is up-to-date. In which case the tasks relating to it should be added to the Task Diary as they fall due.
3) The project has no deadline. In which case it should be added to the Current Initiatives list and dealt with accordingly - one project at a time.
If you can't keep up with the Daily Task list, then you need to go through the Diagnosis Procedure: do I have too much work? am I working efficiently? am I leaving enough time?
Otherwise you will simply end up with yet another to do list which you never succeed in completing.
Therefore I'm always concerned when people talk about scheduling tasks in advance - if this means trying to schedule them for a time when one has more time available. This can only too often simply be a way of trying to get round this basic equation.
So to my mind if one is trying to work the "Do It Tomorrow" system then projects fall into the following categories:
1) The project is behindhind. In which case the tasks relating to it are part of a Backlog and should be treated as such.
2) The project is up-to-date. In which case the tasks relating to it should be added to the Task Diary as they fall due.
3) The project has no deadline. In which case it should be added to the Current Initiatives list and dealt with accordingly - one project at a time.
If you can't keep up with the Daily Task list, then you need to go through the Diagnosis Procedure: do I have too much work? am I working efficiently? am I leaving enough time?
Otherwise you will simply end up with yet another to do list which you never succeed in completing.
November 15, 2007 at 15:38 |
Mark Forster

I think one of the issues relevant to this is that, while it's easy to see what one day's email or one day's incoming paperwork consists of, it's harder to visualise the size of one day's 'other' work - particularly for tasks or projects that you originate yourself.
I edit a monthly magazine, and, apart from the date when everything has to go to press, I set all the deadlines myself (my own and other people's). This means an element of scheduling tasks in advance is necessary. Whenever I've tried in the past to plot out in advance what the month's work will look like, it has proved in hindsight to have been over-optimistic (mainly due to unexpected events).
I've often felt that it would be useful to have some means of knowing how far ahead/behind I am at any point in the month, but have never got to grips with I might set this up.
I edit a monthly magazine, and, apart from the date when everything has to go to press, I set all the deadlines myself (my own and other people's). This means an element of scheduling tasks in advance is necessary. Whenever I've tried in the past to plot out in advance what the month's work will look like, it has proved in hindsight to have been over-optimistic (mainly due to unexpected events).
I've often felt that it would be useful to have some means of knowing how far ahead/behind I am at any point in the month, but have never got to grips with I might set this up.
November 19, 2007 at 13:29 |
Paddy

Dear Paddy
With a recurring task like this, you do most certainly need to construct a template of deadlines which you can apply each month. That way you can just write the dates into your Task Diary each month.
The tasks you do each month may relate to more than one issue. So you might be finalising copy for one issue, inviting contributions for another, and deciding on the main theme of a third.
The investment of time you spend producing the template should make it much easier to keep on top of the whole process.
With a recurring task like this, you do most certainly need to construct a template of deadlines which you can apply each month. That way you can just write the dates into your Task Diary each month.
The tasks you do each month may relate to more than one issue. So you might be finalising copy for one issue, inviting contributions for another, and deciding on the main theme of a third.
The investment of time you spend producing the template should make it much easier to keep on top of the whole process.
November 27, 2007 at 17:54 |
Mark Forster

I know that - if you are following DIT - it should be enough to keep your task diary up to date, but not keeping a single list of everything that needs to be done seems counter-intuitive.