[whpalmer4]

I wouldn't say you are using it incorrectly, but you might not be using it optimally.

From your description, it sounds like you've taken all of your workload and split it out into groups of similar tasks which may or may not be related to each other. If you got a new contract to do a movie or photo shoot, there would be new tasks added to a number of those categories you listed, whereas with a project-oriented setup, there would be a new project added to one of them. Which approach is most useful depends on your needs. Do you need to be able to easily pull up all of your administrative actions at once, and work only on them, or is it more likely that you need to pull up all of the actions relating to a particular photo shoot and work it to completion to meet a deadline? The structure you have is better suited to the former; the project-oriented setup is better for the latter.

Another way of thinking about this is to consider what you would need to do if you chose to drop a project (or put it on hold). That photo shoot is going to have administrative tasks (billing, collecting), post production (backing up the images, doing the processing, producing the final results), marketing (considering whether any images ought to go in your next set of marketing materials), etc. If your client cancels the shoot (or just postpones it), it's going to be much more convenient to simply mark the "Photo shoot for Bill Clinton, Oct. 2011" project dropped (or on hold, or with a future start date) than to go through all of your different containers looking for tasks that might have been related to the now defunct photo shoot — and if he flip-flops again, with the project setup you simply mark the project as active again, with no need to recreate all of the tasks you would have deleted.

The definition of a project used by most working in the GTD style is that a project is any desired result that requires more than one action step. I'll bet that quite a lot of the actions in your database are pieces that could reasonably be assembled into projects. But if your working style is more like that of an assembly line worker who happens to work at a number of different stations at different times (today I only do admin work, Saturday I only do home maintenance, Wednesday and Thursday I do post production) your current setup may make more sense. I would suggest in that case that you make them parallel projects rather than single action lists, and occasionally sort the actions into any desired priority order (the next action view will always present the uppermost available action).