Vauger Projects

F

furashgf

0
I've heard David say twice on his podcast that he's totally comfortable with making very vauge projects, e.g.

"Figure Out What's Bothering Me about X"

"Look into Y"

etc.

This seems like a great technique for getting unformed but mentally taxing stuff off your mind. Right now, my project list only includes specific projects that I'm very clear about with tangeable results. I have many other worries and thoughts that eat up mental space, that arent' really someday/maybes.

Has anyone had any experience with using the above approach?
 
Another similar situation where there's only a next action if someone says yes. For example, I'm thinking about trying to get the developers more access to the DB. If the result of the next action:

Crooks Barbara re Would having more access help @Agendas

Is "Yes", then I have a project with Next actions, else "No".

Should the above be a project anyway, like

Look Into More Access for Developers
 
may be just means "intangible"???

That is,some projects might have intangible outcomes, but nevertheless have meaningingful and indentifiable outcomes, or that the desired outcome of a project might be identifying some alternatives or a range of possibilities. With regard to intangible outcomes I have made the mistake of not being clear about distinguishing my goals and values from the desired outcome of my project.
 
furashgf said:
Another similar situation where there's only a next action if someone says yes. For example, I'm thinking about trying to get the developers more access to the DB. If the result of the next action:

Crooks Barbara re Would having more access help @Agendas

Is "Yes", then I have a project with Next actions, else "No".

Should the above be a project anyway, like

Look Into More Access for Developers
Click to expand...

What's the desired outcome?

More specifically, what would "more access" possibly help *with*? Are there ways to meet that goal other than more access?

If a simple yes or no question defines whether a project is useful or not, then there's no need to do anything about the project until you get an answer to the question. However, real world situations are rarely as simple as yes or no answers.

Katherine
 
furashgf said:
I have many other worries and thoughts that eat up mental space, that arent' really someday/maybes.

Has anyone had any experience with using the above approach?
Click to expand...

If I do not write want on my mind down it eats away leading to a sleepless and/or restless night! So I will always attempt to jot down what's on my mind. Call it a mind dump or whatever, it just stuff that should be captured. Once it's on paper, I can leave it or refine it at my leisure.

Just the act of capture frees the mind. As to further action the weekly review is a good time to look at these noodle like problems and see if they should move forward. If not, tickler them for a week or two and see what comes out. After that, it's most likely resolved and can go directly into the trash can.
 
furashgf said:
I've heard David say twice on his podcast that he's totally comfortable with making very vauge projects, e.g.

"Figure Out What's Bothering Me about X"

"Look into Y"

etc.

This seems like a great technique for getting unformed but mentally taxing stuff off your mind.
Click to expand...
This seems really funny to me. He spent so much time in the book emphasizing NOT to have vague things like these on action lists. And projects were supposed to have clear desired outcomes.
 
What is the Outcome?

I use this - for me the outcome is that I have made a decision about something. Usually that decision will be to create a new project that does have a specific outcome.

The point is that some decisions are not easy to make. They may require research, brainstorming, time to ponder, discussion etc. So the process of making the decision is a project in its own right.

I use name the project "R&D xxxx" but maybe "Make a decision about xxxx" is more accurate.
 
andersons said:
And projects were supposed to have clear desired outcomes.
Click to expand...

But "Figure Out What's Bothering Me about X" has a very clear outcome. What you do with that outcome is another question, but I don't see a lot of intrinsic "vagueness" in a project whose goal is to gain clarity about something that's bugging you. That seems very consistent with GTD's goals and processes.

-- Tammy
 
This is an interesting thread for me as I often wonder if my projects are too vague. I'm sure they are sometimes but other times I wonder if its unavoidable.

Often the desired outcome is difficult to define exactly and often impossible to measure if it has been acheived. For instance I have a project at present which is "Further improve system for planning classes". I know that I want to improve and implement a better system for planning classes but I can't be more precise about how or to what extent this will be done at this time. The project name may change over time, for example probably after a brainstorm on what needs to be done, but I'm pretty certain that the vagueness at this stage is required.

Perhaps an example of a project that shouldn't be so vague is another I have which is "improve social aspects for students". This project has been on my project list for ages and its vagueness has probably meant I have procrastinated.

So, it seems to me that vagueness is at times required but at other times is a definite enemy. I myself need another handle on the issue.

I'm intrigued therefore by the reference to DA talk on "vague projects". I have the "Productive Talk" podcasts so far and don't recall him talking about this but it might have slipped past me. Which podcasts are being refered to?
 
For me, vague projects usually suggest that I need to research or think about something. In those cases, I'll word them as:

Research X

or

Journal/write about X

Both of those are concrete things I can do to clarify what I want to do.
 
I agree it is important to define the first concrete thing you can do for whatever vague idea you have. But if I just put in "brainstorm X" or "consider Y" there is the danger that I will do the brainstorm and then nothing will happen after that, it can just get lost. I need a project to remind me that I need a next action to follow it on. DAs concept as a project being a stake in the ground seems to be for just that purpose.

The project is almost bound to get less vague after a brainstorm and vague projects can be better defined in a weekly review as a matter of course (which will probably involve some brainstorming), but I think the presence of some vague projects being in existence some of the time may be unavoidable.
 
Perhaps I was unclear. "Research X" is not the next action; it's the project.

It sounds like what you describe as Projects I describe as larger goals. Those are the things that I re-evaluate every month and add into my system as projects and tasks. But then, that's just me.

If you're afraid it's going to get lost, by all means put it into the system. The system's purpose is to avoid losing those things, after all.
 
Definition of "project"

A big "a ha" that I had about defining projects came several months ago, when I realized how much "vagueness" was filling my project list. I took something from David Allen, probably from GTD, but I can't remember exaclty where from, the idea to define the successful outcome of a project in terms of something that you can achieve a "win" from, regardless of what other people or circumstances decide to do for or against you.

The classic example is in defining the successful outcome of a particular sales presentation along the lines of:

project : Sales presentation to client X
successful outcome: I have maximized Client X's opportunity to buy from me [instead of "Client X has bought from me"]

I also realized the importance of distinguishing projects from longer-term goals, and by definition, since then, I always ensure (in weekly review as a failsafe point) that all projects on my list are defined in terms of a "short-term end point".

One of the fundamental keys to 'doing' GTD is in the processing phase, which is where we turn "stuff" into "widgets". Generally, I aim to complete all processing in a sitting, but there is certain types of 'stuff' that arises which is vague, and which needs a project in order to complete the processing fully, such as the "look into y" or "Figure Out What's Bothering Me about X", which started this thread. Either way, there's no way around the hard thinking that needs to be done sooner or later to keep the "stuff" from occupying your head.

So, along these lines, "Decide how to define X as a project" can be a valid item on the project list, or its short-form "Look into X". As long as it is on your project list, you will review it regularly to decide on possible next actions.

The caution is not to use this as a way to avoid the minute or two of hard thinking that can be done during processing, and likewise not to leave this on the project list out of the usual vagueness-procrastination patterns that have been discussed in many other contexts here.
 
Something else to keep in mind. "Look into X" (or "Figure out what's bothering me about X") is a project, not a Next Action. As such, when you add it to your projects list, you should also be asking yourself, "What's the successful outcome? How will I know when this is done?" Do the answers to these kinds of questions clear up the vagueness? If not, perhaps they've not been fully answered.

-- Tammy
 
Good advice from all.

I find that, if I have a vague project, I benefit from creating a Next Action specifically to clarify that project. Journalling helps me, so for a vague project I'll create a Next Action that says, "Journal about story idea" or whatever.
 
You must log in or register to reply here.
Top