Clarity on Projects, Contexts and Actions

C

cfoley

0
I’d like to share some thoughts I have had about the relationship between projects, contexts and next actions. A recent thread on here dismissing contexts as obsolete got me thinking. Sometimes I work really efficiently in a context but other times it is more helpful to stick to a single project for a while. I’ll illustrate my thoughts with two examples:

The first example project is to install a bookcase. A reasonable sequence of actions might go as follows:

Choose a location, size and colour with my partner
Drive to our favourite Swedish furniture warehouse and buy the bookcase
Assemble the bookcase
Realise that the notch to fit over the skirting board is not big enough
Phone a friend and ask for their jigsaw
Drive and collect the jigsaw
Modify the bookcase
Discuss precise placement with partner
Mount bookcase with brackets
Drive to return the jigsaw

The situation with the skirting board really did happen to me once. It wouldn’t be too difficult to do all that in a day but you wouldn’t get much else done either. All the changing contexts, driving around, waiting for my partner, maybe having a coffee with my friend when visiting takes a lot of time. These kinds of projects are best suited to working from a context. It might take a whole week to sort out that bookcase but I’ll get through a lot more stuff as well.

The other example project is writing a computer program. The vast majority of the time, the next actions are to implement a feature or fix a bug. Once that is done you move onto the next feature or bug. Yes, there are meetings, phone calls and planning but most of the time is spent writing and debugging code. In this situation, it seems better to work from the project, at least until a context change is required.

GTD recognises that you can’t always predict the sequence of actions in a project but for this mind experiment, let’s pretend that we can. Imagine a table where each row is a project and each column is a context. If we mark each next action with a star, it might look a bit like this:

Code: 
           @Partner   @Errands   @DIY   @Code   @Calls
	Bookcase   **         **         **             *
	Program                                 ******  *

If we organise our action lists by context, it might work really well for projects like the bookcase project but not so well for the computer program project. I have about two university programming projects, three freelance ones and at least half a dozen personal programming projects on hold. If I were to take my next actions and work through a @Code context then the mental effort of switching between codebases would be overwhelming.

I think a lot of projects lie between these extremes. Maybe a good guideline is to work from contexts by default but if a project has several next actions in the current context, either focus on that project or avoid it in order to do the unrelated next actions.

Thanks for reading. If you have any comments or suggestions for me then I would be glad to hear them.
 
Shoot and pray.

cfoley;107052 said:
The first example project is to install a bookcase. A reasonable sequence of actions might go as follows:

Choose a location, size and colour with my partner
Drive to our favourite Swedish furniture warehouse and buy the bookcase
Assemble the bookcase
Realise that the notch to fit over the skirting board is not big enough
Phone a friend and ask for their jigsaw
Drive and collect the jigsaw
Modify the bookcase
Discuss precise placement with partner
Mount bookcase with brackets
Drive to return the jigsaw
Click to expand...

What about this plan:
  • Drive to a Swedish furniture warehouse and buy a "good enough" bookcase.
  • Mount a bookcase in a "good enough" place.
  • Prepare a "good enough" elevator pitch concerning your great new bookcase.
  • Wait for a partner to arrive praying that the pitch will work :-D
 
Well, yes, except that my "Wild Success" was to demonstrate a fictional project that had a lot of context changes and an unexpected twist.
 
Revolving workflow strategies

I still have this list (in Evernote) I found several years ago on a blog called Murtworld. I don't consciously use the different strategies, but it was helpful to me in developing my intuition:

alternate projects
complete as many small items as possible
oldest first
newest first
squeaky wheel
goal driven

I don't think there's anything wrong with any of these strategies as plausible list traversal algorithms, as circumstances change.
 
cfoley;107052 said:
If I were to take my next actions and work through a @Code context then the mental effort of switching between codebases would be overwhelming.
....
Thanks for reading. If you have any comments or suggestions for me then I would be glad to hear them.
Click to expand...

The way I interpret that problem is that you haven't defined your contexts well enough. If it really is that big an effort to change which codebase you are working in then you need to have a context for @codebase1 @codebase2 etc.

What I find myself doing in debugging code (yes, I do some programming in addition to delivering lambs) is I set up a context for each major project. So for example right now I have a context for my LambTracker program. It's a subcontext of Android Development. In the LambTracker context I have several projects and next actions for them. One project is integrate yearly lambing history with the EID program. The current next action on it is design the SQL table to hold yearly lambing history for all ewes. Another project is Design the I/O Screens for the doSheepTask activity with a next action of Implement gravity for navigation buttons for both landscape vs portrait displays. Another project is Debugging LambTracker and the current next action is Figure out why loadDataBase works in the emulator but fails on the Nexus 7. They all have the context of LambTracker. So when I am in the development environment and working on LambTracker I can do all the tasks associated with it.

You need to adapt your contexts to be ones that work for you and there are many ways to do that.

I create, use, and then delete contexts as often as I need to.
 
Next actions organised by context only organise the START of your work. It is perfectly fine to keep working on the one project once you've done the next action, until you've had enough. That's assuming you don't need to change physical location to keep working. If all of the project work can be still done in the same office, then go for it, it's an efficient and productive way to work and still in line with GTD.
 
I don't remember where I got it from exactly, but what really brought this home for me was the bookmark metaphor one of the coaches brought up in a webinar (I think).

The next actions on your context lists are like a bookmark. But you don't just read one page, put the bookmark in, and then switch to the next bookmark in a different book. Instead, we continue to read and when it is called for, we put the bookmark back in where we left of (ie. put down the next action that has to follow after we stop working on a project).
 
You must log in or register to reply here.
Top