Merlin’s weekly podcast with Dan Benjamin. We talk about creativity, independence, and making things you love.
Projects and multipe Next Actions question
vrillusions | Nov 15 2006
I've been doing the "tasks" part (I can't remember the official name for this, but the things that just have one action that you place in your various contexts) for a while now, but I'm still confused about projects and end up just making a task item when I really should make a project for it. The part that's confusing me is the next actions. "next" actions, and the way it's explained, even in the book, sounds like what's the next thing to do to progress this along. That part I get but what about the things that I need to do sometime, but not necessarily the next action? Let me give an example. I'm a programmer and I'm currently working on a new web interface for our company's intranet/ordering system. I have the next action set to "design db layout for account records" (I'm doing everything in chunks because of the size of this). As I'm working along or at home or wherever I'll come up with ideas that I need to do. For example I still need to create a way to change the employee passwords. Another one is the notes box I want to 'stick' to the bottom of the page. These don't have to happen next, it can happen whenever I feel like it, just has to be done before it's complete. Well there's probably a couple dozen of these loose ends that need to be done before I can say it's done, and that's so far. Do I make all those next actions? They don't really need to happen next to move the project along, that's really just the "design db layout for account records" action. Looking at th MonkeyGTD page, which was what I planned on using for projects, there's a tasks and a someday/maybe section, which is probably where I'd put all that stuff at. But they're also next actions as I CAN do them next if I wanted to, and it would move the project forward a little bit. And then what about the next "next action" after that db layout? Although I know that after I design it I then have to build it in SQL, and then after that I need to create the web pages for it, but what if I'm worried that I wouldn't realize what the next "next action" is after I finish this one? Another way of saying it is where do I put next actions that depends on the current next action to be complete? I guess the main thing I'm tying to understand is the difference between a Next Action for a project and what's just a Task for the project? I'm sure (in fact I'm almost positive) I'm making this to be a lot more complicated than it should be. 3 Comments
POSTED IN:
 We have all made GTD more confusing than it should be...Submitted by ops30 on November 18, 2006 - 1:13pm.
vrillusions, Glad to see that you've found some helpful info in another post. Let me see if I can answer some of the questions you asked... When it comes to project management, I've seen more variations among individuals than in any other area of GTD. As you know, DA recommends that you keep a project list in your system that lists the end results of everything you are committed to that require more than one action to make them happen. When it comes to project support info, DA recommends keeping a separate folder to hold the info. However, there are other methods. For instance, one of the moderators for this board, Emory, uses (pre-Tracks?) a separate index card in a Hipster PDA for each project. On the card he lists the outcome and the action steps needed for each project. Details of this can be found on his GTD whitepaper at: http://kvet.ch/pages/gtd-whitepaper-emory . I have found it to be a great resource. For myself, I use a hybrid of two methods. For projects that have a simple outcome and are usually pretty intuitive as to what the next actions are, I use a method called Cascading Next Actions. You can find info on it at: http://www.marktaw.com/blog/CascadingNextActions.html . For instance, right now I have a project called "Wash truck". My very next action to make this happen is "Get key to toolroom" since this is where I keep the water bucket and soap. This NA (Project) looks like this on my @Home-yard card: Get key to toolroom (Wash truck). I know that once I get the key and open the toolroom, the next action(s) required w/b pretty obvious. However, I do have certain current projects that are very similar to what you have mentioned. This is where I use the project management techniques that are laid out in Emory's whitepaper. What distinguishes these projects from following the Cascading style is that they are complex and require me to keep important notes about the project. For instance, one of my current projects is to earn a certification for my profession. I use a 3x5 card kept in the projects section of my Hipster PDA that list the outcome and all of the next actions I know (so far) are needed to complete the project. I have found it helpful to write on these cards in pencil since circumstances and/or new information can change or arise that affects what I need to do. Reference notes (contact ph #s, addresses of meeting locations, notes that point me to where info about the project is) are written on the back of the card or even a new card if necessary. I then go through and list all of the next actions that can be done on my context cards (@Home, @Office, etc). The one thing I have found useful to do is that once I have placed an NA from a project card to a context card I put a "*" beside of it, both on the project card and on the context card. This way, when I am looking at a project card, I can see which NAs are active in the system and when I see an NA on a context card with a "*" I know it is related to a 3x5 card project (also, when I complete an NA with a "*" it reminds me to look at the project card to add any additional NAs that I can now do.) Using the project example above of getting a professional certification, I actually have a master project card called: "Get certification" in which I list sub projects on to complete it (e.g.: "Pass section 1" / "Pass section 2" / "Get confirmation from state board"). I then treat each of those sub-projects like NAs, not by putting them on a context card, but by creating a separate project card for each of the sub projects and putting a "*" by each of the sub-projects on the master card. In that way I know which sub-projects have been put into the system. They are then treated in the same manner as other projects. The key to all of this is the weekly review. You have got to sit down every 5-10 days and make sure that everything is processed and updated in the system. Long post, but I'm going on my second year of GTD and this method of managing projects has been the best I've found for the way I work and live. Hope it can help you. » POSTED IN:
|
|
| EXPLORE 43Folders | THE GOOD STUFF |
