The dangers of linking tasks to projects, etc… (Project as an Outlook Contact item. A

[Oogiem]

Ha, ha - I thougth "Black Sheep Shepherdess" was a metaphor.
I thought maybe for somesort of evangelistic/rehabilitative/social work or something.

giggling hysterically I guess I am evangelic regarding the benefits of wool and I am sure the sheep wish I would do something else on occasion. However I am actually a shepherdess of black sheep, 132 of them to be exact. Now all naked and cold, shearing is done for the year and we're back to winter with snow and rain.

 

[CoffinDodger]

2. Some projects are projects not in the GTD sense, but in the Project Management sense: a project with a long list of tasks, to be done by a great host of people, with a lot of $$$ being spent. These are done with full project plans (and the project name on my projects list). If I have a personal NA from that Project Plan, then I add it to my list. Waiting for's are usually handled in project review meetings. The point of the GTD project is that 99% of the time you need a simple system.

I read a tip on the forum which I've started using that if these sorts of projects are 6 months or more running it may be appropriate to store them as goals or accountabilities. I lead a team of software developers building long projects for which we have project management and bug tracking databases which contain action plans etc. I don't need to mirror those into my GTD system.

However "Coordinate requirement review for version 22" might then become an individual project in my GTD system with next actions, agendas and waiting fors. It services the goal.

 

[Gardener]

Some random thoughts:

I never quite got why it's bad to link NAs to projects. Is it bad because it consumes extra time, or for some other reason?

I use OmniFocus, where all actions are linked to a project, though they don't have to be viewed that way. So if it's about viewing, I have the option to look at a Next Action list broken up by context and ignoring Project. But I'm curious as to whether there's another reason.

On multiple actions, I try to make sure that each project has at least one workable NA, but I don't stop myself there - if I'm brainstorming actions, I keep entering future actions until I run out of brainstorm. Otherwise, I'll fear forgetting those ideas, and the idea is that GTD will keep me from worrying about that, right?

I also like the "cranking widgets" idea, which is another reason why I have a bunch of actions. So instead of having a project with just one action:

Project: Complete off-duty personnel report.
NA: Copy on-duty personnel report code as a starting point.

I prefer to have a pre-planned series of widgets:

Project: Complete off-duty personnel report
- Copy on-duty personnel report code as a starting point.
- Confirm that copied code compiles and runs.
- Write query for off-duty personnel.
- Write sort for off-duty personnel.

Blah, blah, blah. I like to plan the coding ahead of time, in sufficiently bite-sized chunks that I can do it even if I'm feeling rather stupid. This is also often a way to gently break through procrastination.

On past actions, I don't generally look back at them, though I wouldn't say that it's inherently bad. In my case, I want any looking to the past to be clearly specified in future actions, if you see what I mean.

For example, if I complete an action to email someone with a question, I immediately create a new action to follow up on that email. If I complete a programming change that will require testing, I immediately create an action to do that testing. And so on. If I have to go back to completed actions, that means that I failed to follow my own system.

Gardener

 

[kewms]

Some random thoughts:

I never quite got why it's bad to link NAs to projects. Is it bad because it consumes extra time, or for some other reason?

I use OmniFocus, where all actions are linked to a project, though they don't have to be viewed that way. So if it's about viewing, I have the option to look at a Next Action list broken up by context and ignoring Project. But I'm curious as to whether there's another reason.

I don't think it's bad, just unnecessary. The problem is that people who are new to GTD tend to obsess about ways to maintain the NA-Project link, to such an extent that it keeps them from developing a robust system. In a robust system with well-phrased NAs and regular weekly reviews, you don't need an explicit link.

Katherine

 

[nshram]

contacts as projects

Hello everybody!

The subject of this thread (projects as contacts) immediately caught my attention. I have read the original Bill Kratz procedure. However, my requirement was based on different considerations:

1. I have a j2me based Nokia cellphone (6275).
2. I wanted a way to capture/sync projects and actions between my PC and cellphone.
3. Though the hardware on the Nokia 6275 is good, the applications are pathetic. Example : the "todo" list application has a limit of 30 todos!
4. Some initial attempts : text file, pygtd were unsuccessful.
5. I then thought : even in a crummy cellphone, which is the one function that has to work fast. Answer: the contacts function/application! Moreover, in these cellphones, it is the only application that is searchable.
6. So my solution, which I have managed to remain on for the last 6 months is this:
   
   
   

   1. Create projects and next actions as contacts in outlook
   2. Start each project name with ! and another character based on category. Example: !w means a work related project.
   3. Start each next action name with @ and another character based on context. Example: @h means at home.
   4. I have made further refinements on this basic foundation - involving views in outlook, a project number to link into the next action, etc.
   5. Now, after synching outlook contacts with my cellphone, I am able to immediately view projects by searching for "!" and next actions by "@". Further filtering works by entering the second character.

Of course. Many may think all this is another wasteful exercise in trying to find the ultimate GTD implementation. I would agree. All I can say is it works for me, for now!

 

[mcogilvie]

Of course. Many may think all this is another wasteful exercise in trying to find the ultimate GTD implementation. I would agree. All I can say is it works for me, for now!

I think "ultimate GTD implementations" have more bells and whistles. This is making do with what you've got. If it works for you, go with it.

 

[Oogiem]

I don't think it's bad, just unnecessary. .....In a robust system with well-phrased NAs and regular weekly reviews, you don't need an explicit link.

I think that for many projects it *is* necessary to keep the link between next action and project. The reason is probably the nature of my projects though. If there is any chance that someone who knows nothing about the project will have to step in and take over the more links you have the better.

A farmer friend just died in the field at age 42 (I won't say how much younger that is than I am!) If all his projects and next actions depend on his own knowledge and weekly review, the farm will be in a rough state until the family can get it all back on track. If there is a clear list and the family knows where it is, they can at least carry on or hire someone to continue without as much disruption. This is particularly critical in that many farming activities are somewhat time dependent. Any delay in doing them could be very bad.

A consultant friend has a "hit by a bus" method of managing all her obligations. She runs her business so that no client or project is ever be in a state that if she was hit by a bus and killed vital data is lost. One of the reasons she keeps getting business at this time is the fact that her clients know that no matter what happens to her, she has a backup plan for their projects such that another person can pick up where she left off and go forward with minimal interruption to their business.

Lists of next actions without that project link and backup are much harder to hand off to someone if you are not there to explain your thinking.