Can't implement the GTD methodology consistently

Vladfb1

Registered
Hey guys,

I just finished re-reading GTD book and plan to start reading it again. I also got in the loop with some podcasts.

The issue I faced in the past is that this system requires work and sometimes the number of projects are so high that organization and task management/reviews are disregarded in favor of completing the projects.

How do you guys deal with this?

PS: I'm doing GTD in company management, not only personal.

Thank you in advance!
 

Gardener

Registered
When you say that the number of projects are high, can you give an approximate number, and what sorts of projects they are? I find myself wondering if perhaps the overhead for project may be excessive? What does your current system look like--software choice, and so on?
 

mcogilvie

Registered
I find that the clarity achieved by calling anything with more than one action a project compensates for the large number of projects. If I am doing gtd right, the small projects get handled quickly. I cannot emphasize enough the need for tools that make that swift progress possible.
 

Vladfb1

Registered
@Gardener It's the type of days in which you work until you can't anymore go to sleep and work again.

IT projects/Ecommerce.

It was excessive and that's why we hired 3-4 new people.

We tried unsuccessfully asana in the past currently we have a gdoc template which we review weekly and I do some stuff in trello.

@mcogilvie

I am very used to tools as I'm a small dev myself.

Current mindstate is that I'm researching this method further, going to listen to all the podcasts.
 

2097

Registered
The issue I faced in the past is that this system requires work
The idea is that the decision work you are doing when you are doing the core loop of GTD (processing input and turning it into projects, next actions, calendar items, reference material, delegation, and trash) is decision work you would've needed to do anyway. You're just doing it right away.

Some of the benefits of this include

  • You can see if you are overloaded with work&projects and therefore cut some projects out or hire more
  • It helps you see which projects to cut and which to accept
  • You can get practice making tasks more atomically defined which is good for delegation
  • Projects can move along briskly that would've otherwise been procrastinated upon because they were vaguely defined
  • You can create efficiency by "batching" similar work
  • You can put decision-making and open loops out of your mind by committing to a plan for them instead of juggling them in your mind

sometimes the number of projects are so high that organization and task management/reviews are disregarded in favor of completing the projects.
Completing projects is a good thing. Well done.

You need to be a ruthless ninja and not turn every "Oh, yeah, it would be nice if..." into projects. Throw them in the big old Someday/Maybe bin! GTD shouldn't really be "adding" work.

Example 1. Let's say a vague email comes in. You think it might be something worth doing you're not sure uhh...

With GTD:
Just toss it in the archive you have plenty of actionally actionable things to do already.
Without GTD:
Let it sit in the inbox and bug you everytime you open the mail app. And eventually three years later finally delete it because the offer in it expired two years ago.

Example 2. Let's say a great suggestion comes in over phone. You think it's a great new client to work with and you're happy to get going.

With GTD:
You decide a rough idea about the outcome you want, commit to it, and pick out some first steps to take to make that outcome a li'l bit closer to reality. And later you take those steps.
Without GTD:
You want to work with the client but it never materializes for some reason. You just never could figure out how to move on...

If GTD is adding work, the most common reason is one or both of these problems:

  1. GTD tempts you to take on more projects, or to your projects more seriously. The dangerous thing about being kind of a slacker and letting some things slip through the cracks is that it does lighten your workload (at the expense of success). But I sure as heckfire value a light workload! Give me slack or kill me! Fnord! I just... want to decide what projects to cut vs just letting things randomly fall through the cracks.
  2. You are doing GTD in an overly cumbersome way that makes you fiddle with the project&task descriptions themselves too much, postpone them too much, review them too often, rewrite them, move them around, instead of actually doing the action the description is signifying.

Several times per day I bring my inboxes to zero. That costs 0 time, because, the time I spend deciding on the inbox stuff is time I would've needed to spend eventually anyway. It's time shifted (to be more upfront) rather than time spent.

Once a week I double-check that all my projects are moving along and that I haven't forgotten anything. With a good well organized system this can be really fast, and good apps can help here. And since it can help me catch important things that would've gone seriously awry, it's time well spent.

I'm doing GTD in company management, not only personal.
I'm not sure a "shared list of next actions" is a good or even feasible idea. Who would do what exactly?
Kanban stuff can work for work that is already very well defined and clear. But if all you're doing is very clear and well defined work, then you don't need GTD. GTD is to help you when you're being overloaded with vague and weird stuff!

My suggestion is that you do a personal GTD first and foremost. And since you're the boss, delegate stuff af! And then follow up!
And if you have workers that are delivering on that stuff then you don't need to micromanage them and force them to do GTD.
But if you have workers that are getting confused or procrastinate then you might need ta show them how to decide upfront on how to handle the incoming weirdorama requests from you or from your clients.

Good luck darl!♥
 

Gardener

Registered
@Gardener It's the type of days in which you work until you can't anymore go to sleep and work again
But how many projects? What kind of projects? How many are you working on concurrently? Are you making extensive use of Someday/Maybe to park projects? Can you reduce the number of projects and more often work them start to finish instead of concurrently? Concurrent projects have a cost--a very large cost.
 

2097

Registered
That's definitely true, Gardener.
The benefit of many concurrent projects is that you can batch things more efficiently by doing things that require the same kind of context while you're in that context and that you can more easily find small things to do for the small windows of time between bigger stuff. But finding the sweet spot amount of projects is a difficult balancing act. If there are projects who are missing their deadlines, that's usually a sign that there are too many.
 

Gardener

Registered
The benefit of many concurrent projects is that you can batch things more efficiently by doing things that require the same kind of context while you're in that context and that you can more easily find small things to do for the small windows of time between bigger stuff.
WARNING: Opinionated opinionatedness follows:

This would assume that the time saved by doing things in the same context, and the time saved by switching briefly to a brief task when experiencing down time between larger tasks, outweighs the time lost by frequent switch of focus between projects.

And that seems intuitively logical, but I think that our intuition is off here. Switching between projects, for knowledge workers, appears to be very, very expensive. It may often be unavoidable, but that doesn't mean that it's good.

I believe that switching between Jira and Slack and Stack Overflow and one's coding environment and walking to see Joe on the fourth floor, all in one hour, all in aid of a single project, is far, far more efficient than separating that work into a bunch of Jira tasks and a bunch of Slack tasks and waiting to catch Joe for several agenda items at lunchtime. Because the most expensive context involved in that scenario is the thoughts and theories and ideas gathered in your head. Your head is the piece of software that's most expensive to switch. So if you can stick to one project for several hours or several days, instead of doing little bits of ten projects in one day, you're going to be far more efficient.

Again, most jobs won't let you do that. But the fact that external forces make it impossible doesn't mean that it's not more efficient. Multi-project jobs are a necessary evil, not an efficiency strategy.
 

2097

Registered
We believe differently, but I don't know how to argue further for my point of view, not having done any studies. My own personal experience is subjective since I haven't done time-tracking experiments with stop watches and stuff. I definitely "feel" very strongly that I am wasting a lot of my time when I have too few projects and am context switching too much, but again, I know how misleading such subjective experiences can be.
 

Gardener

Registered
The description that I find most interesting came from David Anderson's Kanban. It's just one comparison, not the extensive study that would be desirable. But it's interesting.

Two programming teams, at the same company. One programming team had five to ten features in simultaneous development for the entire team. Another had an average of ten features in simultaneous development per developer.

The first team had an average start-to-completion lead time of five to ten days. The second team's lead time averaged three months. That's not the interesting news--of course if you're working multiple features simultaneously, each one will take longer.

The interesting news is that the first team had two to three defects per 100 features. The second team had an average of about two defects per feature. The first team's "productivity was five-and-a-half times greater with thirty times better initial quality."

This was all in spite of the fact that the second team was regarded as containing better developers, and had developers with more experience.

All leading to the conclusion that "the relationship between quantity of work-in-progress and initial quality is non-linear; that is, defects will rise disproportionately to increases in quantity of WIP."

I think that the greatest efficiency strategy is to reduce the number of projects you're working on simultaneously. You can't always do it. You can't even often do it. But I strongly believe that even minor improvements in project-switching--say, one project before lunch and one after and one tomorrow morning, instead of touching three projects in an hour--will improve productivity and quality.
 

TesTeq

Registered
We believe differently, but I don't know how to argue further for my point of view, not having done any studies.
Just accept the fact that people are different and there are some experienced knowledge workers out there who need to focus on one main Project and switch Contexts, not to focus on one Context and switch Projects. @Gardener
 

2097

Registered
I'm not denying that there is such a thing as too many projects. That's something I keep advocating for when there is overload: cut down on projects. Simplify your life.

But I'm noticing right now in my own life, when I parked most of my projects in favor one project that has a much much tighter deadline than anything else, that this comes at a serious efficiency cost. In my field context switching is very expensive.

Also, I'd say that GTD is a complete overkill if you are working on one project at a time. Instead of even having next actions lists, you'd just have a list of projects and then only for the first project you'd define the outcome and break it down further into steps, and not even bother sorting those steps by context since you're willing to context switch. It could be a super simple system.

Inbox stuff comes in, you store it in a big old pile. You grab one of the things from the pile, clarify the outcome and the steps. You do all the steps. Repeat. Way simpler than GTD.

The whole point of GTD is this "slicing your stuff from two directions" — clarifying the "recipes" for the "dishes" you want to "cook", but then detaching the ingredients from the projects and sorting them into context where you can do them. Boiling them down to atomic widgets that you can execute on.

If you are working one-project-at-a-time, I'd say don't even bother with GTD (for that particular part of your life). It's just pointless overhead.

For me, one of the wonderful things about GTD is that it doesn't really "cost" any time because the decision-making and dispatching I'm doing when spending time processing my inbox is decision-making and dispatching I'd have to do eventually anyway, and I'm pretty ruthless about cutting down projects and putting things in the round file (the garbage bin). But if I was doing one-project-at-a-time, there's no need to separate out that kind of dispatch processing.

The specific problem domain @Gardener uses as an example, adding features to software, is something that I already see as somewhat atomic. I wouldn't want to add half a feature then add half another feature then finish the first and so on. I can definitely see how that would lead to a hundredfold more defects. I've had better success with juggling different pieces of software at the same time than juggling multiple features for the same piece of software.

Just accept the fact that people are different and there are some experienced knowledge workers out there who need to focus on one main Project and switch Contexts, not to focus on one Context and switch Projects
When two people believe differently, and that difference in philosophy extends to beliefs about the universality of the application of their claims, sure, one way out of it is for one of them to "just accept" the others worldview. Or for the other person to do so—you could just as easily tell Gardener to "just accept" my philosophy here. But there's really no need for me and Gardener to be in consensus here. I'm not their boss and they are not mine. The study of knowledge work is a young field and in time one of us will be vindicated. I was trying to be humble here, instead of knuckling down and making unsubstantiated claims.

I was hoping @Vladfb1 would appreciate my advice (in conjunction with the advice from others) and make his own decision.

I'm going to take a break from this forum. Thanks.
 

mcogilvie

Registered
I am hesitant to inject myself into this discussion, but here goes. I am a scientist, a teacher and a manager, and I have decades of experience in those roles. They have been my work areas of focus for a long time. As I think everyone here realizes, individual experience varies widely, and may not be generally applicable. Furthermore, studies in the field of psychology have often proven to be unrepeatable when checked. We often must act, individually and together, with uncertainty as to the best course of action. For complicated problems, there may be exponentially many workable solutions (this is essentially NP-hardness). Some goals, like the “greatest good of the greatest number”, may not exist (this is the point of voting paradoxes like Arrow’s paradox). To put this somewhat theoretical discussion back at a practical level, too much focus on optimization is a bad thing, and your mileage may vary.
 

bcmyers2112

Registered
I'm going to take a break from this forum. Thanks.
Like @mcogilvie, I'm reluctant to inject myself into this conversation but will do it anyway. If it goes south, I'll blame @mcogilvie. :confused::D

Seriously, though, I think people here are making the mistake of taking as personal attacks things that are not meant that way. As someone who has made that mistake numerous times in the past, I can attest that it is just that... a mistake.

And if one is personally attacked (as I have been here, more than once, unmistakably) there is the mind over matter principle: if you don't mind, it doesn't matter.

FWIW.
 

RobertWall

Registered
Per the original question, I'm seeing something that @2097 brought up that I don't think made its way through the rest of the comments.

A *company* can't do GTD, because a company doesn't think, and it doesn't perform next actions. The *individuals* in the company can do GTD. And to the extent that they're all doing GTD (or have a comparable system in place), the whole company will function well. To the extent that they're not, or to the extent that their systems have leaks, there will be issues with company function.

And you can't have a whole company using a single GTD system.

I think this is really important. A project can arise from a meeting, and a "next action" can arise from the discussion of that project - but that ultimately has to go in an individual's system. And attempting to micromanage how an individual does GTD is counterproductive to the whole process.

For example....

If you look at things like the lean manufacturing process, it's instructive to note that things are delegated on a relatively high level. Management might pass off a spec like "design a brake system of size x that has stopping power of y that costs under $200 per unit". Then the people responsible for designing the system do the design.

In that process, the individuals in the design group will set meetings, order supplies, build prototypes, and perform thousands of "next actions" - but in a GTD system the initial delegation can literally be a "waiting for brake system design", with occasional reviews for check-ins and updates.

On the company level, all you really need to know is (a) what the actionable parts of the process are, and (b) who has the next action for each. And for any given person in the company, that's reference material, not a task list.

If somebody has to review a whole huge list of "what the company is doing" to get their own task list, you run into DA's warning about mixing actionable and non-actionable triggers in the same list, and people can numb out.

Just my thoughts, of course. :)
 

Oogiem

Registered
Switching between projects, for knowledge workers, appears to be very, very expensive. It may often be unavoidable, but that doesn't mean that it's good.

I believe that switching between Jira and Slack and Stack Overflow and one's coding environment and walking to see Joe on the fourth floor, all in one hour, all in aid of a single project, is far, far more efficient than separating that work into a bunch of Jira tasks and a bunch of Slack tasks and waiting to catch Joe for several agenda items at lunchtime. Because the most expensive context involved in that scenario is the thoughts and theories and ideas gathered in your head. Your head is the piece of software that's most expensive to switch. So if you can stick to one project for several hours or several days, instead of doing little bits of ten projects in one day, you're going to be far more efficient.
I both agree and disagree.

I do both knowledge work and more traditional work. I still stand by my assertion that, for me, switching between major applications is far more disrupting than switching between projects within an application. But I also consider programming to be a suite of stuff and basically 1 application. When I am working on LambTracker the major focus is the development environment I work in, but ancillary to that is my iPad with notes and manuals, my stack of post-it notes that are the bugs, tasks or enhancements and other issues I am working on and a spare window with a browser up where I can search for answers, whether in Stack overflow or generally on the web. I tend to try to work within a specific module at a time as I find that switching between modules within LambTracker is also hard UNLESS the code I am working on (sheep look-up via EID for example) is in many places and not yet in some sort of library function. In those cases I will fix the code in one module, save it out to DEVONThink for use elsewhere and then, usually I will continue in the buggy module I need for the sheep task. If I am just fixing minor irritants that don't affect operation type bugs or adding enhancements I will often add the fixed code in all modules where it goes.

Where I gain the most by separating computer by application is to isolate all my LibreOffice, Scrivener, LightRoom and Photoshop (also a suite of related apps), Grassroots and Banktivity tasks into a separate list. Once in Libre Office I can easily add and edit lots of things related to varying projects with minimal effort. But switching out from LO into Scrivener is painful and requires I reset my brain to think in that app.

So for me defining contexts into logical groups includes a liberal use of single app contexts as well as some that necessarily span more than one app. So I have a LambTracker context (BTW that requires also @computer internet, both iMac and MacAir laptop and iPad which are also separate contexts for me for things that are not LambTracker)

There isn't one only way to work and it works differently for various projects.
 

mcogilvie

Registered
Like @mcogilvie, I'm reluctant to inject myself into this conversation but will do it anyway. If it goes south, I'll blame @mcogilvie. :confused::D
Thanks! We can hide out in the badlands together until the posse gets tired of looking for us. :)

“In theory there is no difference between theory and practice. But, in practice, there is.”
Attributed to Albert Einstein, Richard Feynman, and Yogi Berra, among others.
 

RobertWall

Registered
Switching between projects, for knowledge workers, appears to be very, very expensive. It may often be unavoidable, but that doesn't mean that it's good.
Based on personal experience, the reason that switching projects gets expensive is because contexts are mental rather than just physical - and for sufficiently advanced projects, switching projects requires a switch of mental context as well.

Consider....

If you're washing dishes, and your kid comes running into the kitchen because they need their volleyball inflated, you put down the dishes, dry your hands off, inflate the volleyball, and go back to doing dishes. Even if it takes you 5 minutes to go to the garage, get the inflator, figure out how to inflate the ball, etc., your total *switching time* - relative to the task of washing the dishes - is only something like 30 seconds. If every kid in your neighborhood needed a volleyball inflated over the course of 2 hours, you'd lose:

(number of volleyballs) x (time to inflate a volleyball + 30 seconds for context switching)

12 volleyballs @ 5 minutes each would be 1 hour & 6 minutes. You'd still have a solid hour to get dishes done, and would probably be moved on to the next task by the time the fifth volleyball showed up - at which point your next task might be "find place to hide so I don't have to inflate volleyballs". :)

If you're trying to write your novel, though, the work isn't physical - it's mental. And there's a mental context that's hard to export when you get interrupted, and hard to import when you come back. So your switching time might be 10 minutes per interruption. At that point you would honestly be better off just going outside and playing volleyball with the kids.

I think that might be what @Oogiem might be driving at. Divvying up work into "apps" makes sense if "open the app" is one of the main switching costs. But if "mindset" is the main switching cost, you can flip from your dev environment to the browser to email to a phone call to your reference manual to your stack of bug reports back to your dev environment with very little perceived switching cost, because the mindset is the critical thing - not the apps.

Just some thoughts. :)
 

Gardener

Registered
But switching out from LO into Scrivener is painful and requires I reset my brain to think in that app
Interesting. That suggests an expansion of the premise that one's brain is the most useful, and hardest to switch, piece of software. And as I write that:

think that might be what @Oogiem might be driving at. Divvying up work into "apps" makes sense if "open the app" is one of the main switching costs. But if "mindset" is the main switching cost, you can flip from your dev environment to the browser to email to a phone call to your reference manual to your stack of bug reports back to your dev environment with very little perceived switching cost, because the mindset is the critical thing - not the apps.
Yep!
 
Top