A computer programmer implementing GTD asked David Allen about projects:
I’m confused about (and I’m sure you are extremely bored with this question, but from the books I couldn’t work out the answer) – how do you size projects? I’m continually having problems working out what is or isn’t a project – and getting lost in the confusion.
I’m a computer programmer. I have to design systems and then build them. A typical “task” of mine will last 6 months – and involve maybe 800 real hours of my own work. There will be all sorts of things inside that that can be done simultaneously, things that I have to wait for and so on. Is the whole thing a project? Or do I break it into individual projects of do the first screen, do the second screen, do the back end?
I even have trouble with the concept of next actions – because more often than not nowadays everything is done for you – my task of “build a content management system” – actually becomes “find a content management system” – sitting on Google looking at products, downloading them, trying them etc. This task could take me anywhere from 5 minutes to 5 days – and I don’t have any idea before hand how long it might take – most of what I do is investigative. For instance, “fix the credit card processing” – that’s my task – but at first I don’t know what’s wrong with it – I have to try things until I do find out – and it could easily take me the next 8 hours solid work just to identify a problem, or I might find it right away.
GTD seems to work brilliantly if I have lots of tiny jobs to do and keep track of (such as in my personal life) – but in my professional life I can’t figure out at all how to integrate the concepts of projects being composed of many sub-projects and more importantly of tasks of which the duration is completely unknown and unpredictable.
Any suggestions you could give me would be greatly appreciated.
David’s reply:
Good questions, and my answers are likely going to be simpler than you think.
First, anything you can finish in a few months needs to be reviewed at least once a week – that’s why I call them “projects”, so they sit on that list and get looked at with rigor during the Weekly Review. If they’re as complicated with sub-projects as many of yours likely are, then you just need to drill down another level in the Weekly Review on each one, identifying the “moving parts” – i.e. the ones that are not dependent right now – and ensure that you have next actions on each one, as appropriate.
“Next action” doesn’t mean short – it just means that you know exactly where the action happens and what it looks like. So it could be a 20-hour action – you’re just clear that it’s at your computer it moves forward instead of the hardware store.
Great post !
I’ve also some doubts managing Projects. I’m in sales and I use GTD also to keep contacts with customers. All my GTD system is based on Things for Mac and iPhone + basic folders for paper items.
The problem is that I’ve opened a project for every customer/opportunity and I put inside the next action related to him (like “call for followup” or “send email with prices”) but also notes (like last meeting discussions or customer’s taste, ecc…) to have all in same place.
But in this way that projects never ends and in the same time during weekly review I find myself mixing the focus between these “special projects” and the real projects with steps from start to finish.
Some suggestion?
Thanks and Best Regards
Massimo
p.s. I’m from Italy, few weeks ago I received an order of some GTD stuff (many folders) plus and unexpected really beautiful pen! Thanks so much! Really appreciated.
Hi Massimo,
I’ve seen people in sales manage their accounts two ways: as Projects or only as Areas of Focus. The tricky things about managing them as Projects is that they don’t end–they have ongoing maintenance and management. Unless, you are expecting a particular closure or outcome on an opportunity. But managing them as a Project would certainly get them in front of you more often, especially if they have a cycle of completion.
Chip Joyce, a community contributor, has written several articles for GTD Times on managing accounts. This one in particular might be helpful for you: http://www.gtdtimes.com/2009/08/13/adapting-gtd-to-managing-sales-and-clients/
I’ll let Liz & the Products team know you liked the pen. I’m sure they’d love to hear that. They work hard over there in Products & Shipping!
Kelly
To the original poster: I also write software and I know just what you mean. Some of my “next actions” have taken a year or more. My rule is, if I can break it down into clearly defined, predictable steps, I put it into my projects list and I put the next action into the appropriate context lists. But sometimes, as in the case of “fix the bug in …”, that just doesn’t work because you can’t define the next action so easily, or as I’ve found, each next action depends on the result of the last (diagnose the source of the bug, find a solution, implement it, test it, repeat). Since it’s impossible to predict how long each step will take, it doesn’t make sense to keep interrupting work to update the next action list. For tasks like these, I just go ahead and put “fix the bug in …” on my next action list, and I work at it until it’s done. For complex problems, I keep both paper folders of scribbles and electronic files of output to help me keep track of where I was when I left off. I suppose those are akin to project support material. Then, if I’m not 100% sure the bugs are all worked out of a component, but I can’t produce any with the test cases I can think of, I put “waiting for bug to appear in …” in my waiting for list.
Hmm. I’ve always thought of a Next Action as being “atomic”, i.e., indivisible. It might take more than a few minutes, but once you started, it would end up being completely finished. Your pegging their range up to 20 hours makes me wonder.
The bane of my next actions are the ones that only get half done, which is why I strive to make sure that I don’t create any such actions. For instance, I created an action to caulk the gaps that have opened in our siding. But really, it’s two actions: to caulk the gaps I can reach, and a larger and longer term action to get a contractor with a huge ladder to reach the rest.
Many compound actions break down like this and cause much trouble if I don’t recognize their dual nature.
Anyway, do you consider Next Actions to be “atomic” as I have described?
I would agree with that, Peter. A next action is precisely that – a single indivisible item.
I’m also a computer programmer/analyst. I struggled with this issue in the past and have some relevant experience that might help.
I suggest that you track the largest outcome that you can capture as a project on your Projects list and track the sub-projects in your project support materials. For example, “R&D content management system” (a “look-into” project–you don’t know if you will create an in-house solution or leverage an existing cloud service), “Implement content management system” (once you’ve completed the R&D and chosen a direction) or “Finalize R12345” (an example of a project release number in my company) would go on a Projects list. Intermediate milestones or “stories” (if you’re using Agile) would be tracked in support materials (project plans, product backlogs, etc). Review these as often as needed to generate new next actions and prevent things from falling through the cracks.
Another tip that might help you is to view your next actions as bookmarks for your projects. They represent what you need to do to get moving on a project once again. You can choose a next action, do it, immediately define the next one, do it, and repeat that process all day long. But when you switch to something else capture a bookmark reminder for yourself and get it into the inbox. If you forget to set a bookmark for yourself, the weekly review is your safety net.
Its would be good idea to try to implement some type of Earn Value or Scrum Methods into your programing strategy. If you have an iPhone try using our App call TA Projects. This can modify your task completion, add task, and delete them can get your Project Performance in Real Time.
I’m having similar problems with implementation. As an academic scientist in biosciences, I am accustomed to breaking “projects” down into publishable units. However, one publication is easily several years in the making. Obviously, there are smaller projects within one publication: generate the data, write the paper, react to the reviews, etc. But within “generate the data” there are dozens more projects: clone a gene, localize a protein…. Within each of these, there are even more sub-projects, each with an obvious successful outcome: harvest RNA, prepare cDNA, amplify the gene, ligate it into a vector, transform the vector, blah, blah, science, blah. Even these steps aren’t yet actionable items; for example, order to even think about harvesting RNA, I have to grow the tissue. Starting the culture is an action item, but there are so many possible project levels above it that I become woozy just considering where my project begins an ends. I am unsure how to begin organizing projects, and I’m concerned that if I did know, I would spend more time organizing than actually doing.