When do you call something a project?

Here’s a sneak peak at our new GTD® Managing Projects Audio Set releasing soon. This new set includes 6 CDs chock full of a tips, tricks and education on the GTD models for seamlessly managing your projects. You’ll hear from David Allen and two senior coaches on the best practices and common questions people implementing GTD are asking about.

Listen to a 5-minute sample track:

[HTML1]

Stay tuned to Productive Living or GTD Times to learn when it’s available. Soon! We promise!

11/19/2010 update: It’s now available! Visit the David Allen Company store.

Join the Conversation

7 Comments

  1. Here are some of the distinctions I made through this audio

    -If something cannot be finished with one step, then have some placeholder, so you can go back to it.

    -Eg Is a meeting a project? Quarterly meetings where people are flying in from around all the world, would be considered a project as it involves a number or steps and organisation.

    -What do you need to do to get this off your mind? If its a lot of different things, then it becomes a project.

    -Get creative with list making, and reward yourself in the process with little wins.

    Wow, these are some really great tips.

    Thanks so much! I’m totally “FOR” the little rewards with the list! haha

  2. When I first started GTD I had a resistance to the term “project” because of my old paradigms. I resisted adding to this list for a while, especially those “simple” things that may only take two or three steps. However, I found that those “simple” things were still on my mind because I wasn’t managing them appropriately.

    For example, I once put “Replace batteries in motion sensor” on my @Home list, but I didn’t have the right batteries on hand. I didn’t move it to the Projects list right then, but I did add “Buy batteries” to my @Errands list. However, the thing still didn’t get off my mind and I an action on my @Home list that I could not do. I didn’t even want to look at that list anymore because I had many things that I couldn’t do on it. My brain would not let it go of it, either.

    Eventually I accepted the fact that I had to call a project a project, no matter how long that list got. Once I started doing that my system was much cleaner and my brain trusted it more. Now I don’t even hesitate to create a project if I doubt in the least that an outcome can’t be finished in one action. An up-to-date Projects list really is one of the most liberating things for your psyche.

  3. My (probably incomplete) understanding of GTD is that it doesn’t specifically address complex projects with lots of moving parts and lots of complex interdependencies between them. I suspect that part of the “magic” of the weekly review is that it allows you to deal with the interdependencies – in your head.

    I find it helpful to add sequence or thread as a layer between action and project. It’s a sequence of actions to do one after another such as measure garage door, buy part, not in stock, order part, follow up.
    I find it helpful to stack up multiple future actions in a sequence (when the likely sequence is known) then work through them one after another.

    This does not address more complex projects which would have dependencies between actions on different threads but a high proportion of my projects are simple threads and it helps get those off my mind.

    I think GTD still has some room to grow in it’s handling of projects. I would like to be wrong here and welcome comments further explaining how GTD handles projects.

  4. Hi Greg,

    I can tell you that the new GTD Managing Projects set does talk about the dependent steps and where to park them. https://secure.davidco.com/store/catalog/GTD-MANAGING-PROJECTS-AUDIO-SET-p-16670.php?s=hp

    It’s actually totally fine to capture those dependent steps somewhere, we just suggest people not put those on the same list where you are looking for actions you can take now. Otherwise, you’re sifting through lists of things you can do now (Next Actions) and can’t do (sequential or future actions.) That kind of sifting takes time and effort.

    For large scale projects that require some kind of robust project management tools (like PERT or Gantt), you’re right–GTD is not designed to do that. But you can work those together. You can always get value from the fundamental GTD questions:

    What’s the outcome?
    What’s the next action?

    Those will apply to any size project.

    Hope this helps!
    Kelly

  5. Hi Kelly,

    thanks for the link. It does look helpful but unfortunately the 99 dollars is a bit of an issue at this point.

    Instead, I skimmed through GTD chapter 3 again. This time all the references to envelopes and whiteboards really stood out. I have completely computerized my action lists and I’m satisfied that I have everything I had when my lists were on bits of paper and more. I find projects more difficult to computerize. But now that my action items are successfully on the computer I want the projects there too.

    The concepts in GTD chapter 3 remain completely valid. p58 mentions sequences, for example. But planning projects on paper is an assumption that no longer feels valid to me. Paper gives you a lot of flexibility that can be difficult to recreate on computer. On the other hand computers do force you to clarify your process in a way that GTD may not have done yet.

    The GTD® MANAGING PROJECTS – AUDIO SET write up does appear to tackle some of these issues. I look forward to absorbing the ideas when they come out at a lower price!

  6. If your effort has time, budget and scope it is a project. If it does not, it is not. Product teams that perform work towards their roadmap goals are not doing projects. They are just a different effort towards that goal. Projects are good for simple, repeatable, efforts where we have low complexity, high certainty, and are more able to predict effort of work because we’ve done it before. The traditional, predictable model works here. Where it does not work is in most software development efforts because those efforts are high complexity, high uncertainty, not repeatable work and we learn more and uncover more of the unknown and uncertainty by doing the work. Use the Cynefin framework to help determine whether you should be using project management, traditional models or adaptive models. In my experience, most software development where we should be bringing work to a healthy team is not project work. When product organizations continue to use projects they are falling back to post industrial thinking and ineffectively bringing people to the work which causes team disruption and unhealthy teams. See Smith/Tuckman and Katzenbach models around what happens to teams effectiveness.

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.