• If you are new to these Forums, please take a moment to register using the fields above.


No announcement yet.

"cross cutting concerns" or where to categorize an NA

  • Filter
  • Time
  • Show
Clear All
new posts

  • "cross cutting concerns" or where to categorize an NA

    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".


  • #2
    Oh boy, do others ever run into this issue. Most recently discussed in the following threads:

    Short answer: ways to make the link exist. Some people use them, some don't find them necessary.



    • #3
      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


      • #4
        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


        • #5
          Originally posted by toertel View Post
          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".

          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.


          • #6
            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.)


            • #7
              @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?
              Last edited by toertel; 01-05-2007, 01:14 PM.


              • #8
                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.



                • #9
                  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.



                  • #10
                    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...


                    • #11
                      @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.


                      • #12
                        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.


                        • #13
                          @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!


                          • #14
                            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.


                            • #15
                              Originally posted by toertel View Post
                              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.