Is this actionable?

  • Thread starter Thread starter jayx773
  • Start date Start date
J

jayx773

Guest
I have a situation that commonly pops up at work, and I am not sure the best way to handle it.

When I have something pop into my inbox, I decide whether it is actionable or not.

But sometimes it's not so obvious, and it may be because I am not entire clear on what 'actionable' really means.

My understanding is if you process an item that you can do something about, then it's actionable. If you come across an item that you need to do next tuesday, it's actionable. But what about something that you need to do, but can't until a near future condition is met?

Here is an example:

I receive a form via email with new user information. To me, this means set up the new user with an account and then email that user their login information. The setting up the account part is easy, as it is immediately actionable. However, what do I do about sending the email? Is that considered actionable even though I can't send email for a few days (3-5) until someone else sets up their email account?

Is the 'send person login info' action actionable? What I've been doing is putting 'email acct set up for x person' on my @waiting for list. and just checking every day or so to see if it is set up.

I can definitely make it work so it gets done. I am just really curious as to how it flows on the flow chart.

What's the difference between an item that you can't do now but you have to do next tuesday, and an item that you have to do but can't until another condition is met. I somehow feel that this is a different situation that receiving a travel brochure in the mail and deciding i may do something about later, in which case it goes on my someday/maybe list.

So I guess it boils down to: is it 'actionable' if I have to do something about it but can't right now?
 
You're handling this exactly the way I would... Record the project "Set up account for Joe User", next action is "Wait for email to be set up".

The project is active in the sense that you have more work to do; it's just that you've (in a sense) delegated the next action.

The only difference between an action that can't be done until Tuesday versus an action that can't be done until someone else does something is the location of the "waiting for". In the case of a calendar item, you could just as easily record "Wait for Tuesday to come" in your @Waiting list. But we usually use a calendar or a tickler just because the time when the "waiting for" to be completed is fairly well defined.
 
Thanks for the reply!

Makes sense to me.

I've actually started to shy away from listing such things under the project list because I already have a marker for it under the @waiting list and the thing I receive will prompt me to perform the final action.

Do you think that makes sense?
 
If you can't do it immediately, then it is *not* a Next Action and does *not* go on your NA list.

Still, if it does require you to do something, then it is clearly actionable (as opposed to trash or reference). And your example requires action in the near term, so it isn't someday/maybe, either.

So, moving down the flow chart, what is the next action? In your example, it is "create new user account." That really is a true NA, and goes on the appropriate NA list.

Once the user is set up, are you done? No. So there's more than one step, which makes it a project, the outcome of which is something like "user notified that account has been set up." If you want, you can put that on your project list and move on, since you have a clearly defined project with at least one NA. Once you've done the first NA, you can revisit it and see what's next.

(On preview: you probably do want to add this to your project list in some form. I would probably keep a list of pending users, as discussed below. Either way, the project list is the last defense against things falling through the cracks. If creating projects is too hard, you need better tools.)

In this particular case, though, you already know what's next: email the user. Except *that* is not actionable: you haven't created the account yet, and even if you had, you have to wait for someone else. Emailing the user is a future non-doable action that is part of a project, so the reminder belongs in your project support materials.

(I'm assuming that creating the new account is not a two minute task, and therefore should be deferred until you are done with your Inbox.) Once you have created the account, the Next Action becomes something like "Ask Joe to set up email for New User." That's probably a two minute task, so you do it immediately and create a Waiting For or Tickler item to followup and make sure it has been done. A key point here is that you *do not* create the Waiting For item until it truly is the Next Action for the project. Don't clutter your lists with stuff you can't actually do.

Now, I'm guessing that adding new users is something you do pretty regularly. If that's true, it might make sense to create a checklist of the steps involved, and to create a file for pending new users. Then, you might set aside time to process new users at regular intervals, with the checklist serving as a reminder of exactly what needs to be done next for each user. In that case, new user processing might become a calendar item or a recurring tickler item, with the individual users barely appearing in your NA list at all. And, if you have lots of new users, you might even want to write software to automate most of the process, with human intervention required only in exceptional cases.

Anyway, I hope going into this much detail is helpful. Good luck!

Katherine
 
Katherine - Great response thanks!!

I think I've made my example too complicated, because actually, everything is a 2 minute action. So essentially it comes down to when the email comes in, the only thing I have left is to notify the user with the login info when their email address is created.

So are you saying that when I receive this, I just create an item on my @waiting for list? Because that truly is the very next action when it comes right down to it. Receive email, wait for email to be set up. I also will not be emailing anyone to set up the account. They are notified seperately to do so and I am checking regularly to see if it has been done. So I will not receive any sort of alert or email letting me know that it has been completed.

Does that change the scenario at all?

I'm a little confused. If it really is not actionable, then how does it end up on my @waiting list? Doesn't that mean that this is actually actionable, and that the next action is that I am actively waiting for the email to be set up?

So it would be: email comes in > is this actionable? > yes > i have to set up email user > what is the next action? > wait for email to be set up

Does that make sense or am I way off in how this whole thing is supposed to work?
 
If the very next action is to wait for email to be set up, then yes, you would just add that to your Waiting For list. (I actually use my tickler for most waiting items, but it's up to you.) And yes, waiting is an action in this context.

Now, if your involvement is so minimal, I'm wondering why you need to do anything at all. Perhaps the person who actually sets up the email address should the user directly? Delegating is a great way to get things off your lists. But that's a different issue.

Hope this helps,

Katherine
 
Yes that helps a lot! Thanks!

You've actually brought up another point of confusion for me. I asked on another post but I didn't really didn't get the answer I was looking for. I think my question was too vague.

In situations like these, is it necessary to add a project to the project list?

Because as soon as I receive the email info, that will trigger the next action to send to the new user (i can either do it then or put it on the NA). I have a place marker for the commitment in the @waiting for list. Also, all of these actions are automatic for me, I do them often.

I feel as though projects aren't necessary when the results of the NA produce an item that is actionable and naturally moves everything along until the implicit commitment is satisfied.

When I receive the email info, I know automatically that this means that i need to send the new user their info and that will close out my commitment. I understand that for others, this may require a project if it is not something they are used to doing or are afraid that it might slip through the cracks.

I was just thinking about how it must be interesting that one persons NA could be another persons project depending on their capabilities.
 
Simple projects

This is the single exception I have to creating projects where more than one task exists. In this case I just make an entry in @Waiting For called something like "WF X in order to do Y".
 
You must log in or register to reply here.
Top