When is an Action not a Project Action

[swashbuckler]

Here's my dilemma. I use GTD Outlook Addin in which I have numerous projects and sub-projects related to my work.

Now these projects folders at the moment act as more of a bucket for actions with no distinction between actual project tasks (involving next actions) and miscellaneous tasks that may be loosely connected to the project and are not on the critical path.

For example: I have a project called Application x and there is a major enhancement that I can create a tangible project plan and timeline. So far so good, but supposing I have an action to call a colleague who has a problem with Application x that is not related to the enhancement project?

Now should this action be put into a project folder 'Application X' or should this be put elsewhere?

My objective is to get the balance between too many project folders in which sometimes I can't see the wood for the trees, with the temptation to put everything into a project bucket.

Would e great to here other people's approaches/recommendations!

[Cpu_Modern]

Each project can have more than one next action active at the same time. Each project must have at least one next action active at any given point in time. Not every next action stems from 10k-level projects, some next actions stem from 20k-level areas of focus. Sometimes you will have a single next action item in your system, that stems from a calendar entry.

Each project may have a project plan, which is placed in project support materials. In this project plan one may outline the full path of sub-projects, milestones and next actions towards full completion of the project.

If you need more than one go to complete it, every outcome you are working torwards to is a project.

The one who lets the tools he uses dicate the form of his system, asks for trouble. Rather let the system's requirements inform the usage of tools.

[swashbuckler]

The one who lets the tools he uses dicate the form of his system, asks for trouble. Rather let the system's requirements inform the usage of tools.

You're absolutely right CPU_Modern. I want to have a system that gently guides me rather than constrains me and perhaps I've been guilty of relying too heavily on GTD outlook addin.

My thoughts are not to get overloaded on the mass of actions that I've created so called 'Project' buckets for.

[CoffinDodger]

Whether you descirbe them as projects or not, above you refer to two outcomes:

I successfully complete feature Y for application X by date Z

I speak with colleague A to find out what their problem with application X is and successfully collect any next actions from that call

The Application X you refer to almost as a reference folder name rather than a specific project.

The best projects do not refer to things ("Application X" or "The front door") they refer to outcomes ("I successfully complete feature Y for application X by date Z" or "I fix the front door so it does not jam when I try to open it")

[swashbuckler]

Thanks coffin dodger. By that logic I could have a multitude of projects/outcomes. Is that the ideal scenario or to restrict them to a manageable level?

Secondly I tend to have a lot of single action items, should these have their own designated folder (single actions or misc) or should they be processed via the GTD system, independently from the application they refer to?

[Brent]

Thanks coffin dodger. By that logic I could have a multitude of projects/outcomes. Is that the ideal scenario or to restrict them to a manageable level?

You will have a multitude of projects/outcomes, which you will have to maintain at a manageable level.

Secondly I tend to have a lot of single action items, should these have their own designated folder (single actions or misc) or should they be processed via the GTD system, independently from the application they refer to?

I'm confused by your question. Actions don't have folders. Actions may (usually are) part of a project, each of which may (often do) have a folder.

If you have a lot of "orphan" Actions, that's a sign that you may not be fully tracking all your responsibilities. You may benefit from looking hard at those Actions for any hidden Projects that they imply.

That said, it's good that you're tracking all these Actions. You're doing nothing wrong.

[swashbuckler]

Hi Brent thanks for your response. Let me put my situation another way. Currently I do have folders/ projects set up (see first post), but they are mishmash of both project task and single actions.

My question is...is it more effective to split out project tasks from single actions from within the project folder I've created?

Following Coffin Dodger's comment it may be better for me to create a reference folder for each application rather than have a project folder for each application.

[CoffinDodger]

I could be misunderstanding this, but are you storing your next actions by context (where you would do them e.g @home, @phone, @computer) or by project?

[swashbuckler]

Hi Coffin Dodger,

Currently I'm storing them by Project. So a Project will refer to Application X. Occasionally I may have a sub-project underneath that relates to a geographical area. So every time I get an action that relates to a particular territory I'll process it, then file it away in that reference folder.

These projects by your definition have no end objective but will continue to exist so long as the application exists or I'm assigned away from it.

However where my approach falls down is that every so often I'm also creating projects with an end objective, for clarity.

[Brent]

Hi Brent thanks for your response. Let me put my situation another way. Currently I do have folders/ projects set up (see first post), but they are mishmash of both project task and single actions.

My question is...is it more effective to split out project tasks from single actions from within the project folder I've created?

It depends on the task.

Honestly, I don't think any of us can give you a definitive answer here. Sometimes it makes sense to do this; sometimes it doesn't. You'll have to experiment.

Is your current system not effective? If so, change something.