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
 
You must log in or register to reply here.
Top