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

U

unqol

Registered
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 said:
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!
Click to expand...
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.
 
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.
 
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.
 
unqol said:
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).
Click to expand...
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.
 
unqol said:
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!
Click to expand...
@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
 
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 said:
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.
Click to expand...
@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. . . .
 
Last edited:
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.
 
Last edited:
Gardener said:
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.
Click to expand...
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.
 
unqol said:
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.
Click to expand...
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.
 
You must log in or register to reply here.
Top