Forum

  • If you are new to these Forums, please take a moment to register using the fields above.

Announcement

Announcement Module
Collapse
No announcement yet.

Projects or Buckets ?

Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Projects or Buckets ?

    I often tend to create 'buckets' in my GTD system
    Is this a bad practice of GTD ? Should I really make certain items an individual project ?
    Or simply leave next actions in a bucket ?

    Example:

    (Bucket) Improvements to iPhone
    I'll always have ideas to park inside this bucket.
    It's simply a parking lot for ideas to grow into it keeps an actionable project.

  • #2
    AoR Buckets, that's all

    I am using an app that has "projects" listed in the left menu. I personally think the 10 k micro-projects are too small to be allowed to take up a long (scrolled!) left menu, and they do not give me the higher-level overview I want, so I use the app's project feature as:
    • Area of Responsibility (20 k) folders (buckets) (these will "never" be completed, i.e are not projects at all)
    • Major Objectives (30 k) (these will be completed at some stage and are "projects" in the everyday English sense)
    Then I use other features in the software to deal with the further breakdown into smaller projects or micro-projects and tasks.

    I never use any other kind of buckets than AoR buckets.

    Comment


    • #3
      Originally posted by Rainbow6 View Post
      I often tend to create 'buckets' in my GTD system
      Is this a bad practice of GTD ? Should I really make certain items an individual project ?
      Or simply leave next actions in a bucket ?

      Example:

      (Bucket) Improvements to iPhone
      I'll always have ideas to park inside this bucket.
      It's simply a parking lot for ideas to grow into it keeps an actionable project.
      It depends on you and the tools you use. The example you give seems like a
      someday/maybe item to me. You might want to:
      have one someday/maybe item with ideas in the notes section
      OR one s/m item per idea sprinkled in a big list
      OR a list of ideas just for your iPhone.

      Personally I have done a bit too much of the last possibility to recommend it. Excessive gathering of minutia is something I have to watch out for, and I have better things to do with my life. It is very important to weed lists regularly. Probably the best thing you can do with something like iPhone improvements is to put them on a list like
      @Anywhere: Decide buy snazzamatazz for iPhone
      and then decide and don't second guess.

      Comment


      • #4
        I would add that kind of stuff in a categorie "iPhone improvment" withing my Someday/Maybe list. Those that you want to do asap should become a project or a single action.

        Comment


        • #5
          No buckets for me

          For the type of example you mentioned I agree in particular with mcogilvie. Be careful!

          Personally I do not keep permanent "buckets" (folders, projects, tasks) that are based on "activity type" or "context type" or anything of that nature. Instead, all my stuff is organized in direct relationship to a concrete outcome (result). That helps me stay sane. The only slight exception I make to this is my AoR folders at the top level. And I also make exceptions for very short-lived "special context" efforts.

          I would not consider "iphone improvements" to be an end in itself, i.e. not anything I would organize in a "bucket". If, for example, I wanted to be able to add a good pdf editor (or other snazzamatazz) to my iphone, then I would add that either as a single action (as mcogilvie said) or I would make it a part of some larger project for which pdf editing on the phone will be necessary. I would not even attempt to fundamentally organize everything that is iphone related in one common "bucket" just because they are all iphone related. But:

          Sometimes - very often, actually - when I get close to actually doing things, it becomes highly desirable to make the best use of whatever "special context" I realize that I may need to temporarily create for one or more tasks. For example, if you had to open your iphone (mechanically), then it probably would make sense to make use of this special temporary context (to have the iphone open) and add all the snazzamatazzes you have decided on all in one go, right? Even though the various snazzamatazzes probably belong in different projects (for perhaps entirely different purposes and goals), they also belong together, practically speaking, in a micro-project that you might call "open iphone and add snazzamatazzes A, B and C"). Normally (in most software I have seen) you cannot really manage "multiple citizenship/multiple parents" for the individual tasks, so what I usually do is I do create a separate task or project - a "temporary bucket" if you will - for it, but I do not move the individual tasks from their original projects; I just list the various snazzamatazzes, and the projects they really belong to, in the task's notes. I leave the original tasks in their respective projects for being logged properly in my logbook and for the case that the special-context micro-project never comes to pass, and most of all in order to see the tasks clearly in their right environment if I review the project before I have gotten around to actually opening the iphone. I do not create "contexts" for these "special temporary contexts", because it is more messy, and I would need to remember to filter by each and every such special context all the time - better to have it as a task, visible straight on the regular list.

          Comment


          • #6
            buckets aka single actions lists

            @Rainbow6
            Hi! I use "buckets" too, I just call them Single Action lists and I bring them up a level to my Areas of Focus & Responsibilities. So for instance, any active single actions that might land in an 'improvements to iPhone' category would go into a "TECH Single Actions" list for me. I find this helps remind me of the task's importance and relevance.

            The trick is to really only add single-action items to these lists. If it's a multi-step project, I really need the trigger of an empty project to remind me to capture the next step once I've completed the one I wrote down. And if my brain has to remember whether or not there was something that was in my bucket I completed but has a next step, then I've undermined the trustworthiness of my system. And then I'm back to mind like mud.

            By the way, I also keep an 'AOF Someday/Maybe' bucket list in each Area of Focus folder. I put this folder on hold and make the context for all items someday/maybe. This keeps all of these items out of my next available items when actually doing. Oh, and I use OmniFocus, in case that's helpful to know.

            -Michelle Gunn

            Comment


            • #7
              Originally posted by Rainbow6 View Post
              I often tend to create 'buckets' in my GTD system. Is this a bad practice of GTD?
              Well... maybe.

              As a "parking lot for ideas to grow into" it's a pretty good idea, and I give it a thumbs-up.

              As a place to "simply leave next actions in a bucket" it's a really bad idea, and I give it a thumbs-down.

              If you need further clarification on what I mean, I'm happy to oblige, but I feel like that's probably enough to get you on the righteous path.




              Cheers,
              Roger

              Comment


              • #8
                Originally posted by Rainbow6 View Post
                Is this a bad practice of GTD ? Should I really make certain items an individual project ?
                Or simply leave next actions in a bucket ?

                Example:

                (Bucket) Improvements to iPhone
                I'll always have ideas to park inside this bucket.
                What you describe as a bucket is IMO an AOF. I am firmly in the camp of projects not buckets. Nearly always when I create a list of single action items it turns out that most of those are really projects in disguise.

                Now it does make sense to have a "bucket" for an AOF to collect the someday/maybe things that you may later turn into projects. However, in my tool I just create those ideas as projects and set them to on-hold. When I make them active I'll flesh out the outcome and set next action(s).

                So I'd have a folder called Improve my handheld tools (because it might not always be an iPhone) and within that a bunch of ideas that may or may not be projects that are active right now. Like Learn how to integrate Siri with Omnifocus which is clearly a project not an action. Or Find a better date calculator to calculate gestation dates, another project. When I make on of those projects active I get to decide what the next step is. So for the date calculator my next action might be Search on Apps store for date calculators that run on iOS 7 that allow calc between dates.

                Comment


                • #9
                  My system (in OmniFocus) has projects, Single Action lists, Thoughts, Lists, and Project Seeds lists. I'm not saying that these things are GTD-appropriate, I'm just saying that they're what I do.

                  Single Actions are an actionable goal that I want to do soon (that is, it's not Someday/Maybe) that can be achieved with only one action. For example, Wardrobe Single Actions might contain "sew that button back on my raincoat".

                  There are circumstances where that action could be a project. If I'd lost the button, for example:

                  Project: Raincoat button fixed
                  Measure raincoat buttons
                  Find 3/4" black button for raincoat
                  Sew on raincoat button

                  If I didn't know how to sew on a button, the project could instead develop as:

                  Project: Raincoat button fixed
                  Ask Jane what I need to sew on a button
                  Buy hand-sewing needles and beige thread.
                  Make appointment with Jane to teach me to sew on a button.

                  Even if the action is a single action, it could be a part of a project:

                  Project: Broken clothes mended
                  Fix drooping hem on black linen skirt
                  Sew on raincoat button
                  Sew hook closure on red skirt

                  But if I'm not interested in a whole clothing repair project, and I just want the button fixed, then this is a single action.

                  My Project Seeds lists, on the other hand, contain "actions" that I know perfectly well are projects and not actions, but since I'm not ready to start working them, I don't bother to expand them. Actually, I make a point of NOT expanding them, because they'll just clutter up my lists. So my Project Seeds lists might contain "Fix all my broken clothes," a Someday/Maybe that eventually develops into the third project above. Items in this list are essentially Someday/Maybe, though I feel that there's some nuance of difference that I can't put my finger on.

                  My Thoughts lists are just a place to dump thoughts that aren't even sufficiently formed to be a project seed. For example, if I remember the name of that sewing book by that author that I really want to read again, I'll dump that into "Sewing Thoughts" just so I know where I put it. I'm not sure whether, in GTD terms, this is an Inbox that I haven't sorted yet, or if it's project support material that I choose to keep inside my GTD system.

                  I also maintain plain old Lists, which I just consider to be part of my filing system, even when they happen to reside in OmniFocus. Books to Read, Perfumes to Sniff, Seeds to Consider, and so on. The lists may feed actions ("order something from Books to Read from the library") but they don't consist of actions.

                  I would say that if something is actionable, and you want to be acting on it, and it has more than one step, it "should" be a project. I say "should" because the importance of defining it correctly depends in part on how much you're hampered by its not being a project. For me, the problem of projects-presented-as-actions is that I look at my lists to find an action to work and I find myself saying, "I should...no, first I have to..." several times, breaking my flow.

                  And if I haven't defined the "first I have to..." action, odds are that I'll miss that action when I'm in the right context. For example, the first raincoat button task requires me to measure the button while I'm at home and then buy the button when I'm at the right store. If I rarely get to the right store, then I really want to be prepared when I do get there. If I pass it every day on my way to lunch, it's less of a big deal. So while you "should" distinguish actions and projects, the strictness may depend not only on your preference, but the particular project.

                  Comment

                  Working...
                  X