I would recommend thinking of ABC Department as an "area of responsibility," with each report as a project within that area of responsibility.

The book uses an airplane metaphor:

Life purpose = 50,000 feet
3-5 year objectives = 40,000 feet
1-2 year objectives = 30,000
Areas of responsibility = 20,000 feet
Projects = 10,000 feet
Next actions = runway

I've found this a really helpful way to organize my work. That way you don't have big catch-all pseudo-projects -- e.g., health, finances. Instead you have "desired outcomes" (projects), such as "lose 10 pounds" and "rethink investments."

Projects = "any desired outcome that takes two or more steps to complete." I've found this one of the most helpful definitions in the book. I would recommend rephrasing your projects as "desired outcomes" (e.g., solve problem X on purple report). You might have several such desired outcomes for the purple report. Visualizing a desired outcome helps to clarify/organize the work that needs to be done.

Thanks mdl for your response.

I guess having a huge list of Projects/Desired Outcomes is quite a natural thing.

There are some really great PDF charts and diagrams on Davidco.com, and they might help you a bit. Granted it makes a lot of sense once you've read the book.

For me the crucial points are these: Get it out of your head -- write it down. Stick to the practice of "Do it, delegate it, defer it, drop/delete it." And do the Weekly Review weekly, or as often as you need to, to keep the big picture in mind.

And it's obvious by now that I haven't really stuck to the desired outcomes thing, so that's probably something I personally need to work on.

I'm late to this party, but here goes . . .

I take it that you work in or around the IT arena. As others have already pointed out, your top level projects are really outside the tactical scope of GTD. Projects that warrant project management tools do not equate to GTD projects. They are different animals.

Likewise, HelpDesk tickets are probably below your GTD threshold unless you are worried that a ticket will: a) take some planning to resolve, b) you are worried that you may somehow forget about a ticket, c) you need to coordinate with someone else to close the ticket, or d) you need to defer the ticket and your HelpDesk system doesn't provide a good way of dealing with this (I guess this last point is really just a special case of "b").

In my opinion, there is a definite boundary and tension between project management and GTD . . . especially if you are in IT. If this applies to you, then you may want to just accept the separation . . . at least for now; and not try to interface the two too tightly. It is seductive to think of marrying your project management software to your GTD tool(s), but this leads down the path of madness . . . or at least one enormous rat hole.

Use GTD for your non-full blown project stuff, and handle project management according to your organization's guidelines and tools. This is not just due to the tools. I think there is more to it than that. GTD is intensely personal; project management is intensely impersonal. The tools and mindsets are often very different. I've found that I can can handle context shifts between the two separate systems (think minimal interface here . . . as in cut & paste), and I'm betting that you will find your way as well.

Time accounting is an area where you may be able to leverage your GTD system. With the clever use of contexts (I am thinking of context tagging in particular), your GTD system can be the basis for your time accounting reports. I'm pinning my hopes on OmniFocus for this functionality. Until then, I'm recording competed NAs in a spreadsheet . . . more cutting & pasting.