cross cutting concerns or where to categorize an NA

T

toertel

Guest
In programming there is a concept called "cross cutting concerns", and I'm running into a similar problem with GTD. I expect others have run into this, so I thought I'd ask.

I have a next action to (for instance) talk with someone about some small piece to a project. In my mind, this belongs in two places, with all the other things I might need to follow up with that person about, and with all the other things that need to get done for that particular project.

I don't like the idea of keeping it in two places, as I tend to have the actions in paper form and it'd be difficult to keep the two items "tied together".

Thoughts?
 
L

LJM

Guest
The strict GTD answer would be to put it in whichever location you're most likely to look when in the context where you can solve the problem.

Are you more likely to see the person, check your list of things you want to ask him/her about, and see the action that way?

Or are you more likely to be working on the project, and fire off an e-mail or take a walk over to the other cube/office?

(also: would switching to a system where you can link them be a net gain or a net loss for the way you are comfortable using your system?)

For the longer answer, read the three threads linked above :)
 

br4978

Registered
Why not use routine work habits to assure you cover items concerning a specific person?

I'd get out the highlighter and mark all items on your NA lists that relate to that individual at the beginning of the day (or other interval, as appropriate). That way, you'll be able to scan and pick up all other NAs when you're engaged with the person in question. A quick glance at items on your Agenda list for that person will pcik up all other items not listed as an NA.

I do this electronically by sorting my NA list by the person's name (which I place in the text of the NA) rather than using a visual scan, but I bet on paper this would be just as fast (or faster).

- MB
 

moises

Registered
toertel;44801 said:
In programming there is a concept called "cross cutting concerns", and I'm running into a similar problem with GTD. I expect others have run into this, so I thought I'd ask.

I have a next action to (for instance) talk with someone about some small piece to a project. In my mind, this belongs in two places, with all the other things I might need to follow up with that person about, and with all the other things that need to get done for that particular project.

I don't like the idea of keeping it in two places, as I tend to have the actions in paper form and it'd be difficult to keep the two items "tied together".

Thoughts?

It's not just a NA problem. This problem arises for me as well when I am putting items into my general reference filing system. Is my new HR software filed in HR or in Software or do I make a new folder for it?

The real world does not come neatly divided into categories with hard edges. But we want our systems to be neatly divided into categories with hard edges. So we want to represent our world in neat boxes. The messy world does not always fit easily into nice boxes, so we must use force.

Since my general reference system is, thanks to David Allen, dynamically changing all the time, I often forget exactly what file I put things in. So, I keep a searchable Excel file listing filed items that I might forget. Just today I forgot that a couple of months ago I created a new folder to contain some new state requirement called a "Business Registration Certificate". While looking in my "Government" folder I saw that I needed a copy of my Business Registration Certificate. I did ctrl-f in Excel and found a copy immediately. The lesson I have learned is that, given the limitations of my mind, it is not sufficient for me to have items filed in folders. I need to have a digital list that contains the folder names and some hints about folder contents.

I like to do something similar with my NAs, so I use multiple tags to help me find them. I have a context, project (when applicable), and contact name (when applicable). But, as Kewms wisely pointed out, that horse has been beaten to death, so I will not comment further on it here. Maybe it was a cat that was beaten to death and still comes again and again.
 
R

ritz

Guest
I categorize by context

My NAs are categorized by mutually exclusive contexts (in this case it would be @Agendas, sorted by person), but are linked to associated projects by notations within the NA.

That way, when I'm in a given context (in contact with the person in question in this case) the NA is in the list of available NAs for that context (in this case, a list of anything I need to talk to that person about.) When I complete the NA, I am in the habit of looking to see whether it is associated with a project so I can take whatever steps are appropriate (marking a step as completed, creating the next NA, etc.)
 
T

toertel

Guest
@ritz, to be clear, my problem isn't about knowing what project my NA is associated with. Per my original (somewhat vague) example, I need to talk with a peer about some decision that needs to be made regarding a piece of a project. I know what project it is associated with.

The difficulty for me is when I try to have all the project info together, for instance, I have a meeting with a client, so need all the outstanding items regarding this project together so that they can be reviewed. So, I need to have readily available: that I'm waiting for something from A and B, need to talk to C before deciding a couple of things, and am at various points in sub-projects D, E and F.

Now, it seems like the ideal to solve this particular problem (for me) would be a project and an @list for each NA, such that I could sort based on either... but that would mean probably moving away from paper (like my comment @ljm below).

@moises, I can certainly see what you're describing as a problem for some, although that isn't mine... ;) I've been a programmer for a long time, and have gotten very used to storing things in a strict heirarchy, and knowing where to find them again. (At least as far as filing goes.)

@ljm, I generally want the info (from the example) on a person-specific list...
Being a programmer, I'd like to switch over to some other (e.g. electronic) system for keeping track, but I've yet to get enough momentum with one to get away from pencil and paper...

@katherine, I'm still slogging through the threads, and haven't found a solution for me yet... but still going. (I guess I should have lurked a little longer, since, as you said, it does seem to come up pretty often.) There doesn't seem to be a FAQ on GTD for the forums... or am I just missing it?
 

kewms

Registered
I use a paper system. For the specific example of keeping all the pieces of the project together, I look in the project support file. While theoretically that means that there's duplication between the project list and the NA list, in practice it turns out to not be a big deal.

For example, one project requires approvals from several people above the level of my immediate contacts. These people are listed in the project notes. I have NAs and tickler items to call them, followup with their secretaries, whatever is necessary to get their response. But meanwhile, the project notes just say "Tom, Dick, and Harry must approve -- sent email 12/20." If I need the exact date or content of one of my followup emails, I can get it from my sent mail file, but in general just the note that the subproject is waiting is enough.

YMMV, of course, depending on the amount and kinds of detail you need, and how quickly you need to retrieve it.

Katherine
 

unstuffed

Registered
What Kewms said...

I'd say that the NA itself has to be in your context list for that person, while the information that you're waiting on something from them is kept as a notation in your project support material.

In one of my incarnations, I'm also (have been, willan on beeyan) a programmer, so I know the sort of baroqueries that software dev can throw at you. I use a slight variation on the GTD system for myself, but at base it's all the same principles: the context lists are to give you a list of all the stuff you can do when in that context, and the project support material needs a marker to tell you what's doing, what's waiting, and what's screaming, at any given time.

You can keep this 'marker list' stapled to the inside of your folder of project support material, or in your 'projects marker lists' folder if you have one, or glued to your knee if that works for you. But I think that you need both the ongoing snapshot stuff and the NA on context list stuff.

Or have I completely misapprehended your meaning? It's been appallingly hot here for the last few days, and I think my brain has fried.

Alison
 

unstuffed

Registered
Oh, one other thing...

...on re-reading your replies. Despite being a sad, socially maladapted geek, I use paper for my GTD system. I've tried various software implementations, and to me it feels too much like hard work. I like being able to lay my bits of paper on the desk and shuffle them, I like being able to scribble things on whenever I need to (not just when the computer's on), and I like being able to see everything at once. Plus a number of other things that have escaped me at the moment.

Could be partly because I have a definite thing about UID (user interface design). I'm so thoroughly tired of software that seems designed to show off what the designer did, rather than to allow the user to do what they want. Good UID is hard, excellent UID is exceptionally hard, but a staggering amount of what I see is entirely scrofulous UID. But people are still forced to use it because they haven't seen good UID yet, so they don't know that they should be demanding better from their software.

Okay, I'll stop ranting. Sorry. But I told you my brain had fried...
 
T

toertel

Guest
@unstuffed, you got my meaning just fine. I think I've actually had two difficulties. The first was that I am soo used to thinking about "projects" in my engineering sort of way, rather than the GTD way. I didn't realize it on my first read of the book, and after reading the forum and starting to re-read the book, my brain is slowly starting to come to grips with how many "projects" I really have. I think that was contributing to my difficulty deciding how to organize the NAs.

The second difficulty, how to actually manage the NA, I think I've got a working theory for. I'll use the @list for the actual NA, and have a simple reference in the project material. Something as simple as a marker like "@John" should be sufficient. I can always look at the @list to see what the actual task is.

Thanks for the assistance, everyone.
 
P

pooks

Guest
I'm not sure if I'm quite understanding the question (not coming from a techie background) but occasionally I find an NA that serves more than one purpose. Last night I had to empty my Element quickly to loan to somebody so they could pick up their new dog more easily (yay!) and I just tossed everything into a black trash bag and brought it into the living room.

"Sort black trash bag from car" needs to be done to clear the living room. But it also needs to be done because there's some paperwork in there I need today.

In that case, if I've got a "living room" project and a "paperwork" project, I finally realized there's no reason why I can't put it both places.

If I don't think to mark it off of both project lists when I'm done, it's no big deal. Next time I look at them, I'll mark it off as done and move on.
 
T

toertel

Guest
@pooks, Let me give you a more concrete example.

I have a big project "migrate customer database from Oracle to Postgres". It involves a whole pile of sub-projects. One of them is "Walk through migration process with test database". My next action for that is to talk to my boss about it, to find out what computer is dedicated to the "test" migration. I'd put that on my @Boss list, so the next time he's in the office and available, I'll talk to him about it.

However, I have occassional meetings with the customer, who might want to know the status of the overall migration, as well as some of the individual pieces.

It would be convenient for me to be able to look in one place, and know that we've completed setting up the new database on their production machine, that we've ported 2 of the 3 important applications and (most important) I need to talk to my Boss about what machine to use for the "database test migration". I imagine it would be difficult or awkward to review all of my @lists while in the middle of a conference call, scanning for things that I know (or have tagged somehow) as related to this particular project/sub-project...

Now, I'm not actually DOING the GTD process yet, so this is still just based on my limited understanding...

But, I hope that helps you understand the original question! ;)
 
P

pooks

Guest
In that case (and I'm sure somebody will step in if I'm wrong) you'd simply have your project list, with all the NAs on it. You will see the NAs that have been checked off, and those that you're waiting for (WF) and those that are next up at bat. So you might be able to say, "We've already done A, B, and C -- I'm waiting for Z-Company to get back to me on D, and will get back to you as soon as I clear C with my boss, and as soon as J is cleared, we'll move onto...?"

Your Project Card/List -- however you set it up -- will have a list of NAs. You can tell at a glance which have been done and what status the others are at. You probably will know enough from looking at that list to not have to chase down every NA; but you'll know where to find them if you need to.
 

kewms

Registered
toertel;44860 said:
Now, I'm not actually DOING the GTD process yet, so this is still just based on my limited understanding...

In my own implementation, I've found that the Theory of GTD is actually more difficult than the practice of GTD. The project-action link is a case in point. Many people immediately assume that their GTD system will succeed or fail based on their ability to maintain this link, and they judge potential tools based on this criterion (and often this one alone).

In practice (see earlier threads), many people seem to find that the project-action link just works, and that things like Inbox processing and consistent Weekly Reviews are far more important to actually Getting Things Done.

So my suggestion would be to set up a system -- any system -- and work with it for a while, and then you'll be better able to judge its strengths and weaknesses.

All that stuff that programming theorists say about the value of building a working prototype applies here as well.

Katherine
 
T

toertel

Guest
Honestly, I am trying to get up and working with GTD, even without all the answers... even though I'm spending quite a bit of time in this thread. ;)

And I think I came to a similar conclusion, that I might not even need the reference, but if I do, just a note about where the actual NA is, may very well be sufficient.

My biggest personal hurdle is getting over the "setup costs", getting the system in place, without being able to do it piecemeal, without fully understanding it, and without being able to tell if I'm doing it "right enough"... Obviously people are able to, so there is hope for me too. :)
 

unstuffed

Registered
You're getting there...

...and I think kewms is right when she says that the theory is harder than the practice. When you dive in and start wrangling, you'll find some of the questions disappear. And you'll find other questions that stump you, but you'll choose a way to deal with them, work 'em for a while, then maybe tinker again. It's less a concrete engineering/design process than a software dev process: you're setting up a base system that does most of what you want, then tinkering with it to make it a better fit.

For your specific question, what I'd do is this: you have your context lists, so you'll have "ask which machine will be used for test migration" on your @Boss list. You'll have all your project materials in one or more folders, either one for the whole project, or one each for the sub-projects and one for the whole project. Your choice. I'd have a 'progress marker' list stapled to the inside of the whole project folder, and on this you can scrawl your NAs, in as much or as little detail as you need.

This is assuming that it's the one client for the whole project: we've done work where different people in the client organisation have stakes in different parts of the project, in which case you just modify to fit.

Then when the client calls, you have your whole project list right there, and you can see what NAs you've achieved, which will jog your memory about what stage you're up to.

Viz your concern about the setup costs: if you're going to set this up, you really should try set up as soon as possible. You can break the setup into discrete parts, although it works better if you do it in one massive hit. DA says complete setup takes about 2 days. Once you've got a working setup, you can then test drive it, see which bits work and which don't, and tinker.

One final piece of advice, from someone who's also still in the throes: it's worth it to put in a spurt to complete the setup, and then to say that you're now fully operational. If you keep patching here and patching there, you won't be fully confident or fully committed.

Do or do not, there is no try. ;-)
 

pixlz

Registered
Cross cutting concerns

toertel;44860 said:
I imagine it would be difficult or awkward to review all of my @lists while in the middle of a conference call, scanning for things that I know (or have tagged somehow) as related to this particular project/sub-project...
QUOTE]

Hi

I have the same issue with keeping the project "stuff" on different lists all over the place so I use Mindmanager - (www.mindjet.com). I have a big map (one each for Work, Home & Uni actually). I am able to set up a map with each project as the high level branches, subprojects and finally NAs. Each NA has a category which is the context and I can filter by these Categories. I can also set up due dates and other text markers to filter by if neccessary.

If I want to I can export to Word in a list format. I also use it in the traditional way for brainstorming etc.

Regards
Sharon
 

darlakbrown

Registered
I work in technology too....

Don't know if this helps but for a large project like that you should create a Project folder (or binder if really big) that you review at least once per week. This would contain all project plans, notes, docs, etc. You would update project status on a blank piece of paper. When client calls, pull the folder, open it and tell them where you're at. GTD is good but it's not magic. You can't keep all the project info on a context list.
 
Top