Defining projects vs areas of responsibility

V

vvviola

Registered
I'm having a bit of a difficulty with Next Actions/Projects/Areas of Responsibility.

My day-to-day implementation of GTD is going ok - I process my inbox, get some sort of action in context lists, and then (mostly! ;) ) do the work. But in order to get a better view of things, I know I need to work out projects etc.

My difficulty is this: I attend a certain meeting about once a week - which I prepare for and then report on. A number of these meetings feed into a higher level meeting, which turn feeds into a further top-level meeting. I have things to do in relation to each one. My question is - where do I draw the lines (or does it even matter?)

Is 'Top-level meeting on Subject A' my area of responsibilty? With each of the lower level meetings being projects? Or is the preparation for each meeting the project, and therefore each meeting at each level a different area of responsibility.

Or am I totally overthinking this and it doesn't matter one way or another? (I kind of feel it's holding me back from doing my weekly review properly)

Thanks!
 
R

Roger

Registered
It probably doesn't really matter too much one way or the other, at the end of the day.

I'd suggest they're not projects because they don't have a defined end-date or end-goal, as far as I can tell.

Subject A is probably the area of responsibility, with the various meetings being efforts in support of those responsibilities. I think the intent with this sort of structure is to give you a framework to evaluate how well those meetings are actually advancing the cause of Subject A.

Cheers,
Roger
 
mackiest

mackiest

Registered
I would create a repeating calendar entry for each meeting, and put the meetings on my projects list to remind me to go over them during my weekly review.

I would keep a file folder of support material for each meeting, containing notes from previous meetings and any planning and personal notes for the next meeting.

As specific conversations or other actions became necessary in order to prepare for each meeting, (based on my review of the support material etc) I would add reminders as next actions in the appropriate contexts.

Before each meeting I would briefly review my support material as necessary to prepare questions and agendas. I'd take copious notes in the meeting, being sure to note any outcomes and next actions - whether for me or other people whose work I depend on. My notes would get thrown in my inbox afterwards for further processing for next actions and reference filing.
 
G

Gardener

Registered
I generally feel that it's not a project unless I can phrase it as a task. So, "Top- level meeting on Subject A" isn't a task, but, "Prepare for January top-level meeting on Subject A" is.

So in my system, the projects related to the meetings would all be "prepare for" a single meeting, and they'd start and be completed about as often as the meetings happen. That doesn't mean that there'd be a new set of project support materials every month - there might be, or I might just have a "Subject A" folder that I work with every month.

There might be related projects as well - for example, if I were evaluating a possible purchase to be discussed in the meeting, then "Evalute Widgetizer candidates" would be a separate project. I'd complete it and put the results in the Subject A folder.

I also have a set of repeating single actions, and one of them might be "Create project to prepare for January Subject A meeting", set to pop up, say, a week after last month's meeting is over.
 
You must log in or register to reply here.
Top