Task management is a critical part of any process; beyond lies the precipice, an increasingly sheer descent of missed deadlines, forgotten details and abandoned deliverables. When projects go bad, poor task management is often to blame; while no one might remember exactly where a project slipped off the mainline, the cascading failure of incomplete or unacknowledged tasks is an unmistakable sign to stakeholders that things have somehow gone irrevocably wrong.
The problem with most task management systems is that they’re easily derailed by unexpected urgencies: misprioritization, politicization, extraneous detail, things unquantifiable. Little wonder so many project managers fall backward into the arms of Stephen Covey at the first hint of trouble.
To counteract the pressure to prioritize by urgency, I use a lightweight form of structured task notation I call NUB (non-urgency based) notation. It focuses on capturing a minimum of quantifiable data to assist in the rapid scanning and sorting of tasks. The key word here is “quantifiable” — if it can’t be quantified, it shouldn’t influence prioritization. Too often, besieged project managers prioritize based on whether something is easy (“we’ll just knock it off and move onto the next thing”), difficult (“after we crack this one, it’s smooth sailing”), politically expedient (“if we can nail this, it’ll get executive management off our backs”) or a source of irritation (“God, I’m tired of hearing about this; just do it and let’s move on”), none of which might be appropriate criteria for assigning priority.
In NUB notation, every task is expressed in four parts: stoplights, description, status and limiters:
[stoplights] description [status] [limiters]
Here’s how a relatively simple task might be expressed in NUB notation:
Build fence (-$500)(-16h)
In other words, we need to build a fence which will cost $500 and require two days labor. Now here’s a more complex task:
! ? Normalize production database: 25% (31-Dec-10)(+$1000/w)(-16h)(#8)(>7)
This time, we need to continue work on a database (we’re a quarter of the way there, with an end of year deadline), which will save us $1,000 per week. Unfortunately, this task is dependent on another task; we also require input from someone or something else. This particular task is mandatory.
(By the way, I’m not implying here that building a database is a more difficult task than building a fence. I’ve built both fences and databases, and it was the fence that nearly killed me. Databases don’t warp after you’ve sunk them in concrete.)
Here’s a breakdown of each component in a NUB task:
Optional single-character stoplights precede tasks and indicate critical meta information about the task. These are the stoplights I use:
|!||The task cannot NOT happen. Declaring a task mandatory must be an explicit declaration, rather than an implicit assumption, which prevents overestimation of criticality.|
|?||The task is waiting on someone or something else. While work on this task might not yet be stalled, it cannot be completed.|
|~||The task requires more thought. Allowing for this stoplight encourages early notation and prioritization of tasks.|
The task description should be as brief yet precise as possible. Ideally, it should be no longer than an SMS or tweet. The shorter the description, the easier the task list will be to scan.
If a task has begun but not yet been completed, the approximate percentage of completion should be shown. I tend toward a spectrum of 25%, 50% and 75%. If a task has not yet begun, I leave the percentage indicator out rather than adding the clutter of “: 0%”. Likewise, if a task is complete, I might briefly apply a strikethrough, but generally I’ll simply delete it rather than denoting it as “: 100%”.
Limiters are optional but important attributes of a task which allow for efficient prioritization; this is the heart of the NUB system. I use three types of limiter: deadline limiters, value limiters and reference limiters.
|(15-Jul-10)||The deadline limiter is simply a date, provided with the least practical amount of granularity (e.g. if a task is due by a specify day, specify so, but if it’s due simply by the end of the month, leave off the day).|
|(+$100/w)||The plus or minus prefix denotes whether the task represents a gain or loss. The amount can be expressed in dollars, dollars per unit, hours or hours per unit.|
|(q)||Because there are tasks whose value cannot be expressed in money or time, a “q” indicates a quality of life gain.|
|(#1)||A number sign denotes a unique identifier or ID for this task which can be referenced either elsewhere in the task list (see predecessor limiter below) or outside of the task list.|
|(<1)||The predecessor limiter simply points at another task which has the specified indicator or ID, denoting that this task is dependent on that predecessor task.|
The Anatomy of a Task
Using the above, we can now express the abstract structure of a task more completely as:
[stoplights] description [:status] [(+-money/unit)(+-time/unit)(quality of life)(identifier)(predecessor)]
Although in this form the structure appears complex, it becomes second nature after you’ve done it a few times and will encourage early notation with incremental refinement.
Like many occasionally overwhelmed task managers, I often apply a higher level of structure by grouping tasks into discrete lists. Lists can be assembled based on category, location, business unit, project, or any other form of aggregation desired — but shouldn’t be structured around attributes which exist down at the task level (e.g. “things to do this month”).
As with any other platform- or industry-agnostic methodology, the benefits of NUB task notation are limited by the uniqueness of the environment in which it’s applied. I wouldn’t, for instance, want to use it to land 747s. (I have a $20 Amazon gift certificate for the first air traffic controller to demonstrate its applicability in the tower. But I will never, ever fly in or out of your city.)
For project managers with a broader selection of problem-sets, NUB task notation offers a means of quantifying the relative value of disparate tasks without having to resort to life balance worksheets and urgency matrices.