Action placeholders & sub-lists

[RobertWall]

I'm a web dev implementing GTD in Omnifocus.

I have some customers that have very neat lines around their work. A single website, a single project, with a defined "complete" state.

I have at least one customer, however, where the lines are very muddy around the whole project. I mean, technically the project is "build CRM system", but every time we finish one section of it another pops up. And sometimes there are, literally, dozens of individual tasks related to this project.

So categorizing those as @Computer results in a *HUGE* list of tasks, and it drowns out the other stuff that might actually be more important at any given time. Although it's important to know that they *ARE* all @Computer actions. Almost nothing for this customer would ever be on any other list.

Each of these items *are* atomic next actions (and not short next-actions - usually they're 30-120 minutes each), so they need to be tracked as such *somewhere*. And marking them off when done gives me some measure of satisfaction.

So I'm thinking one of two things....

(1) Use different tracking software for the projects, and use GTD to just hold placeholders reminding me that the entire *project* is @Computer. This adds additional complexity that I'm not a fan of, but I'd be interested if anybody has a positive experience and/or recommendations for going this route.
(2) Keep all the tasks/actions in GTD, and just have a @Computer item that links to the internal OmniFocus project list.

Thoughts?

 

[Cpu_Modern]

Read more on the natural planning model.

I quote from page 59 of the original edition of GTD:

Have you identified the mission-critical components, key milestones, and deliverables?

You are probably confusing deliverables and next actions?

On page 75 then:

The Basics of Organizing

The key steps here are:

• Identify the significant pieces.
• Sort by (one or more):

• components
• sequences
• priorities​

• Detail to the required degree.

Components would then be those deliverables again.

Your true next actions with that particular client would be stuff like "talk to special needs client about decision for next component to tackle" or something.

On page 79 he cautions:

If brainstorming gets hung up (and very often it does for more "blue sky" types), rigor may be required to do some evaluation of and decision-making about mission-critical deliverables that have to be handled {organizing). This is sometimes the case when an informal back-and-forth meeting that has generated lots of ideas ends without producing any decision about what actually needs to happen next on the project.

This is just my opininion, take it for what it's worth, but clients like your specialist need more education about what is really important. There has to be clarity established at the clients side about what that CRM is supposed to deliver and why.

Yes you can milk such a client, but only for so long until he discontinues your working agreement for usually irrational, ahem, reasons. IMHO it is better to educate such types, even if this is more work, but as a consequence of that effort make them stick with you.


Now, the very long @computer list is an old problem in the GTD universe. It can be mitigated by scheduling and ticklering a bit more, but that only goes so far. I think it comes down to having to scan a long list repeatedly, an action that is experienced as unnecessarry mentally taxing.

In reality scanning those items again and again serves as an update to your intuition. You become more aware what it is that you commited to doing. That helps with your next Weekly Review.

Of course only if you do a Weekly Review.

What I found helped me is to put the newly created tasks at the top of the list. That way the "hot" items remain at the top and I usually do not have to scan for long until I find somethig pressing and worthwhile.

Then, from time to time, I scan the whole list, going "fishing" for some thing at the bottom of the list, to accelerate that one.

 

[RobertWall]

Well, they're *all* things I'm able to work on, typically at my discretion. Most of the time they don't have different priorities. When something *does* have a higher priority then it's noted as such. Although I think I see what you're saying re: deliverables vs. next actions.

To clarify, this isn't a project that just keeps getting revised and never getting launched. It's a launched product that we keep extending in different ways, and having all the items on the "wish list" together is actually a benefit for system design, as sometimes they intersect and I can ID the things that are *logically* most important (i.e. "component x and component y both are going to rely on a back end system that does z - I should build z first").

It's a working relationship that's been ongoing over the last....hmmmm....12 years? The process actually works, other than the super-cluttered Next Action list.

Maybe what I need to do, ultimately, is just have most of the notes/tasks for this client in their own huge project category, and only surface the half-dozen items that are the logical next actions. Then I can review the entire project during Weekly Review and make sure none of the components are getting lost without next actions.

 

[mcogilvie]

You should only see next actions in your actionable tag lists, BUT not all possible independent next actions need to appear.

 

[Gardener]

To clarify, this isn't a project that just keeps getting revised and never getting launched. It's a launched product that we keep extending in different ways

Even though my job is as a programmer, this more closely reminds me of task planning for my vegetable garden, aka "the farm". (A 70 foot by 70 foot vegetable garden, divided into 12 wide rows, each of them divided into ten beds.)

There are countless tasks that I could do for the farm, and a huge number of them are not terribly dependent on others. That is, "plant bed 10F" is of course dependent on "prep bed 10F for planting", but beds 10E and 10G are not in any way interrelated with 10F.

I don't put all these tasks into my everyday project/task lists--I didn't when I was using OmniFocus and I don't now that I'm using paper. My tolerance for list clutter is just too low for that.

In my case, I'm in charge of this project, so I can have a list of large distant goals, and I can break them up into smaller goals as I get closer to doing them, and then I can break them into actual projects and tasks as I get within a week/month of actually working them. I can do this because I'm my own customer, so I don't have to remember how some customer wanted it done.

In your case, it sounds like the tasks are specified by a customer, but even so, if I were in your position I'd keep them in a list outside your main GTD project/action lists, and then, every week or month, scoop up half a bushel of them to put in your main GTD project/action lists.

Returning to my garden, just to give a sample sequence:

- Long-term goal: Reduce maintenance effort for the farm.
- Slightly less long-term goal toward that goal: Add more perennials.
- One step closer: Ornamental perennials would be nice, preferably those that are technically edible.
- An actual project: Fill all of row 12 with rosa rugosa alba. Only now is there any chance of entering thingds into my regular GTD lists. However, I'm likely to have a couple of dozen projects like this, and most of them will be in Someday/Maybe.

But finally! This one became current, and qualified for actions:
- Clear, dig, amend, at least one bed of row 12.
- REPEAT the above until done.
- Install drip irrigation for future roses in row 12.
- Order 10 rosa rugosa alba plants for spring.
- WAITING FOR spring and rose order.
- Tarp the first three beds of row 12 against the rain.
- WAITING FOR sufficiently dry soil under the tarp.
- Plant three rugosa rose plants.
- REPEAT the above three until done.

 

[Cpu_Modern]

To clarify, this isn't a project that just keeps getting revised and never getting launched. It's a launched product that we keep extending in different ways…

Then it is not a GTD-project, although it may be referred to as a project. It is a Area of Focus. If the business as a whole was "a person" and had a "personal" GTD system, then this CRM might be a project in that system, if I make sense.

and having all the items on the "wish list" together is actually a benefit for system design, as sometimes they intersect and I can ID the things that are *logically* most important (i.e. "component x and component y both are going to rely on a back end system that does z - I should build z first").

Using your @computer list as a project plan for that Area of Focus is certainly "legal" and probably viable. It could be though, that you fare better with a proper project plan and a few NAs such as "choose next component to implement" or some such.

Implementing a feature in the CRM is more work than just one NA, isn't it? Even if you write only two lines of code, you probably have to study some algorythms first, read around in the existing codebase, write the code, test it and finally deploy.