How big are your projects?

[jpm]

Thanks for the thoughts. Your responses have given me a lot to think about. I still think I'm confused.

I'll try to be a little more specific...

My team is responsible for providing hardware specs world wide to our customers. We will do about 800 of these next year. I've bounced between treating each one as a separate project (each one takes between 1-2 weeks elapsed time, and we have anywhere from 15-60 in our workqueue at any given time.) and treating them all as one single project. Neither works particularly well.

Treating them as individual projects seems like a lot of overhead (not for entering the project but for managing it), even though, I likely only have 1-2 next actions each, often just a waiting for as almost all of the work is delegated to my team, though sometimes I must coordinate with a sales manager or sales director if the account is high profile.

Lumping them as one big project "e.g. manage project queue" tends to leave me not focusing on the details and having a big long project that never really finishes. In addition, I tend to get follow-up calls to sales directors about individual accounts confused.

The other half of my team has longer term projects 3 mo to 1 year +; there are typically about 12 to 24 such on-going projects. Each has significant deliverables requiring anywhere from 1 month to 6 months worth of work. These projects are fairly complex requiring interactions with sales, marketing, r&d, and multiple hardware partners.

I've also worked this one as either multiple or a single project. Similar problems occur with these longer term projects when either lumping them all together or breaking them into individual (Deliverable) component parts.

These are two of the five objectives for which I'm responsible. For these two objectives, I'll have anywhere from ~25-80+ active projects at any given time (if managed as individual projects); or simply two projects (if lumped together).

I guess what I'm really asking is how would you treat each of these as individual projects or as one large (lumpy) project? or as something else entirely...

Thanks.

[Borisoff]

I would treat them as individual projects. Anyway you have to track each of them individually. And they're delegated to different persons. So there will be different Waiting Fors and Next Actions for each.

[Cpu_Modern]

Here's what I guess I would do:

1. "manage hardware specs project queue" is an area of responsibility (20,000 feet item)
2. maintain checklists to manage this queue (e g a table "client | status | responsible team-member | link to specific materials") as much as the team and me needs it. Maybe these checklist would be even "public", that means not even part of my personal GTD-system. Like the menu form the nearby restaurant on the bulletin board.
3. Review these list as often as necessary. Maybe a tickler/ recurring task, or a scheduled meeting with the involved persons.
4. Additional work concerning the whole thing, like for example "develop long-term strategies to optimize hardware specs creating process" would than become gtd-projects.

Ok, this is the first thing. The other projects your team has to do, I would not have them as projects in my GTD-System. Only the work you have to do belongs IMHO into your personal GTD-System. The company objectives and your gtd-projects do offcourse overlap, but they are seen from a different angle.

I suggest you re-read the pages in the book where DA explains what he sees as the 20,000-feet level and how to come up with a list. Me guesses again this will clear up some things.

[Brent]

Agreed with others.

Each hardware spec delivery is a Project for you. Each "longer-term project" for the other half of your team is a Project for that other half of your team.

A Project is something that you have to do.

I don't see 25-80 Projects as a lot of overhead. It's just adding things to and dropping them off of a list.