Projects - Prioritizing Feature Requests
Becky,
I'm a systems architect, and I'm using GTD. Although GTD's treatment of project has an elegant simplicity and is very useful for a large number of day to day projects, it doesn't scale up well when planning and executing complex projects. So here is my two cents worth.
If your projects are running in excess of 100 hours or you are planning the work of a team, you should probably use project management software anyway. Project management software allows you to easily build a hierarchical work breakdown structure plus it enables you to determine the parallelism in the project work. (More on that later.) However, unless you plan your projects down to the granularity of a next action, it will only get you so far. Most people don't, by the way, because in many cases, it's just impossible to do. You really don't have a clear idea about how to do some things until just before (or even some time after) you have started doing them.
A project plan is essentially a project tree. It starts with an overall project like "Build a Global Sales Data Warehouse for ABC Company." The top-level project is then detailed out in successive levels of sub-projects. For any project in the tree (X), its sub-projects answer the question "How do I do X?" Its parent project answers the question "Why am I doing X?" So in our example, if I ask "How do I build the warehouse?" the answer is "I gather requirements, design, build, etc. etc." If I ask "Why am I gathering requirements?" the answer is "Because I am building a global sales data warehouse for ABC Company."
It is this recursive decomposition of projects into sub-projects that the GTD theory doesn't handle too well.
Another wrinkle is that projects can be decomposed not only into subprojects that must be performed sequentially, but also into sub-projects that can be performed in parallel. It's the parallelism in projects (even simple ones) that means that a large project can have several next actions. I've read posts that say that a project can have only one next action, but I think that's a mis-reading of GTD. A next action is the next physical thing that you can do to move a project forward. A project can have as many next actions as there are parallel tracks in its plan.
So what do you do?
Plan your project using either project management software or an editor that can easily make outlines. Plan it down to the level that you can really plan, and you're not just whistling in the dark.
If you have project management software, also put in the task dependencies so you can easily see the parallelism in a PERT chart. If you are using some kind of outliner, use a mark-up scheme to show you the parallelism. For example, you can bullet parallel items and number sequential items.
Keep track of the active sub-projects on the plan, i.e., the ones that are currently being worked on - or could be. You can do this by putting them on your project list, or by highlighting them somehow on the project plan.
Work each active sub-project just like a small, individual project. Appointments go on the calendar. Time-delayed items go in the tickler file. Next actions go on the appropriate action lists.
When you finish an active sub-project, mark it as done and then return to the project plan and see what sub-projects on the plan can be activated. Activate them and keep on trucking.
What this approach does is to only present the active sections of your project plan for action. The rest of the sub-projects remain hidden. Your project plan acts in a sense like a Someday/Maybe list for the project.
Also, if a sub-project "explodes" into something more involved, you can always extend your project plan by decomposing the sub-project into a number of sub-sub-projects and process each of those as outlined above.
Hope this helps.
Scott
