Posted on July 21, 2021 @ 12:07:00 PM by Paul Meagher
Todo lists are an often used tool for being productive. Todo lists, however, can hide alot of the complexity involved in performing a task. A simple way to think about a todo list is that you create a list of tasks that you want or need to accomplish and check each of them off when they are done.
Lately I've been frustrated by the fact that before I can engage in doing a task I either have to fix something, find some item, or buy some item involved in completing the task. The various common ways in which your todo list tasks can become more difficult I call "productivity impasses".
As an example, we recently buried a power line to our barn which involved digging a trench to lay the power line in. That created bare soil so I wanted to spread some grass seed over it and water the seeds in. Watering the seeds in involved hooking up a hose to a sprinkler and moving the sprinkler around before and after planting. Not a big job, but I forgot that at the end of last year I had difficulty removing the spray nozzle because I didn't take it off all season and it became cemented to the hose end. I used an angle grinder to remove it and ended up cutting into the hose end. When I attached that hose end to the sprinkler it sprayed out water at the connection point. So I spent some time trying to find a hose end connector needed to fix the hose (I often have a hose end connector lying around in case) but eventually decided to go out to a hardware store and pick up a new hose end connector. I then returned home, fixed the hose, and watered in the grass seed. So to accomplish
this task I had to spend time looking for a needed part, buying a needed part, and fixing the hose with that part before I could finally accomplish the task of watering in the grass seed.
This is an example of a find-then-do impasse, a buy-then-do impasse, and a fix-then-do. The need to find, buy, and fix stuff are often not included in the description of a task which might be stated as "water in the grass seed".
Another common impasse is the agree-then-do impasse where the time it takes to agree to do something eats up alot of the time that could be dedicated to getting on with the task. It can often be good to get different perspectives on a job, but it could become dysfunctional if you can't reach agreement in a timely manner.
A learn-then-do impasse occurs where instead of just getting on with doing the task, you have to spend time learning how to do it. For me, this often involves watching a few youtube videos until I get a good sense of how it should be done.
It is not clear whether you can anticipate all the impasses that might impede your performance of a task but knowing that some common types impasses might arise could be helpful in becoming less frustrated in managing your todo lists and better at estimating how long it might take if you factor in potential impasses.
One approach to creating more effective task lists might be to associate each task with a list of properties that might be specified to detect possible impasses. For example, the "Water in the grass seed" task might have this task description and set of properties to fill out or think about.
Water the grass seeds
- Agreement Required:
A task might have lots of properties worth analyzing, but the theory here is that examining tasks in terms of common potential impasses might be a good use of time. I am also aware of the "paralysis by analysis" concern and wouldn't get this detailed about most task planning.
A completed Task Properties List (TPL) might look like this:
Water in the grass seed
- Requires: Water Supply, Water Hose, Sprinkler
- Fix: Fix hose end. Get water working again in garden shed.
- Find: Hose end, Water Hose, Sprinkler
- Buy: Hose end
- Learn: No new learning required
- Agreement Required: No
Originally, my task was just to "Plant the grass seed" until the issue of getting hoses to work made "water in the grass seeds" a separate task. The Task Property List for planting the grass seed looked something like this originally:
Plant the grass seed
- Requires: Grass seed, water, tamper
- Fix: Remove large rocks, add river sand to level soil, tamp down soil, tamp seed into soil
- Find: Tamper
- Buy: Grass seed
- Learn: Watch youtube videos on planting grass seed
- Agreement Required: No
The scope of a task is another aspect one might reflect on when analyzing a task. Tasks often have a hierarchical structure with tasks embedded in higher level tasks. The task description should describe a task at the proper level of embedding. If the task is too high level, it might take a long time to complete whereas if you want to complete 5 tasks today, you might have to formulate your task description in way that makes those tasks doable in a day.
A different type of impasse is a fix-then-fix impasse where a fix creates other issues that have to be fixed. The task of "installing a new electrical service to the barn" created the task of reseeding the area that was ripped up to bury the line. Connecting the power line to a new service panel in the barn also created a plumbing issue because the water line ran where the panel was installed. So the task of installing a new electrical service to the barn created the need to fix the soil that was ripped up and to fix a plumbing issue. You could include these fixes as properties of the original task but generally it is better to think of the fix-then-fix type of impasse as generating new separate tasks to distinguish them from the smaller fixes that need to be completed to finish the task at hand.
I don't spend alot of time analyzing tasks in this level of detail. I was spurred to do so after noticing certain patterns in the types of impasses I was running into when trying to accomplish a farm task. I decided to itemize common types of impasses and then to analyze tasks by asking whether one of these impasse types might arise. The tool for doing this
I call the Task Properties List that has field labels associated with common impasse types.
Whether this is useful approach or not, I don't know, but it does seem like an interesting way to think about the structure of tasks. I chose the term "impasse" to describe these productivity zappers because there is a literature on impasse driven learning that might be relevent but which also might extend the concept of an impasse in more practical ways then the academic literature tends to do.