Have you managed to successfully split your work as projects and next actions as a "knowledge worker"?

[unqol]

As a knowledge worker, I find that there's a very thin line between the "Clarify" and the "Engage" steps. I have projects that have a clear objective, and a general structure, but when I sit down to work on them it is very difficult to to set a "Next Action", even if I force myself to do it, when I actually engage with the project many times that "Next action" will change completely and just work as hard terrain that I have to re-define so that makes the "Next actions" list not engaging. The other approach is making the "Next action" more general, but then it doesn't provide much value beyond re-stating the project. I find myself working exclusively with the project list and a general skeleton of the project in the reference material, with not much use for the "Next action" list.

I end up with something like:

Projects

+ Project A.

Next Actions (too specific, ends up being redefined)

+ Work on area A.1 of Project A using approach D. (This ends up changing and not being useful most of the time).

Next Actions (too general)

+ Sit down on the computer and work on Project A. (Doesn't add any value, it's just a re-statement of the project)

I find the Project / Next Action split more useful when doing projects in the real world, like building a physical thing, go to shop X, get material M, buy tool T, prepare material + tools in so-and-so room, build parts X,Y,Z, ... but I haven't managed to make it work for knowledge work. Have any of you in the community have any tips, or personal examples that could help with this?

Thanks!

 

[fooddude]

As a knowledge worker, I find that there's a very thin line between the "Clarify" and the "Engage" steps. I have projects that have a clear objective, and a general structure, but when I sit down to work on them it is very difficult to to set a "Next Action", even if I force myself to do it, when I actually engage with the project many times that "Next action" will change completely and just work as hard terrain that I have to re-define so that makes the "Next actions" list not engaging. The other approach is making the "Next action" more general, but then it doesn't provide much value beyond re-stating the project. I find myself working exclusively with the project list and a general skeleton of the project in the reference material, with not much use for the "Next action" list.

I end up with something like:

Projects

+ Project A.

Next Actions (too specific, ends up being redefined)

+ Work on area A.1 of Project A using approach D. (This ends up changing and not being useful most of the time).

Next Actions (too general)

+ Sit down on the computer and work on Project A. (Doesn't add any value, it's just a re-statement of the project)

I find the Project / Next Action split more useful when doing projects in the real world, like building a physical thing, go to shop X, get material M, buy tool T, prepare material + tools in so-and-so room, build parts X,Y,Z, ... but I haven't managed to make it work for knowledge work. Have any of you in the community have any tips, or personal examples that could help with this?

Thanks!

So your next actions are in context. Sit down on the computer is irrelevant. It would be on the @ computer context list. You would put the very next action for that project on the @computer list and not have to say so because you are at the computer. At the computer you would look at your @computer list. At home you would look at your @home list. So what is the very next action? The other reason it is so important is lets say the next action can't be done but it can through another context. I had on @computer -add phone number to x site as contact. I was unable to do it as I was not the admin for the account. I cross that off @computer list and add it to the correct context. The project remained on my project list. That way if I crossed the next action off the list, even if I didn't move the next action to the correct context, I would pick up the next action at my weekly review. I also only put down the very next action. No more. I don't know why Knowledge work is somehow different than... say buy socks. Its not as complex, but both can be projects. And each one has only one next action. I would stick closer to your first next action mentioned, but I can see that how you described it is not the very next action. That is why you have to redefine it. Usually "work on" is not the best way to describe a very next action. I keep thinking of other things. It also has to do with your knowledge of the material. For example, you would probably skip a lot of the rudimentary next actions I would have to go through if our project was "design a website for x". My first next action may be much different form yours. Hope this helps.

 

[Matt_M]

This is a really good question and it's something I occasionally still struggle with myself. Ultimately, I don't use GTD for more sophisticated or complex work like software engineering, writing books/essays, analysis/strategic planning, etc. It does not scale for work that is intricate, complex, and long-running. There's a reason agile/scrum/kanban/lean/six sigma are all industry standards for that kind of work. Duplicating a Jira backlog/board into a GTD system can be done but it's wasteful, redundant, and inefficient. Writing a next action like "Sit down at computer and write chapter for book X" for the project "Write book about X" is pointless and repetitive.

The fundamental problem with using GTD for the kind of deep knowledge work we are talking about, is that it says to make a next action for the next physical, visible step (i.e. a verb). Doing that for deep knowledge work is prescriptive and fraught with error since you don't know ahead of time how to solve the problem or what exactly you will do to solve it until you are working on it. The better approach is to be descriptive and leave out the "how". Simply describe the output and expectation without knowing how it will be done (hint hint: that is the work).

For example, when I am doing work such as "Develop a budget tracking application", I don't use GTD. I use techniques like agile/scrum whereby I simply list the high level outputs and expectations: "Be able to create an account", "Have a total of all credits/debits", "Can safely delete a transaction", etc.

It simply works far better since it avoids trying to pre-solve a problem or presuppose the work and isn't perspective but rather descriptive.

I would never say "Create Account class" or "Create a `delete(account)` method in the `AccountRepository` class" since it might be the next, physical step or it might not be ... I don't know until I sit down and work on the problem/think about the system as a whole.

GTD is fine for shallow work (i.e. call Martha to see about marketing proposal, text Sam about weekend plans, draft email agenda for upcoming staffing meeting, hire a new VP of marketing, etc.). It falls completely flat for deep work when you can't possibly know "how" to solve a problem/what to do with it until you work on it.

 

[mcogilvie]

I am very familiar with this issue. Here are some ideas which I find helpful. The first is the natural planning model, and the idea that when you are stuck at one level of the model, you move to another level: usually higher but not always. Second, David Allen has used the term “process action” to mean an action associated with defining your work. This includes things like “Review section 3 organization” as well as “Brainstorm notation for biorthogonal bases.” Finally, there is the concept of regarding a next action as a bookmark, telling you where you stopped and how you think you want to start up again. You’re correct that this is not always what you end up doing (“doing in the moment” versus “doing defined work”). However, it is often very useful to give yourself a bit of runway to launch yourself into the air. I find GTD by itself to be an excellent and complete framework for knowledge work. Specialized systems have their place, especially for group work, but GTD is very generally applicable.

 

[Gardener]

Next Actions (too specific, ends up being redefined)

+ Work on area A.1 of Project A using approach D. (This ends up changing and not being useful most of the time).

IMO, this sounds both too specific and not specific enough. "Work on" is the part that, IMO, is not specific enough.

Are you able to give an actual next action--or something closer to one--to give a better idea?

As a random example, I'm writing a novel. As I've written, I've merrily declared things about the setting, things that are likely to end up contradicting each other. After I finish the second draft, I want to fix that.

Imagine a next action

"Work on clarifying and correcting the setting."

That's too general.

"Work on clarifying and correcting the setting, focusing on compass directions."

Not really much better.

"Search for all mentions of the four compass directions and mark them with a keyword."

That's a clear next action that I can just do. It may or may not end up being useful (I can think of several ways to use the result), but it's totally clear.

 

[gtdstudente]

As a knowledge worker, I find that there's a very thin line between the "Clarify" and the "Engage" steps. I have projects that have a clear objective, and a general structure, but when I sit down to work on them it is very difficult to to set a "Next Action", even if I force myself to do it, when I actually engage with the project many times that "Next action" will change completely and just work as hard terrain that I have to re-define so that makes the "Next actions" list not engaging. The other approach is making the "Next action" more general, but then it doesn't provide much value beyond re-stating the project. I find myself working exclusively with the project list and a general skeleton of the project in the reference material, with not much use for the "Next action" list.

I end up with something like:

Projects

+ Project A.

Next Actions (too specific, ends up being redefined)

+ Work on area A.1 of Project A using approach D. (This ends up changing and not being useful most of the time).

Next Actions (too general)

+ Sit down on the computer and work on Project A. (Doesn't add any value, it's just a re-statement of the project)

I find the Project / Next Action split more useful when doing projects in the real world, like building a physical thing, go to shop X, get material M, buy tool T, prepare material + tools in so-and-so room, build parts X,Y,Z, ... but I haven't managed to make it work for knowledge work. Have any of you in the community have any tips, or personal examples that could help with this?

Thanks!

@unqol

With all due respect . . . in regards to "Revising"

GTD understanding of "Revising" would only be by-product of intentional Reflecting / Reviewing . . . otherwise, incomplete Clarifying was done when Organizing ?

As you see GTD fit. . . .

Ps. In talking to the person herein, the following would be said to self: sloppy under investment Clarifying was done when Organizing . . . ten push-ups

 

[Cpu_Modern]

Having a project organized with only having a single next action on a context list, implies that it is okay to not get any work done on that project at least until the next weekly review.

If this is not the case with your project, then that project is not sufficiently tracked "appropriately organized" in GTD parlance. You will feel tension if you have only a NA on a list and observe that you are not tackling that NA. You rely on your ad-hoc assessment of the whole picture, knowing full well that you ought to make headway on project X and take out the project plan, inject energy, engage…

You are actually working from some other map that is either in your GTD system or your head: an informal list of the deadlines for you deliverables, or some such…

If however it is the case that your project can wait ie. you didn't get to it between two weekly reviews, then it is okay to not engage (triggered by the context list). The project needs time ruminating and your NA will at some point be an engaging trigger.

 

[gtdstudente]

Having a project organized with only having a single next action on a context list, implies that it is okay to not get any work done on that project at least until the next weekly review.

If this is not the case with your project, then that project is not sufficiently tracked "appropriately organized" in GTD parlance. You will feel tension if you have only a NA on a list and observe that you are not tackling that NA. You rely on your ad-hoc assessment of the whole picture, knowing full well that you ought to make headway on project X and take out the project plan, inject energy, engage…

You are actually working from some other map that is either in your GTD system or your head: an informal list of the deadlines for you deliverables, or some such…

If however it is the case that your project can wait ie. you didn't get to it between two weekly reviews, then it is okay to not engage (triggered by the context list). The project needs time ruminating and your NA will at some point be an engaging trigger.

@Cpu_Modern

Off the cuff:

Meaning intrinsically oscillating between 'Intuition' ["ad-hoc assessment", if you so please] and 'Procrastination' ?

If so, when the 'blow-up(s)' is/are at the gates . . . all of the seemingly unnecessary diddling will evaporate real fast ?

Possible GTD response . . . keep the Calendar as empty as possible in order to be as Context focused as possible ?

As you see GTD fit. . . .

 

[Cpu_Modern]

I wouldn't call it procrastination. It is more a forced jump into the engaging step, due to time pressure or other pressure. The root cause is not having organized the (deep work) project appropriately.

 

[Gardener]

Having a project organized with only having a single next action on a context list, implies that it is okay to not get any work done on that project at least until the next weekly review.

Well, it could be a person's policy to always create another Next Action when they finish the last one, rather than waiting a week to do so.

 

[Cpu_Modern]

Well, it could be a person's policy to always create another Next Action when they finish the last one, rather than waiting a week to do so.

Yes, the so called bookmarking method already mentioned by another poster in this thread.

What I was talking about however was the case in which no work is done on that project at all. This is different from the case in which a NA on a context list gets done and now that project lacks of an action reminder until the next weekly review.

The next weekly review comes into play, because that would be the guaranteed minimum point at which the project in question might receive more thorough organization. At that point the practitioner might decide that a single NA and a project plan isn't enough any more. Not because only at that point a subsequent NA would be added to the context lists.

What I was explaining in my post is that the root cause for "not engaging context lists", the stated problem in the OP, is not so much the wrong granularity of the formulation of the NA reminder, but a too lofty degree of project organization in the whole system.

Only if you are okay with not touching the respective "deep work" project for the time span determined as "at least to the next weekly review", is a single NA on a context list an appropriate level of organization for that project.

 

[Jared Caron]

I find myself working exclusively with the project list and a general skeleton of the project in the reference material, with not much use for the "Next action" list.

This is totally fine, and a common practice in experienced implementations.

An important distinction to make here is that your GTD system is just a snapshot of a moment in time, a bunch of reminders to keep you on track, not necessarily a process for precisely tracking each step (though it can do that). An earlier poster mentioned bookmarks, which is a good way to think of it. Your projects are the books to finish, the next action is just the bookmark of where you left off and what to do next. Project support can be thought of as the words on the page. The idea with GTD is to simply have clean lines between these types of information so that you can make good decisions about which book to pick up when. In other words, you don't have to pick up every book to see where all the bookmarks are.

Also recall that your calendar is a next action list. This is critical to understand for complex projects. Your next action might simply be a 2 hour block for working on a project, or a meeting with stakeholders, for example. During that time, you'll work out of your project support material - plans, files, notes, etc. that will have the key information you need. I find that much creative or productive (in the sense of making something new) knowledge work benefits from this kind of approach, since the creative process is emergent by nature.

The point during the weekly review is to make sure that all your active projects are moving with either a) a next action on one of your lists, OR b) something on your calendar moving that project forward. Sometimes its both.

 

[Gardener]

Yes, the so called bookmarking method already mentioned by another poster in this thread.

What I was talking about however was the case in which no work is done on that project at all. This is different from the case in which a NA on a context list gets done and now that project lacks of an action reminder until the next weekly review.

The next weekly review comes into play, because that would be the guaranteed minimum point at which the project in question might receive more thorough organization. At that point the practitioner might decide that a single NA and a project plan isn't enough any more. Not because only at that point a subsequent NA would be added to the context lists.

What I was explaining in my post is that the root cause for "not engaging context lists", the stated problem in the OP, is not so much the wrong granularity of the formulation of the NA reminder, but a too lofty degree of project organization in the whole system.

Only if you are okay with not touching the respective "deep work" project for the time span determined as "at least to the next weekly review", is a single NA on a context list an appropriate level of organization for that project.

I feel that there's something going unstated. For example, is this a scenario where the project is represented by one and only one NA, and there is no associated project plan or other support material? And so when the person realizes that the project didn't move that week, they decide that it needs a project plan?

This is just a guess. I'm fairly confused.

For me, an active project that doesn't get touched in a week is a project that, for whatever reason, (1) was not possible that week, or (2) dropped to a lower priority that week.

Random example for me:

Right now, in my off time, my top priority is gardening--I'm doing a fresh round of redesign of my garden. But we're in the middle of a hot summer, so my gardening time is limited--I need to drag myself out of bed early to get a couple of hours in before my workday starts, or, on the weekend, three or four hours before it just gets too hot.This means that I have active non-gardening projects because I just can't garden in the afternoon or evening.

But if we abruptly had a stretch of sub-eighty-degree days, I would leap on that opportunity and I would put those other projects aside. They wouldn't get touched for a week, but that wouldn't be because they only had one NA, or because i hadn't considered them deeply, but instead because they are a lower priority.

Equal and opposite, if we had several days of steady rain, it would be the garden projects that would move aside, but, again, not because they have only one NA and not due to insufficient deep thought or planning.

Now, the distinction here may be "active" projects. Most of my projects are in Someday/Maybe. If one is in my active list, that's either because (1) I firmly expect to work on it in the next week or (2) I've chosen it as a backup in case the "firmly expect" projects can't be done. So we might be talking about the same thing, except my deeper thought and planning happens before the project is ever promoted to "active" and before it ever gets an NA.

 

[achieve]

I would never say "Create Account class" or "Create a `delete(account)` method in the `AccountRepository` class" since it might be the next, physical step or it might not be ... I don't know until I sit down and work on the problem/think about the system as a whole.

I laughed out loud when I read this part. I indeed have similar experiences and thoughts—breaking down some tasks into infinitely small parts and then putting them into GTD. But I know that if I do this, the time I spend checking and modifying the GTD list will far exceed the time I actually spend on doing things.

For example, when I am doing work such as "Develop a budget tracking application", I don't use GTD. I use techniques like agile/scrum whereby I simply list the high level outputs and expectations: "Be able to create an account", "Have a total of all credits/debits", "Can safely delete a transaction", etc.
It simply works far better since it avoids trying to pre-solve a problem or presuppose the work and isn't perspective but rather descriptive.

Doing that for deep knowledge work is prescriptive and fraught with error since you don't know ahead of time how to solve the problem or what exactly you will do to solve it until you are working on it. The better approach is to be descriptive and leave out the "how". Simply describe the output and expectation without knowing how it will be done (hint hint: that is the work).

Your reply has given me a great deal of inspiration.

What I originally thought was to determine how detailed tasks should be broken down based on the frequency of checking—for example, breaking them down to a level where I check the GTD action list once every half a day would be sufficient. However, I do often encounter tasks like writing articles or programming that you mentioned. But if I have to figure out how to break them down to "a level where I check the GTD action list once every half a day," it’s really difficult. Sometimes, I don’t know when I’ll be able to come up with or find a useful piece of material, generate a good idea, or when the relevant people will reply to me about issues related to that task.

Although I don’t quite fully understand the specific operations of agile development you mentioned, I roughly get the idea. In fact, for the more complex tasks you talked about, it’s a good idea to put a goal(the output and expectation) in the action list that can guide you to accomplish them.
I was reminded of one of the most important functions of GTD: to lighten the burden on the brain. In fact, if the thoughts and actions that emerge after we see a prompt about a goal and its outcome are constantly changing and involve continuous experimentation, then there is no need at all to break down and record every single step in the action list. This is because, in such cases, our brain can automatically keep prompting us on what to do next, and we won’t forget the next step we need to take.


As for simple tasks like making a call to someone, they can indeed be handled well by general GTD practices,because we often forget to do these .

 

[Cpu_Modern]

[…] is this a scenario where the project is represented by one and only one NA, and there is no associated project plan or other support material?

In my understanding we talk about the scenario as is presented by in the OP, but of course we are free to wander off as we wish.

In the OP the project plans are already established ("have a clear objective, and a general structure") and the problem stated is that work on deep work projects tends to be triggered by the projects list and seldom the context lists ("so that makes the "Next actions" list not engaging").

In order to works towards a solution for that problem, I first wanted to surround the problem space closer:

For me, an active project that doesn't get touched in a week is a project that, for whatever reason, (1) was not possible that week, or (2) dropped to a lower priority that week.

Yes, and you are okay with that, I suppose. This is what my prior answer wanted to get at: is the "non engaging" context list really a problem? In the case where things are the way you describe them, clearly not. So that would rule out all cases of that sort.

I made the statement, that for these cases the context list will develop it's quality of "being engaging" over time and there is actually not a problem.

Then I wanted to narrow in on the probable source of the stated problem in the OP. Not sufficently organized but very important projects.

This of course speaks to several elements of GTD…

my deeper thought and planning happens before the project is ever promoted to "active" and before it ever gets an NA.

…the creation of decent project plans as you stated and the OP recognised.

But also to the way the project is represented in the overall system. And one sole NA reminder on some context list is not enough; is what I wanted to convey in my prior posts.

A thought to which the insight you provide from your system speaks testimony.

For you do not merely have these types of projects represented by on single NA reminder on their respective context list, but addiotionally you operate from the understanding that all NAs on your lists pertain to projects you want to get working on this very week. (Or maybe not… if it rains… etc - but you get what I am saying…)

You also introduced the Someday/Maybe list into the discussion and I would say for good reason. The solution to the problem as stated in the OP is probably also involving a clarifying reflection about that list by the OP. I guess.

 

[programmer01135]

As a consultant & developer, I have found that for most tasks, the _actual_ next action is too fine-grained, and _way_ too onerous. The interruption to your flow by constant checking off tasks would be disastrous for productivity. What I do is a combination of triggers ("Work on Project X"), high-level tasks akin to a user story ("New financial report", with some details captured in notes) and "pick up here" type tasks.

If I'm working on a project where items are stored in Jira/Azure Dev Ops or similar systems, "Work on Project X" is sufficient and then I go look in my assigned tasks list for what I need to do next. For projects where there is no defined task management system, I capture those high-level "user story" type tasks in OmniFocus, with some notes on what the client asked for. When I actually sit down to do the development work, then I'll actually execute on the functionality needed, check off when it's ready to go to the client for testing, and move on. If I need to ideate on a particular task in more detail, I usually just grab my legal pad and scribble out notes. Anything that comes out of that ideation that actually needs to go back into OmniFocus gets dumped into my inbox for later clarification.

The last item I use when I get interrupted or I hit the end of the day and I haven't finished a task. This gives me context for the next day so that I don't have to try and remember where I was at or what I was going to do next. Usually that's more of a true "next action' type task that's a tickler for where I need to pick up on.

 

[achieve]

check off when it's ready to go to the client for testing, and move on

This has resolved my thoughts on when to check off. In reality, handling this is quite tricky.

 

[programmer01135]

This has resolved my thoughts on when to check off. In reality, handling this is quite tricky.

I check off when it's no longer my action. If I need to follow up with the client on testing results or have a reminder to make sure they completed it, then I'll create a reminder action and tag it "Follow Up" or "Waiting" as appropriate, so it shows up on my morning review of that tag, but I also see it's not my action to complete when I'm scanning the project list for the next thing I need to do. When I have my weekly status call with the client, I can follow up with them on the status to see if they've finished testing. If there are defects or enhancements to the work that are needed, they get captured as new actions in the list.