How big are your projects?

[jpm]

I'm curious about how others have dealt with the question of what constitutes a project. One of the challenges I've found is determining what the reasonable size of a project should be. Has anyone found any best practices?

The literal definition of a project in GTD is such that you can end up with a lot of little projects that become difficult to manage. At the other end of the spectrum I've experimented with trying to keep only major outcomes as projects (such as end of year objectives).

While I find the short list of large projects less overwhelming, it is also a long time between project completions. In addition, I sometimes wonder if with larger projects there aren't key next actions that fall through the cracks.

I'd appreciate any input on what the scope of a typical GTD project should be.

Thanks.

 

[johnmcoulter]

Projects Are Just Projects

Anything you have one or more next actions to perform before a successful outcome is attained is a project. Some of them only have one more next action, some have 3-5, some may have 50 or more. Your next action list just needs (at any given point) to contain the next action descriptive of physical, visible behavior to move it forward toward the successful outcome.

For complex projects that may eventually require 75 more actions before successful completion, there is no need to assume that all relevant actions will appear on your next action list--it's merely a placeholder to know where you've left off when you get to any given weekly review. It may well be that only 6 of 75 ever appear on your next actions list.

You don't have "GTD Projects," you just have projects. And all you can ever do at a given point in time on any of them is a single action that moves you toward your desired outcome.

 

[Todd V]

re: Handling Big Projects

I've thought a lot about this. Essentially it has to do with "What to do about sub-projects?"

This Quicktime movie explains how I've tried to deal with them and should give some helpful principles/advice you might be able to apply to your own approach to big projects.

 

[kewms]

I have projects that only have two or three actions, and projects that represent up to a year of work. Write them all down. If the overhead of creating a project is too high, your system is too complicated.

I haven't found subprojects helpful. The project support materials for large projects do break them down in a fair amount of detail, but they still get done one Next Action at a time.

Katherine

 

[TesTeq]

Projects and subprojects.

Projects - specific outcomes that require more than one Next Action to be achieved. All my GTD Projects are personal projects that I am responsible for.
Areas of Focus - higher level outcomes that require one or more Projects to be achieved. Areas of Focus do not need to be personal.
So instead of projects and subprojects I use Areas of Focus (superprojects) and Projects.
My life is not very complicated so I do not need hierarchical project structures for my personal projects.

 

[Apop]

Hi jpm - I've been thinking about this too recently.

I'm a building design engineer so all my work projects are big by the standards so far in this thread - typically a big building will take 3 years to design and another 2 to build, so I end up with lots of 5 year projects. To contrast that, a lot of my personal projects are small - ie Paint the Front Door.

The trouble is, my big projects are too amorphous for me to be able to relate the outcome (design a high quality building) to the current action (call architect about glazing). I seem to be slipping into this habit to in my personal projects, so I have projects called 'Friends' and 'Family' - which is fine but there is no real outcome for me to focus on and be motivated by.

The key here seems to be that a project must have a successful outcome, but even when it does, on long term projects that can be so far off that it doesn't really motivate.

What do others think?

Apop

 

[Brent]

I've recently pared down and redefined my active Projects. They're now things that I should be able to accomplish in the next week.

Sometimes they're part of larger Projects. That's fine. An example: I have a Project to watch a large stack of anime DVDs. Instead of creating a Project to "Watch all anime DVDs," my Project is "Watch 2 anime DVDs." I'll just put the same Project on my list next week.

"Larger" Projects are either intrinsic to the smaller Project -- as in the example above -- or are kept in my Someday/Maybe list. Or in the 3-year dreams posted on my walls...

 

[TesTeq]

Work projects, personal GTD projects and Areas of Focus.

I'm a building design engineer so all my work projects are big by the standards so far in this thread - typically a big building will take 3 years to design and another 2 to build, so I end up with lots of 5 year projects. To contrast that, a lot of my personal projects are small - ie Paint the Front Door.

My work projects are not my personal GTD Projects. They are my Areas of Focus. Within a given work project (Area of Focus) I define my own personal GTD Projects with clear outcomes.

 

[dschaffner]

I'm curious about how others have dealt with the question of what constitutes a project. One of the challenges I've found is determining what the reasonable size of a project should be. Has anyone found any best practices?

It's not exactly GTD standard methodology, but the software I use to manage my tasks (lifebalance) works like an outliner, so that the big tasks, have smaller tasks, all the way down to next actions.

 

[matt]

How big are your projects?

My projects vary in size in the same way that other people have stated here. My work involves managing pharmaceutical trials which can last several years, other projects can last between several months or days. Good project management always means keeping next actions aligned with project goals (runway to 50,000 feet). Don't get to bogged down in how. I have everything from a 2000 line MSP (and growing) to a project in a list and a next action aligned to it... whatever works. I'm sure you could run a large project from an outlook task list but it might make others in my organization a problem.

In answer to a couple of points in the original post
large projects scheduled reviews in the plan look at the tasks and final goal check alignment and brainstorm new actions and quite often expand some placeholder actions into individual tasks
small projects Same thing but at weekly review time also a quick look if defining next actions in between

 

[jpm]

Project Size Best Practices

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.