How (often) do you update your actions throughout the day?

[miltos]

The one thing that is really tripping me up in implementing GTD is the daily "maintenance" that my next actions seem to require.

I am a project manager in a technical environment. One thing I do is oversee the handling of specific support cases that are submitted by my users and worked on by an external vendor. I tend to have one action for each of the open cases that we have, and I just try and update the Notes for that action as it gets worked on so that it contains the latest information and becomes the "place of record."

My frustration is that each of these cases can have up to 20 emails a day on it, with the back and forth of troubleshooting and trying to figure things out. Each case can last anywhere from 2 days to several months.

I'm wondering what strategies and approaches people use for updating your next actions so that they contain current information about the status of the action and what truly needs to be done.

Am I approaching it wrong? As a project manger it makes sense for me to have one action that contains the whole history of the case, with a note about what the true next action is at the top of the notes. But does GTD really recommend that I create a new action anytime there is a "next step" with a given case - and delete the previous action(s)? So, then, each case would actually be a project (in which case then I'll just need to get my head around having A LOT of projects).

I would love any thoughts and suggestions you have. Thanks!

 

[Toby Jarvis]

Consulting the text book...

The text-book definitions here are:

Project - Any desired result that requires more than one action step...if one step won't complete something, some kind of stake needs to be placed in the ground to remind you that there's still something left to do.

Next action - the next physical, visible activity that needs to be engaged in, in order to move the current reality toward completion.

So in your scenario I would probably approach it by calling each support case a project (e.g. install x for Joe Bloggs) and defining each of the next actions within that project (e.g. call vendor etc.). A separate project-plan document (a simple hierarchical list of the key components) will serve as your notes for the case, and any supporting material (email history etc.) gets stored in a project folder (paper based and/or electronic).

It sounds to me like you're approaching it right, but need to think of the support case as a project and the next actions as the actual physical steps that are required. The important thing is that a next action can only be one of two things: done or not done. Create and tick off next actions within a project as appropriate, using the project as your flag in the ground and your project plan as your prompter for what to do next.

 

[dschaffner]

But does GTD really recommend that I create a new action anytime there is a "next step" with a given case - and delete the previous action(s)

GTD is nothing if not flexible. The bottom line is that you need to do what works for you.

I'd say "create a new action anytime there is something that has your attention", rather than micromanaging a whole lot of next actions that become out of date within the hour.

It sounds like you just need to check in several times a day and make sure that progress is being made by the external vendor. You might only need true next actions on those items that are off track or somehow need your personal attention.

Does that help?

- Don

 

[abhay]

I think you are mixing actions with project support. The emails are a part of project support, and so are your notes as you complete actions, if you want a record. On the actions list, it helps just to have the next physical action, that too only when the ball is in your court. When you finish the action, you can happily remove it from the actions list, possibly after recording your notes, and perhaps adding an item in the 'waiting-for' list.

Regards,
Abhay

 

[humblepie]

The one thing that is really tripping me up in implementing GTD is the daily "maintenance" that my next actions seem to require.

I am a project manager in a technical environment. One thing I do is oversee the handling of specific support cases that are submitted by my users and worked on by an external vendor. I tend to have one action for each of the open cases that we have, and I just try and update the Notes for that action as it gets worked on so that it contains the latest information and becomes the "place of record."

My frustration is that each of these cases can have up to 20 emails a day on it, with the back and forth of troubleshooting and trying to figure things out. Each case can last anywhere from 2 days to several months.

I'm wondering what strategies and approaches people use for updating your next actions so that they contain current information about the status of the action and what truly needs to be done.

Am I approaching it wrong? As a project manger it makes sense for me to have one action that contains the whole history of the case, with a note about what the true next action is at the top of the notes. But does GTD really recommend that I create a new action anytime there is a "next step" with a given case - and delete the previous action(s)? So, then, each case would actually be a project (in which case then I'll just need to get my head around having A LOT of projects).

I would love any thoughts and suggestions you have. Thanks!

Hi there, being in the support line i can empatize with your predicament so let me try to help here.

I thing you are trying to draw GTD together with a known incident handling workflow that was establish with a third party vendor.In that case i would expect there is a flow chart or the course of engagement with them such as a third party contract agreement. The workflow chart either is created by you or them.

In a sense each incident encountered is a sub project. You need to away of each milestones leading up to proper closure of the incident.

You will have actions such as this

- forward problem to vendor to analyze problem/incident @contact or @email
- wait for vendor to get back on problem or incident @wait

vendor gets back to you and you need to apply the fix to try if the workaround works

- get the guys to apply the workaround @John or @someone

it doesn't work so you wanna invoke the third party vendors to come down so

-email the vendor to get them to come down @email or @contact

the problem with that is that you will track at least 20 cases like this spanning different duration.

what i would do in your shoes ( or like what i am doing now) is to track only the milestones with a microsoft project plan and work with that. Keep it seperate from your main GTD system.

Most of these things i presume are done @Office so i would rather have something like review MS Project plan to find out what i should do next in my main GTD system and then if i am at that context i will go through the company's system or the MS Project Plan to identify what is my next action in that context.

what i feel is that if you are going to get your cases recorded in various context list it becomes a waste of time. do note that if something that can be done in 2mins do it. This will eliminate many of the next actions that is suppose to be inputed into your GTD system unless you have to wait for something to happen before you can call up this guy/lady.

Your MS Project plan or incident resolution workflow should tell you your next milestone. if its an actionable tasks outside @office context then record it down in your main GTD system. other wise review your plans everyday and track your next actions from there.

 

[humblepie]

The text-book definitions here are:

Project - Any desired result that requires more than one action step...if one step won't complete something, some kind of stake needs to be placed in the ground to remind you that there's still something left to do.

Next action - the next physical, visible activity that needs to be engaged in, in order to move the current reality toward completion.

So in your scenario I would probably approach it by calling each support case a project (e.g. install x for Joe Bloggs) and defining each of the next actions within that project (e.g. call vendor etc.). A separate project-plan document (a simple hierarchical list of the key components) will serve as your notes for the case, and any supporting material (email history etc.) gets stored in a project folder (paper based and/or electronic).

It sounds to me like you're approaching it right, but need to think of the support case as a project and the next actions as the actual physical steps that are required. The important thing is that a next action can only be one of two things: done or not done. Create and tick off next actions within a project as appropriate, using the project as your flag in the ground and your project plan as your prompter for what to do next.

the problem at his work environment is that his "projects" will really start pilling up. by documenting them in your workflow and then tracking it from your company's system seperately is just too much work.

if your company have an establish incident tracking system then i think make use of it would suffice. honestly, i wish my incident workflow system can be tagged with contexts haha! that would make life much easier for me.

 

[Oogiem]

I'd try a single on-going project with a single next action and associated notes that are all the intermediate steps filed or attached somehow. And I'd tend to try to keep that as reference for quite a while.

If it helps what I do is that for my more complex projects I document the actual next actions I took after the fact and check them off at logical breaks, after morning chores, inside for lunch, before evening chores, before bed.

I tend to keep what I did on specific projects around as templates for when those types of projects come back or I put notes and take lots of pictures for my scrapbooks that will help me for projects know will come back but a long time from now. I don't want to forget what I learned this time around. I am often amazed at how often I refer to stuff that got done a year or 2 ago. One reason I do such extensive scrapbooks and have them indexed is we are constantly looking at how we did X 1 or 2 years ago now that we are doing something similar.

 

[Brent]

I update my Next Actions as required.

Sometimes, I look at my NA list, and a few Actions are out-of-date, but I know that I need to work on a different Action. So I'll work on that Action. Otherwise, I'll update the list.

As others have suggested, it sounds like you have too many Actions.

One thing to remember: the NA list can be seen as a dashboard of work to be done. As you scan the list of NAs, some will "flash red" in your mind to indicate work that needs to be done now, or that you're in a particularly good mood for, or that otherwise are particularly appropriate for that moment.

If you have a small percentage of out-of-date Actions, that's okay. Your mind will still interpolate the actual Next Action (if vaguely), and if it needs to be done, it'll still flash red.

 

[Roger]

I have a similar sort of situation with support cases at my workplace.

After fiddling with things a bit I fell into a little hack of pure GTD that I think of as "Fat NAs". Because that's the way they look in the folder.

So I get my first notification of a support case. Great. Print that out, look for the Next Action, and shove it into the Action folder (or quite possibly the Waiting For folder.)

An update comes in. Print that off, staple it to the front of the sheet(s) I already have, and go through the process again.

Sometimes these grow into full-blown Projects, but most of the time they stay under two dozen sheets of paper or so, and live just fine as Fat NAs.

Eventually the situation gets resolved. Then it gets a "Decide what to do with this" Next Action in which I need to figure out whether I should file this away for future reference or just toss the whole thing.

It gets occasionally a little grungy around the corners but for the most part I've found this to work out pretty well for me.

Cheers,
Roger

 

[Toby Jarvis]

the problem at his work environment is that his "projects" will really start pilling up. by documenting them in your workflow and then tracking it from your company's system seperately is just too much work.

That sounds fair enough; duplication of effort isn't a good idea. Barring unnecessary tasks, however, I would say that the amount of things you have to get done (aka. the things you've committed to) is an absolute at any one moment, i.e. what's on your plate is what's on your plate.

How you categorise your work by areas of focus, projects, subprojects and next actions is open to interpretation, but the bottom line is that buried in there is a certain list of true next actions that you have committed to. Trying to sugar-coat that list to make it seem less onerous is a lesson in futility in my view (although making it easier to scan and prioritise by categorising and appending contexts is still key).

So I say let the projects pile up if that's a true reflection of what's on your plate. Then hop in your GTD helicopter, travel through the 10,000-50,000 ft levels as necessary and ask yourself (and others as appropriate) "is this what I should be committing to?"

 

[Toby Jarvis]

Sustainable GTD

Sometimes these grow into full-blown Projects, but most of the time they stay under two dozen sheets of paper or so, and live just fine as Fat NAs.

Quite the carbon footprint here! ;-)

A whole new topic perhaps...

 

[kewms]

T
I am a project manager in a technical environment. One thing I do is oversee the handling of specific support cases that are submitted by my users and worked on by an external vendor. I tend to have one action for each of the open cases that we have, and I just try and update the Notes for that action as it gets worked on so that it contains the latest information and becomes the "place of record."

Why are you, the manager, doing an essentially clerical task? I would expect the vendor to do this kind of reporting through any of the various "trouble ticket" systems out there.

IMO, there's a management/delegation systems problem any time you find yourself tracking other people's actions in more detail than @Waiting For.

Katherine

 

[miltos]

IMO, there's a management/delegation systems problem any time you find yourself tracking other people's actions in more detail than @Waiting For.

Katherine

Yep, there is definitely a problem, but it's with the vendor. Their online tracking system is mostly useless and is not something I can use to track workflow or Next Actions. Not to mention, they do a crappy job so it does require a fair bit of micro-managing on my part in order to make sure things keep moving and get done.

I guess the good news is that we do have a new project on the books to select a new vendor ... but in the meantime I've got to play the cards I'm dealt.

 

[miltos]

Thanks for all the fantastic input. I'm going to try treating each case as a project and see how that goes. My project list will be huge, but as one poster pointed out, what's on my plate is what's on my plate.

 

[Conejo23]

I would definitely put those projects in their own folder so it doesn’t overwhelm your overall project list, or make them subprojects.

It’s too bad your incident tracking system isn’t a little more effective so that you could simply rely on that and create a repeating task to review and respond to the information there. If you get a new vendor, would that mean a new incident tracking system as well? Can you guys create one and impose the requirement on the vendor to work with that rather than their proprietary one?