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 .