A routine observation from facilitating workshops and coaching people on issues related to productivity and strategy execution is that the way people are formulating action items simply isn’t helping them. A well-written action item contains enough information to spur you into action rather than just serving as an anchor for you to then remember what needs to be done.
That’s fairly abstract, I know, so an example here will help. Take, for example, the person who wants to write a business plan. Often times, when I look at their action item for this, what shows up is something like “TPS Report.”
Now, imagine that they look at this list 3 weeks later. How likely is it that they’ll remember what they were supposed to do with the TPS Report? Was it to review it? To edit it? To start it? To get some help on it? To send it to Manager Rob?
Rather than doing whatever they were supposed to do, they’re now trying to figure out what they were supposed to do. All of this may sound obvious, but take a look at your action lists and see where these types of problems show up.
I use “action lists” rather than “ToDo lists” or “task lists” because sometimes we’re talking about tasks and other times we’re talking about projects and objectives that need to be completed. The same rules apply; an action is an action and you always complete the big things through discrete actions, anyway.
Here are some great ways to write better action items:
- Remember that the capture phase is different than the process phase.
- Write each action item as if you were writing it to someone else.
- Use verb-noun constructs at the beginning of the action item and all the way up.
- If it needs to be done by a certain time, include the “when” in the task.
- In team environments, always assign ownership to the action item.
- Be clear about relay items.
- Give context as a comment or note.
Regardless of whether you use a formalized productivity system like GTD or a more intuitive, home-grown way of getting stuff out of your head, there are two discrete phases of capture and process. “Capture” is where you get stuff out of your head, whereas “process” is where you actually analyze what you’ve gotten out of your head. This distinction is much like the distinction between drafting and editing; the main goal of the capture phase to get it out so you can see it, but the process phase is so that you can make sense of it.
The items below are all about what you do during the process phase after you’ve gotten your items captured. (I’ve been sitting on a framework around this for a few years – if you’d like to see more of it, let me know via the comments.)
Our action items are often shorthand codes for our current selves just meant to jog our memory. While this may work for things we might need to do today, what often happens is that a task we mean to do today gets booted into the future. Not to go metaphysical on you, but the person that reads the action item two months from now is a different person who may not remember what that shorthand code meant.
I’ve found that when people write the items as if they were writing them to someone else, they walk through writing them the right way, which means their lives are easier in the future when they get that action item, as well as in the now when they see the item and don’t have to do a bunch of guessing about what needs to be done.
A verb-noun construct tells you what needs to be done to what; it automatically spurs action, which is what we want. In our “TPS Report” example above, adding a simple verb like “Draft TPS Report” creates a useful verb-noun construct. You now don’t have to guess what needs to be done; you’re left with figuring out how to do it, which is a substantial improvement on things.
“All the way up” means to not just use it for your tasks, but your projects, objectives, and so on. (Another framework here coming soon.) Whether you’re talking about something that’ll take you 10 minutes or 10 months, there’s still a verb that’s in front of whatever it is.
Another thing to recognize about the power of verb-noun constructs: it makes it apparent when you need to chunk a project into doable parts because the immediate question that comes up is “what needs to be done to do that?” If you know that you need to email Mike to send his QLM Matrix before you can finish the TPS Report, then it’s easy to see that the TPS Report is actually a multi-step project with sub-items. What other items are there? Not only that, but the verbs that go in front of tasks and those that go in front of projects are normally different, again giving you a signal about how much work it’ll take to complete the thing in question.
Do yourself a favor and make the default habit that items with a time requirement always contain their due date so that you develop the practice of immediately being able to see the difference of what needs to be completed anytime versus what needs to be completed at some specific time.
Also consider the difference between when something external is due and when you need to have it completed and be clear in your action item. Again, back to our example: “TPS Report” could now be “Draft TPS Report by Thursday (due to Manager Rob by Friday).”
This one can be tricky, because sometimes it’s clear who should do it and you can make them responsible for it. However, in some cases, you’ll need to assign ownership just so that it gets done. Many managers and leaders fail to understand that if someone else isn’t assigned the item, by default, the manager or leader is responsible for seeing it through, which often isn’t the intent; they want “somebody” to do it. Remember, “somebody never does anything” – specified people do specified things.
Many action items are meant to spur the action of someone else in the chain of a project; think of multi-person projects as a relay race, wherein one person runs a piece of the race and hands off the baton to the next person. In our example above, Mike’s completion of the QLM Matrix enables the next step in the process, but if he completes it and doesn’t send it, then we have a relay fail. A lot of time is lost by poor handoffs and days easily become workweeks. (Relays are one of the first things I look for in team workflows because streamlining them yields immediate and lasting benefits.)
When handling relays, you can either split the items into two discrete items – e.g. “Update QLM Matrix for Sarah by Wednesday” and “Send Updated QLM Matrix to Sarah by Wednesday” – or develop the internal habit to automatically send the item to the next person in the chain. Well-functioning teams with effective people usually opt for the latter because they trust each other and the process.
An advantage electronic task management systems have over physical systems is that you can supply additional information about the task. Giving context about the task – such as stating why the task is important or giving background information – can help you and whoever gets the task complete it better and often motivates them to do it. A whole horde of tasks can often appear as busywork, but knowing where and why your work fits in can be incredibly helpful. You’d be surprised how much taking an extra 10 seconds to write a couple of sentences can affect the quality and timeliness of execution.
These steps are listed a logical, sequential order that’ll help you process each action item. You’ll notice that the order moves from “What needs to be done?” to “by when?” to “by whom?” to “what next?” to “why?” You may not have a “by whom” if you work for or by yourself, but the rest are still relevant; on that note, many solopreneurs have trouble delegating precisely because they automatically assume that everything that needs to be done needs to be done by them.
Writing Better Action Items is a Practice
Most things that are worth doing take continual practice and writing better action items is no different. I’ve ingrained these things as habits after doing and teaching them for so long and figuring out what works and what doesn’t. Does it take some extra time? You bet. But much more time is usually wasted by poorly formulated action items because they’re not spurring the actions needed to complete them.
Take, for instance, the verb-noun construct rule. I actually get confused when there aren’t verbs in front of action items and immediately correct them mentally when I see them. It’s a bit sad to admit that it causes me a bit of anxiety to see them because it opens an unhelpful curiosity loop. Years of practice make them pop out like misspelled words do to an editor.
And, like any other practice, it’ll eventually become a habit. Getting stuff done is a lot easier when you have habits like these because it’s one less thing you have to think about and make decisions on.
Over to you: of the items listed above, which is the most challenging for you?