For-later actions

[cojo]

Hi folks! Love GTD. It just makes sense. I've moved a few times between paper and computer-based systems, but I keep moving back to paper and for now I'm settled on a classic-size planner. The only thing I haven't adopted is the tickler file - but I write down where my papers are or what to print out on my calendar, sort of a "virtual tickler".

I work in IT security. I have some projects where I have to grant someone access to a resource and then pull it away after the project is complete. That's one example of what I'm talking about, but it's the most common one that happens to me.

I've read comments like "don't worry about the next-after-next-after-next action! You'll remember it when you get there, and it may change anyway!" Well, if I don't write this stuff down, I won't remember - and then Billy Joe will wreck the accounting system because I forgot to yoink away his access after a small project (which may not have a calendar deadline, so I can't just put a reminder on my calendar or put it in my tickler file).

I keep a separate next-actions list for each project I'm working on, so I can refer back to what I've done in the past. (I use contexts for standalone actions.) Right now I'm putting these actions on my next-action list and write something like:

Take away Billy Joe's access (pending testing)

But, it would be nice to have a better way.

So how do you deal with these types of "later-on" actions within projects? Where do you put them?

 

[moises]

One way to interpret this (there are others) is as a waiting-for. The NA is w/f Billy Joe to finish X project. kewms taught me a long time ago that there is a trap in waiting-fors. And you have given a nice demonstration of that trap. And kewms taught me that the elegant solution for such traps is to figure out what the next action is and put it on the calendar.

On September 17 put on your calendar "Call Person Y to verify if Billy Joe is finished with X project." If he's not finished, add a new calendar item for September 24. If you have a project plan, you could add it to that as well.

 

[cojo]

Good point! I've always used "waiting for" as a holder for waiting for specific people...sometimes in these projects I don't even know who does what, I'm just waiting on the outside until I get notification that a project is complete.

But I could use "waiting for" and list "project"...

I'm open to other ideas too! Thanks!

 

[jknecht]

Most of the time, people recommend checklists for things that are repetitive in nature. But I think this example is tailor-made for a "Project Teardown" checklist. This checklist might include things like:

[ ] Revoke Billy Joe's access to resource X
[ ] Back up all project data to DVD
[ ] Re-image project development server

Each time a new user is granted access to the project, you just add the "Revoke Mary User's access" to the teardown checklist. When the project ends, you can pull out the checklist and just plow through the items without too much more thought.

 

[kewms]

If it's up to you to verify that the Waiting For condition has been met, then there needs to be a reminder in your system somewhere. That could be a Calendar or Tickler item, or it could be part of the project support materials (provided you'll review the materials at the Weekly Review or some other appropriate time).

If you're not responsible for the task until officially notified -- say a manager fills out a Terminate Access request -- then you can safely ignore it.

Katherine

 

[dschaffner]

I'm just waiting on the outside until I get notification that a project is complete... I'm open to other ideas too! Thanks!

Depending on your GTD implementation you may be able to combine the "waiting for" and date sensitive information.

For example, in the electronic list manager I use, I've sent up a category called "waiting for", plus the software lets me also assign a due date.

If the due date has not passed, I don't see the item at all, and once it's passed, the item shows up in my "waiting for" list, so I can follow up with the appropriate person.

- Don

 

[abhay]

I have some projects where I have to grant someone access to a resource and then pull it away after the project is complete. That's one example of what I'm talking about, but it's the most common one that happens to me.

If there are not many projects of this kind, or you are also otherwise actively involved in the project, you may keep a project for each such item, which has this action in it's notes. During the weekly review, when you go through all your projects, you can be reminded that this project is over, and you can now make it a next action to remove the permissions, and not remove the project from your list until this happens. But till the project is not over, it's not a next action, and you will keep on saying 'oh, I can't do it yet' whenever you see it on the next actions list. This list is of actions doable in a particular context as soon as possible, not after something else happens.

I've read comments like "don't worry about the next-after-next-after-next action! You'll remember it when you get there, and it may change anyway!"

Well, I would not say it's exactly that. All that people mean by such comments is that you should not overplan, and such actions should not be on the next actions list. If you worry that you will forget it, you definitely are correct about writing it down. That's what GTD is about, getting all stuff out! It's only where you write it that is important.

If there are too many such actions, and they are going to clutter your project list, then you can put these items into a "permissions to be revoked someday" checklist, which you can review every week during weekly review. The items in that list can contain the person's name, the project, and may the particulars of permissions and other things which you would like your system to remember. At the time of weekly review you can either add a next action to remove the permissions, or an action to find out whether that particular project is over, or so on depending upon your update on the status. You can generalize this checklist if you have other things to be tracked which don't exactly fit this type of actions.

Hope this helps,
Regards,
Abhay

 

[Brent]

I think what you've got there is Project Support Material. I'd track it that way.

Create a folder (physical or digital) for each person, with a list of the access you need to grant or revoke. Then schedule a tickler or calendar reminder for the next grant/revoke activity.

Alternatively, you could see "granting and revoking access" as an ongoing Project. You could create a list of dates, people, and access to grant/revoke, e.g.:

15 September 2008 - Bill Corrigan - Remove T1 lab access
17 September 2008 - Susan Congdon - Add to S3 software access list

Then treat the list as an inbox; review and process it every day.

 

[Gardener]

I'm new at this, but:

I tend to distrust Waiting - I normally only use Waiting for actions where the responsibility to drive the event is someone else's - where, in other words, I don't much care if I forget the action altogether. I know that I'll be reviewing Waiting so it shouldn't get lost, but there it is.

For things where I personally care if the task gets done, I have an "Administration" bucket at the Project level where I put little one-off tasks that are important, time-sensitive, but don't seem to fit in the main flow of a project.

In OmniFocus, I put the task in my Administration project and give it a Start date, and it doesn't annoy me until I get to that date. (Except for seeing it when I review.) If I don't know an exact date, I make a guess, and if the task isn't appropriate when the date comes up, I guess again. If I had a paper-based system, I assume that I'd write the task on a piece of paper and put the paper in a Tickler folder, again guessing the date and re-guessing and re-filing if the task isn't appropriate by the time it comes up.

Alternatively, if each project had a bunch of cleanup items, I'd probably create a "Clean up Project X" project with all of these items and put it On Hold. Then I'd add a "See if it's time to do Clean Up Project X" tickler in Administration, again guessing and re-guessing on the date. (In a paper system, I'd probably add a note as to where I filed the materials for that project, in the tickler.)

As another alternative, for this specific issue you could have a weekly/monthly/quarterly Tickler for "review temporary access lists". If you don't have lists appropriate for regular reviews, but such a thing could exist, you could create a project to make them and develop standard processes for putting accesses on them when they're granted.

Gardener

 

[dschaffner]

I tend to distrust Waiting - I normally only use Waiting for actions where the responsibility to drive the event is someone else's - where, in other words, I don't much care if I forget the action altogether. I know that I'll be reviewing Waiting so it shouldn't get lost, but there it is.

This is an indication that there is a leak in the system. Are you doing weekly reviews?

- Don

 

[Gardener]

This is an indication that there is a leak in the system. Are you doing weekly reviews?

I am, and I've never lost a Waiting task, but I think I don't fully trust the system yet anyway. I may just need to use it long enough to trust it. Also, I suspect that I get a self-satisfied glow from the idea that I'm not only contacting people about things that I would normally procrastinate into non-existence, but I'm, ohmygoodness, _planning to follow up_! So maybe I just have fun creating follow-up tasks.

Gardener

 

[dschaffner]

I am, and I've never lost a Waiting task, but I think I don't fully trust the system yet anyway. I may just need to use it long enough to trust it.

You might try asking yourself "why don't I trust the system". It may be that, as you point out you just have not used it enough yet, or there may be something else going on too.

I think is also important that you just keeping working the system, and see how things develop

- Don