I suppose that since you have accomplished your original goal that it is no longer a project and it seems it is something that you could just put "do website maintenance" on your calendar and forget about it being a project any longer.

But, if it works for you continue having it as project I don't see why it would matter. ;)

I think how you categorize it (project, or just NA's) depends on how you want to be able to look at it when you do your weekly reviews, and how you "do" GTD overall.

"Design Church Website" and "Design Client Website" were definitely projects. I sense that you feel like you can track the maintenance better if you close these out and do something different with your other related open loops. I think I would feel that way, too.

Some ideas: Make "Church Site Maint." a new project. It may not even need any next actions under it - but you'd catch it in your review & think about whether you needed to do an update or not. If you do, then you will create a next action.

This seems like it might be cleaner than continually carrying the baggage of "Church site" on you NA lists that you're looking at a lot.

This kind of thing is where a computer-based system can help, if you use one in addition to the HPDA. if the timing works, you can set up a recurring task to review the site & see if you need to do anything.

That all goes only if the maintenance and updates are actually driven by you. If someone at church feeds you the actions - "Hey, Berko, the picnic is coming up in a month, can you put it on the website?" then you may not need to do any "tracking"- you get the action assigned when someone needs your help, and you add it to a list.

If that's how it works, I would say it's easiest to just add those specific actions to your NA list (whichever context it fits) and not worry about tying them to a project.

How you handle the client sites might be the same, or not. For a client, it's a real plus if you can anticipate their needs, and it could result in some additional cash business for you. So maybe doing something that will prompt you to think about their site on regular basis is a good thing. Also, if you have a boss (not sure if you're a freelancer or not), it's good to have some documentation of all the sites you're tasked with maintaining, whether you have any current work pending or not. Emory's got some good thoughts on this in his whitepaper.

Hopefully there's something useful in my long, rambling post!

Thanks, Paul and Daniel. Those are helpful comments. I guess I sort of always thought of doing GTD with only Projects and NA's, but this makes me see there is another kind of thing that I'm not sure what to call. I would call it something like "Routine" but that doesn't quite get at it either. Thanks for the suggestion to put these kinds of tasks on my computer. It seems like it will need to be done via all-day events in iCal, since iCal doesn't do recurring tasks yet.

Actually, it seems like the Covey system can fill a gap here. It seems what we are talking about are spheres of responsibility. I realized today that that is the best way for me to do my weekly review. (Today was my first complete weekly review since I started doing GTD quite a while ago. It feels nice.) I really only have four spheres of responsibility within which everything else falls: web design, school, work, and home. Of course, I have different contexts that span these, but thinking about those different spheres of my life makes thinking about all my open loops so much easier!

In regards to the Weekly Review, I use the standard "Incompletion Triggers" list from the book. One of the triggers is "Personal (or professional) projects started, not completed." Also "Responsibilities toward ... (family/spouse/professionals/friends/etc.)"

My Incompletion Trigger list will be modified in time, as has been my Weekly Review checklist. (I've added reminders for things like checking my oil, etc.) But yeah, do that Weekly Review. Whenever I've missed it I've found myself thinking, "Okay, I need to be doing something, but what?!"

In GTD, David Allen talks about higher levels of planning, using a flight metaphor.

50,000 feet - life purpose
40,000 feet - 3-5 yr goals
30,000 feet - 1-3 yr goals
20,000 feet - current areas of responsibility
10,000 feet - projects
runway - next actions

For me, it would help to think of something like "Church web site" as an area of responsibility (20,000 feet). Then any specific desired outcome that might arise in relation to that responsibility would become a project (10,000 feet). Thus, having "Church web site" written down at 20,000 feet in your master "life plan" document would remind you of the responsibility during weekly review and perhaps prompt you to think of anything specific that needs to be done. But there's no need to keep "Church web site" as a project if there's no immediate next action.

I think a ticker file can also help to remind you of this responsibility.

Heh, Merlin's latest post links to a copy of the Trigger List.

(I guess I need to poke around the wiki more.)

Thanks for all the replies, folks. So, when I have completed the "Church web site" project, is it reasonable to assume that when they do come to me with things that need to go on the site (which will be more and more rare in the near future. YAY!) that that action (if it is indeed an action and not a project in action's clothing) can go straight onto my @Web Design card?

Look, how you do GTD ulitmately is your own choice. It's your life after all. But strict, pure GTD means putting "Church Website" on your Areas Of Focus list. Or Areas Of Responsibility like some do call them. Then, when some things occur that make you feel the necessity to do something, put these actions and projects on the apropriate lists. It is easy to distinguish projects and areas of focus by asking the question: "What is the next action?" If it's nothing but you still feel responsible chances are ist is one of your 20,000 ft areas. Or none of your business. Be rigorous with yourself. Otherwise you just keep filling lists. Hope this helps.

Almost my entire work life falls into this way of working, since I rarely get to hand something over when I finish the initial implementation. There is usually something that can be defined as the deliverable of the project: when that's handed in, the project's done as far as I'm concerned.

Any follow up is either a single next action (sometimes) or a new project (in GTD terms) in it's own right.

Works for me, YMMV.