[julienl]

Hi,

Personally I use a mix of a few types of contexts:
- locations
- people
- state of mind (focus / type of activity)
- "stages of progress"

I call it "workflow" but I like your idea for a name. I will focus on one specific type of workflow in my computer-related work as a "pseudo project manager". Basically I take care of handling new clients for the main product suite of the company I work for. I will meet them as early as during the sales/demo stage, and then gather their requirements for standard configuration as well as customization and new development, do the training, some support, some analysis, etc. I don't manage resources, I usually deal with a manager from the dev team for example and "assign" the work to him/her then they take care of who will work on what and coordinating things.

Those projects can have up to 100 or more "things to track / do" for a medium installation, but if I actually break them down to single "steps" / actions, it becomes much larger. For example: "interface to system X" could include steps such as:
- determine method of connection
- determine content
- determine format
- develop interface
- document interface
- test interface (internal)
- deploy in test
- test interface with system X team
- get client signoff
- deploy in prod
- setup schedule in production
- monitor automated process for the first few days
- handoff to support team

At first I created a project for each of those, but it didn't work out well. In particular it was harder for me to prioritize across too many projects. Then I used groups of actions, but in general they don't work like I would like at all and I find them confusing.

For now, my middle-of-the-road solution is to keep only one action, or maybe break it in a few actions for the "big parts", and then I change the context to "move it" to the next stage and use the notes or a temporary group of actions if it is useful. It is really "loose", I don't have too many strict rules but rather goes with whatever works for the specific case. Going back to the example, let's say I just keep one action "interface with system X", it would probably go through those contexts:

- analysis (possibly with notes or subtasks: format, method, error-handling, etc.; this is a "state of mind" context for me)

- handoff (so when I login to the bug/feature tracking software or when I am at the office and can explain complex details in person, I can get everything and just go through it)

- waiting for dev (this context is on hold because there's nothing for me to do)

At this stage, when I do my project review, I might decide to change a few "waiting for dev" to "follow up" if I think I need to get an update or push to have it done soon.

- review (when the feature is delivered to me)

- deploy (when ready for test)

- handoff (this time the handoff is to the client when I communicate with them)

- waiting for client

... and so on. Possibly I would have a separate task to work on the documentation because I would do that in parallel while development is done, etc. I hope it is clear and possibly can help you.

Thanks and enjoy your day!

Julien