How is using Later different from using Someday in this regard?
But what are your thoughts on using a sequential project as a natural extension of both Next and Later concepts?
It just seems that if Someday, Next and Sequential projects are utilized fully, then having a Later list would not be that useful, while adding some distraction and maintenance.
One tip for keeping Someday easier to review overall is to label someday items according to how often you want to review them. For example, I have a maybe tag for Someday items, which I normally exclude from review to save time.
I’m happy to keep up the discussion. I’m open to the possibility that you’re using the software more efficiently. Thanks for asking questions, they make me rethink.
I think I can state my problem more concisely. Hopefully, I’m not missing anything.
Let’s say tasks are like a dependency graph. Since I’m using GTD, I don’t really want to map it all out. Nevertheless, some vague version exists in my head. Next items are leaf nodes, they can be directly worked on. In my mindset, Later is anything blocked but needs to be done in order for the project to be completed. Someday/Maybe are items typically blocked for a long time. They might be ideas about future direction, in case of research projects. Or in the case above, changing static images to interactive diagrams. Conceptually, they typically require the project to be almost completed. They might get broken down before actually being used.
After completing a task, I will move any new leafs mentally from Later into Next. The question is, how do I find those in Everdo? In my envisioned setup, I go through every item in Later. If it’s now unblocked, I move it into Next. Using your setup, I right click on the tag “Maybe” at the top and go through the Someday/Maybe list. If it’s now unblocked, I move it into Next.
The key insight here is that both systems are doing the same. The difference is only whether it’s naturally supported by the software or if you’re using tags to accomplish the same thing.
Or are you not doing this? Are you not moving items into Next after completing items? If you are doing this at review time, then I’d say it doesn’t work for me since during a regular day I can plow through several Later items. And I don’t think my items are too granular. An items is at least a Pull request with git.
Your reasoning could also be used to get rid of Someday/Maybe. After all, you can keep all actions in Next and filter by tags. Do I understand your system correctly? Maybe we have different usage patterns and that’s why you feel okay with your version but I feel like I’m missing something.
How extensively are you using that maybe tag? If you’re using it most projects, it might be a good indicator that it you’d benefit from this extension as well. Also other people, feel free to join in. I’m curious about why not everybody is experiencing this friction.
The reason why I don’t feel like it solves my problem is that there is not necessarily an order. I want to be able to work on any of the Next items. The Later items could be defined by anything starter after a placeholder item, but that’s more of a workaround again.
Thanks everyone for chiming in. I was away for a few days but see that I have pretty much the same approach as 3xe. Later is really about things that should be done but not now or soon. I hate the idea of mixing opportunities and tasks which is why the Someday/Maybe doesn’t satisfy me for that purpose. I can see that the GTD model doesn’t have that distinction but it’s really important. For the time being, I am using Someday/Maybe as a Someday/Later and using an area to separate Opportunities from Tasks but as a result I feel I can’t benefit from the full power of areas.
For project actions, I usually just use the sequential feature as it is. It works for almost all my actions. I will move some actions to Someday when I’m not even sure whether I want to do them as part of the project.
First, I would suggest making the scope of your projects smaller, so that graph-based project planning is not such a big consideration. I keep large-scale plans on a more appropriate medium (paper, actually). Then I create projects for short term outcomes.
Second, I would like to clarify that the leaf nodes are not necessarily next actions. They are if you have a parallel type project in Everdo. In a sequential type project a branch of the graph becomes a sequential list of actions.
Given a smaller scope of a project (a few weeks to a few months in time), my approach is to “project” the action graph on a time line the best I can. You can’t do two actions at the same time anyways, so you will do the projection at some point. I do it right away. I end up with a sequential list of actions. It’s not perfect. I wouldn’t use the Later list because then I need to think whether some part of the graph fits into Next, or Later, which is vague. I still don’t understand which actions go into sequential Next and which ones go to Later.
I wouldn’t say I use it a lot. And I probably use it for a different case, as I’m now realizing. I use the maybe tag for standalone someday actions which I’m not likely to actually pursue. But I still add them to the system to get them out of the mind. I review them a few times a year.
Isn’t this the fundamental problem with trying to reduce a graph of dependent actions to a sequence of actions? I know the problem exists, but I don’t think adding another sequential list addresses the root problem.
While I’m not convinced about the Later list, I keep the general issue in mind when using the app. More arguments will help. I’m hoping for a better way to solve this.
Thank you so much for your detailed answer. I think I understand your way of working a lot better now.
I have to admit, I’m not using sequential projects much. Maybe because I’m less structured than you or due to the nature of my work but I like the possibility within gtd to work on any next item that I like. It’s like with a child: do you like to eat broccoli or carrots? I’m so busy choosing my favorite item that I forget that I want to slack off. On a more serious note, the item I’ll work on will also depend on how much time and energy I have. Besides the constraints I’ll mention below.
I see. It’s definitely something I will keep in mind, especially for bigger software projects.
Same as above. I specifically like that, unlike other project management tools, I don’t have to define the full dependency tree. That’s great about gtd. Personally, I’d like to avoid the planning that you do on paper altogether because I know for me, short term, things will change.
Let’s consider a research project at university. For me, they are typically less than a year, maybe 6 months at a time. Things change all the time, for better or worse. Tasks might include: improve logging, implement notification when experiment ended, run experiment X, run experiment Y etc. Which task I’m working on depends not on my plan in Everdo but on the environment. If the servers are down for maintenance over the weekend, I will do implement major features. Maybe the computational resources are occupied right now, so I’ll refactor a bit and check later again. Maybe I can only run one experiment, or multiple at the same time. While they’re running, I’ll work on something else. When I have the energy, I’ll apply for more resources or funding or a conference etc. My point is these projects are not sequential by nature and I can work on multiple tasks. Additionally, I have to keep on reading papers and start writing a paper while keep running experiments. Again, parallel by nature. Now, you might say my definition of a task or project is wrong. Maybe. But it works in general for me and that’s the most important thing. I don’t think I’d get more benefit from creating a “run experiment X” project.
I also don’t belief that fixing the order of nodes in the graph would benefit me in this context. These projects are bound to change. This may happen to the outcome of experiments, supervisor input or funding.
Now that I write it down, my life seems kind of messy. But that’s why I’m into gtd.
I assume your reply might be that my projects are still too big. Again, I will try to experiment with that. I do like the clear definition of these projects though and I’m not sure if I can create clear boundaries for sub projects. Given this very vague description of research projects, how would your work concept apply to it?
If I think about it correctly, I agree with you for sequential projects. Since there, anything in Next but the first Next item corresponds to my definition of Later (Next but blocked, although some are only artificially blocked).
Viewed the other way, if there was a Later category, then a sequential project would simply by a project where Next has at most one item. The other items that are now in Next would be in Later.
Right now, I’m thinking that we’re working on different types of projects with different work mentalities because I’m not trying to reduce it to a sequence of actions and I doubt it would be possible/useful for all of my projects.
I assume you’ve had more changing projects as well. Be it at university, in real life, because of micro-managing bosses or changing customer requirements. Did you use gtd at that time already? If so, did you apply the same strategy, i.e. work with a sequential project? How did you scope sub projects? Specifically projects that had a sort of fixed scope of a few months already.
If the sequential project + time/energy/context filtering doesn’t work well, then I would try to break down the whole research project into a few smaller projects. Think one small project per “branch” of the original project, so that each “small project” is sequential, but the whole set of active projects is parallel and represents the big project. Maybe create a separate area for those projects if that fits your workflow. This is how I work for large many-months projects. I have a dependency graph on paper and each node is a project in Everdo. So current active projects are leaves of the graph. Other nodes are created or activated when the current leaves get completed. Inactive projects can be stored and planned in Someday.
Another big thing for me personally is using time blocks per area or label. It’s not directly related to your question, but it helps tremendously to limit the scope of potential work at a given moment.
My specific experiences might be not very relevant. I try to reduce the scope of work at any given time and focus as much as possible, be it in work or study. I think it’s optimal and I was lucky to usually be in a position where I could do that. But I think the GTD methodology has the tools to deal with more hectic work environments. I think I need a more specific question to provide any value here
“Someday Maybe is actually equal to tasks or projects that do not have a due date.”
We don’t actually need a separate area for them because of technology, you can quickly get a list of everything that is " someday maybe" by simply filtering out tasks that have no due date.
I don’t think that’s correct. The set of Someday items might be a subset of the items with no due date. But the converse is definitely false for me and I dare say for many users. For example, I have plenty of Next and Waiting actions without a due date. Not just because I’m lazy to set a due date everywhere (which I am), but because there legitimately aren’t any due date, but I simply want it done asap.
Really ? Mowing the lawn may start as ASAP and does not have a due date. It’s just that if you don’t do it the next action changes to “use round up in the garden” can’t see a due date nor the someday maybe category.
Doing something for a client often is an ASAP without a due date. The client may call at some point probably then you get a due date.
I could go on forever…
I love deadlines. I like the whooshing sound they make as they fly by (quote courtesy of Douglas Adams)
Thanks for your explanation, I see the difference.
I’ve heard that before and it makes sense. My concern in this topic is more intra-area but I agree.
I agree. The context of this question was more about Everdo rather than GTD. I feel like my way aligns with the methodology but it doesn’t seem to map perfectly onto Everdo.
What I meant was you have something to do for a client ASAP without a specific due date. But after some time he might call you and tell you he needs it till date X.
If it’s due ASAP then it has a due date.
If it has more than one step to finish then it is a project and not a next task anyways.
If it is a project without a due date, it is a someday maybe project.
You said it was “due” for a client. That has a due date so it is not “someday maybe”
You haven’t given me a next action or project without a due date that is not “someday”
Even a habit type routine either has a due date because you give it one or if it is not important enough to be given a due date, then it is something maybe by nature.
If it doesn’t have to be done, then it doesn’t have a due date. It’s someday maybe.
There are a lot of tasks we give virtual due dates to. When we continue to put them off, we realize that they were actually someday maybe disguised as a next action. When we remove the due date, they become so officially.
For me it’s simple, I won’t invest the effort to make up a due date for each and every action, enter it into the system just to find out there is more than I can possibly do in my life time.
That’s why ASAP works well for me.
Even if you are right and every action has a due date, it well might be that it is not possible to qualify a real due date or a due date that I might be aware of or might be able to find out.
If it works for you it’s fine.
But if you find yourself watching due dates passing by and making up new ones over and over again you might be better off accepting ASAP as a possible due date and using your intuition.
Before GTD I had a task list and calender stuffed with red over due stuff, frustrated I gave up re-planning and reassigning new due dates. That’s just not how I roll.
Ultimately I found GTD which fixed that for me.
For me ASAP is key.
Let’s agree to disagree, that’s not a discussion I want to take further from now on.
Referring to the discussed distinction between the Later list, the Sameday list, and the Next list. There were mentioned sequential tasks which in my opinion are not the case here. In my opinion, this is the case: Next actions are tasks that you committed to do ASAP.
Someday items are the ones that you didn’t commit to do. Maybe you never do them and it is ok.
Sometimes we have a parallel project but some tasks that you commit to do depends on other tasks. You don’t want to forget them so here is the moment when the Later list comes to the game. This is the list that contains actions that you committed to do but they can’t be done right now. Of course, GTD suggests to keep those further actions in project support materials but the Later list is more convenient in my opinion.
If I understand correctly, you suggest using Later as a list of blocked next actions.
I think a general solution to this would be to use a tag like blocked or later on next actions. This way, you will not forget these items because they are still in Next, but you can also hide them very easily hide them when viewing Next.
We only need to make assigning/removing tags easier. That would facilitate all tag-based workflows, so it needs to be done anyway.
On a more serious note, the item I’ll work on will also depend on how much time and energy I have. Besides the constraints I’ll mention below.