GTD Lite

[dal1mdm]

Life is an open loop.

I wonder if there are others out there who are content with a partial impelementation of GTD. There is no way my lopsided right brain could ever implement the full blown GTD methodology. There are just too many pieces. It feels like life under a microscope

Am I the only one? I keep lists of projects and NA's, but the weekly review, the filing system, the areas of focus, etc. Are you kidding me?

 

[kewms]

IMO, if you skip the weekly review, you are missing the most important component. Among other things, the weekly review is essential for making sure your system really is trustworthy. Without that, nothing else works.

Katherine

 

[jpm]

Life is fulfillment completed one next action at a time.

Being left brained is only a limitation to implementing GTD if you believe it is. Your implementation may look a lot different than mine on the surface, but the same principles apply.

GTD gives you a wide angle and zoom lense on your life. You can look at the big picture or zoom in on the smallest details.

Mimimalist GTD:

1. Next Action list by context.
2. Someday Maybe list.
3. Projects list with Project Planning & Support Materials
4. Inbaskets/Collection Buckets
5. General Reference Filing System
6. Weekly Review.

Without any one of these six things you really (IMHO) doing GTD.

This of course doesn't get you to the higher perspectives, but once you master the above 6 the higher 30,000+ foot levels are pretty easy.

 

[furashgf]

i'm able to do the minimal stuff above, but I still haven't been able to get to the complex brainstorming and organizing activity you're supposed to do for any sizable project. Not sure how people deal with that - I've posted before about it but it's something I'm not getting.

 

[kewms]

i'm able to do the minimal stuff above, but I still haven't been able to get to the complex brainstorming and organizing activity you're supposed to do for any sizable project. Not sure how people deal with that - I've posted before about it but it's something I'm not getting.

Can you give an example project and explain how you would approach it? It's possible that your projects simply aren't big enough to require much thought. It's also possible that you're already using a GTD-friendly methodology, but just don't recognize it as such. If you're happy with the approach you're using, don't worry about it. If not, maybe you could tell us why not?

Katherine

 

[furashgf]

Well, here's a good example. The project is "Rewrite Document Generation System." So, we've got a project plan and a bunch of documents that evolve over time. It's a decent size project, I have to coordinate, organize, etc. the work of programmers, staff, communicate w/ users, etc.

So, I've got a project plan - which is a bunch of tasks, mostly focused on the programming orented things.

However, there's tons of "stuff" that goes with this project. Hundreds of nudges, etc. I could be doing.

So, what I think I'm supposed to do is do a full-on brainstorm/organization of the project. I've got a trigger list (see attached) and an outlining tool I like to use. So what I should do is take all the materials and notes I have, and work through my trigger list and brainstorm a super-detailed plan, then organize it as he describes. Then, on the weekly review, I'm just "picking the next task" from this super organized hierarchical plan.

Instead, what I have is a list of stakeholders and what they want, and during the weekly review I just come up with next actions. I don't have any trouble coming up with them, but (1) just looking at the name of the task and coming up with next actions isn't the same as pulling a task off an organized list and (2) I'm guessing the reason the GTD book suggests doing this is it helps identify ALL the stuff you/someone could be doing, not just what pops into your head. I'm sure that if I were able do do this process like all the other GTD people are, I'd find all sorts of tasks I could do that would make the project even better. I can start on the brainstorming thing, but about 10 minutes into it I end up not finishing it. Multiply this times 30 similarly complex projects, and there you go. I've stopped trying to brainstorm/organize during the weekly review, because I never finished a weekly review when I did that. When I make "Brainstorm/organize project X" a NA @Anywhere, that doesn't work either since I skip it because the combination of energy/time. i.e., nearly any other task on my list looks intuitively like a task that I could handle as opposed to that task. I don't think its tools, because the tool I use to outline/brainstorm is a tool I use all the time for other activities and I enjoy it. It's not that I don't know how to brainstorm, since that's how I get the team to come up with task lists, etc.

 

[Brent]

Regarding a partial implementation of the system:

Getting Things Done is kind of like a car. You can buy an engine, and that's nice. You can buy a frame, and that's nice. You can buy a gas tank, and that's nice. But they can't fulfill their full purposes unless they're all put together and integrated.

There are some optional niceties like air conditioning in a car or the Outlook Add-In in GTD. But there is a certain fundamental set of practices, without which the system works at only at a small fraction of its true potential.

 

[Brent]

Hmmmm. I think you may have gotten the wrong idea about GTD.

GTD does not require a super-detailed plan for each project. Far from it.

All you need written down are a goal, and the next physical visible action. You can plan if you want to.

Sounds like the overall project can be divided into a number of distinct projects. What if you identified the specific goal for each part of the overall Document Generation System Project, then worked out just the next thing that needs to be done?

The "higher-level" planning in GTD is more about identifying what you want to do and how your projects fit into your larger goals (e.g., "writing a short story" as part of "becoming a writer"), as I understand it.

Does that help?

 

[kewms]

Your approach sounds fine to me. If the project is moving forward and all the stakeholders are happy, don't worry about it.

Why do you think you need a more detailed plan? "Because the book says so?" Or do you feel like the project is out of control in some way and being more organized would help?

My understanding of GTD is that DA advocates doing exactly the amount of planning you need to do to feel like the project is under control, but no more. He absolutely does *not* suggest that you should plan out every single NA for a six month project in advance. Quite the opposite, in fact.

Katherine

 

[furashgf]

That makes sense. The reason I think I need to is because most GTD people posting talk about, during the weekly review, getting the NA from your organized plan. I'm NOT doing that. I'm looking at the name of the project, maybe glancing at the stakeholders/vision, and then coming up with 1-5 or so next actions to do.

Now that you describe it, a super-detailed plan would probably not survive encounter with reality and you'd end up spending all your time updating your super-detailed plan. That happens with big "P" project plans all of the time. It's called the "glass case" plan, where the project manager either spends all his/her time updating a plan to make it match to today's reality, or everybody gives up on the plan because it's out of date (it's in a "glass case").

 

[Brent]

Thank you, furashgf! You've precisely described an aspect of GTD that I love, probably better than I can describe it. Detailed plans typically don't survive impact with reality.

You wrote, "I'm looking at the name of the project, maybe glancing at the stakeholders/vision, and then coming up with 1-5 or so next actions to do." That sounds exactly like the process I see in the GTD materials. I think you're doing great.

 

[kewms]

Again, if the project is under control and moving forward, everything is fine from the GTD point of view. If it ain't broke, don't fix it!

In fact, the people who talk about pulling NAs from a detailed plan at the Weekly Review often seem to be posting to complain about the amount of time it takes to maintain and update all of their lists. In other words, *exactly* the symptoms of "glass case" planning that you mentioned.

Katherine

 

[jpm]

Plans are nothing, planning is everything...

I believe that's from Eisenhower...

The detail to which you plan a project depends a lot on the nature of the project. If you're putting up a skyscraper, then a detailed project plan is probably a critical part of the project. Once the blueprints are finalized there aren't a lot of changes that go into the design of the building. There may be cosmetic changes and schedule changes (and even budget changes), but if you start making major structural changes your project is in critical trouble.

For most knowledge work however, the objective of the project can change at any time and any part of a project can suddenly become critical or completely irrelevant. Thus planning to the most minute detail is probably a waste of time.

So a knowledge work project is best planned not down to every single action or task, but at a higher level. Brainstorm the initial milestones that may be important, or key considerations that will need to be addressed. Identify any next actions and then re-visit the plan each week during the weekly review. Check the plan. Are the milestones still valid? What are the next action(s)? Simple, easy and quick.

One other key point. Your initial project brainstorming should not be done during the weekly review. Particularly not for big projects. Break it out as a next action or put it on your calendar.

That's what has worked for me...

 

[wordsofwonder]

This is a question I've been thinking about lately, as I've been simplifying some elements of my system that I felt were taking too much fiddling around with to keep working.

I am a writer and computer geek -- my project list on any given day could include things like "apply security patches to the ABC server" and "fix the login bug in the XYZ web app", and also things like "write the first draft of the article about DEF" and "revise chapter 3 of the novel." Some of these projects are great big huge things, and some are fairly quick and small.

In both sets of circumstances, I've found my planning needs to be just enough to answer three questions, and no more than that. The three questions are:

1. What is the goal/outcome of this project? (For example, "By the end of July, fix the ABC Web site so the login works properly.")
2. What is/are the next action (or few actions) to move that project forward?
3. Do I feel like the project is under control and moving forward?

As long as I have answers to the first two questions and the answer to the third is "Yes", I'm good to go. If I don't, then I brainstorm or write down a couple more action steps and try again. I may have a detailed project plan or specification in my files, but my GTD planning only need include the next few actions it takes to move a project along. I tend to plan a maximum of one next action per context for a given project, unless I have a reason to sketch out a few more.

-- Tammy

 

[furashgf]

That's what I've been doing, and it works fine. I've just always thought I was supposed to be doing something else.

 

[Juno]

I'm with you

I'm figuring out that for me, the simpler the better. The biggest value for me is capturing all the 'stuff' in the trusted place, much more than figuring out NAs or plans for anything. So mostly a notepad or index card at the ready is plenty for me. I really do experience the peace of getting my gotta dos and wanta dos where I can find them later, rather than diverting my attention and spinning them in my brain when I should be doing the task at hand.

Then those things either get done or added to a project list that I am keeping. Seeing all the projects on one page means I wont forget them. All I need to know is the next baby step to move things along for NAs, and the different contexts just make it super efficient.

It's about the third time I've started up with GTD and so far this time I feel much more empowered.

 

[furashgf]

In keeping with the GTD approach, I think I'll just put in a deferred item to get more into planning a year or so out, and just focus on getting the mechanics 100% pat - 2 minute rule, weekly review, etc. Not denying that beautifully articulated mind maps aren't useful, but it's probably best to get the other stuff solid first.

 

[TesTeq]

GTD does not require mind maps.

Not denying that beautifully articulated mind maps aren't useful, but it's probably best to get the other stuff solid first.

GTD does not require mind maps. Many people like to use them for planning but it is not mandatory.

 

[wordsofwonder]

That's what I've been doing, and it works fine. I've just always thought I was supposed to be doing something else.

I tend to favor the mentality advocated by the Extreme Programming folks: Do the simplest thing that could possibly work, and refactor mercilessly when things start getting unwieldy.

I have to keep a certain amount of self-control to avoid turning legitimate refactoring into an expression of monkey mind , but the general principle is still good.

-- Tammy

 

[Brent]

Thanks for the "Monkey Mind" link! Based on a brief read of the first few paragraphs, I've just printed it off for a thoughtful read later.