Happy Friday!

Projects revisited

One of the reasons I left GTD behind was the limiting definition of “project.”

In GTD, if an outcome requires more than one task to complete, it’s a project. The problem is, that’s guaranteed to bring you way too many projects. And, perversely, it creates a disincentive to break down stubborn tasks. If you do, voilà, you’ve got yourself another project.

No one wants an interminable list of projects. But you don’t want related tasks hanging out in limbo, either. So what’s the alternative?

Bins & Procedures

Before we dive into the meat of this newsletter, let’s look at two types of lists that GTD would classify as projects, but which my AP Productivity system handles differently.

Bins

A bin is a simple list that houses one-off tasks, tasks related by category, or what I call proto-projects—lists of related tasks that haven’t matured into full-fledged projects. Bins provide a simple place to store tasks without the rigor of a project.

Bins can align with areas of responsibility or different roles that you play in your life, whether temporary or permanent. You might have one for Home & Auto, another for Kids Stuff, one for one-off tasks at Work. I have a Bin right now for the musical Carrie, which I’m music directing for West Virginia University. When it closes on Sunday, I won’t need that bin anymore.

Procedures

A procedure is a recurring checklist that reliably completes (or automates) work.

A packing list for business trips is a procedure. Daily startup and shutdown routines are procedures. Adjusting the settings for different Zoom calls is a procedure.

So what’s a Project?

A Project is more directed than a Bin. The tasks aren’t just related: they’re coordinated to produce a specific outcome. And projects contain more than just tasks, as we’ll explore below.

A Project is more elaborate than a Procedure, and indeed often contains procedures. Procedures rarely require extensive metadata about timelines or the people associated with the process. Projects usually require that.

In short: a Project is a hub.

💡 Build your projects as hubs 💡

👆 That’s your weekend upgrade.

“A hub for what, though, R.J.?”

Projects combine tasks, parameters, and procedures, as well as inputs and outputs in the form of resources and work. All of those are directed toward a specific outcome. The Project is the hub where those components intersect.

Let’s break down each of these components and explore how projects coordinate them.

Project Parameters

Parameters define and describe projects.

Dates

There can be many dates associated with a project: Timelines, Deadlines, Reviews, and so forth. Your project’s dates may be as simple as Start Date and Due Date, or as complex as a set of waypoints to monitor progress.

In my projects, I include Start and Due Dates by default, and add additional date information as needed for specific projects or project types.

People

Many projects have clients or collaborators. Linking them to the project is critical. How they’re linked may be as simple as including their contact info so you can easily reach out, or as integrated as sharing a workspace with them.

Alignment

A project should serve a larger purpose. If your projects are misaligned with your goals or responsibilities, they may be drawing your attention away from what’s truly important to you or your team. If you include what goals or responsibilities your project aligns with, you’re far less likely to pursue distracting work. And if you find it difficult to determine what goal or responsibility a project aligns with, that’s a red flag that you might be doing the wrong work.

Review plans and schedule

Many projects require maintenance, and including their review schedule as part of a project’s parameters ensures you won’t lose track of the project in your system. Even if a project’s review schedule is simply “As needed,” it’s useful to include that parameter.

Project Procedures

A project for a business trip might include procedures for what to pack, how to book the flight or hotel, who to contact when you arrive, or more.

And every project will include a startup and shutdown procedure. The startup ensures the project is correctly included in your system and the tasks are available to surface to your attention. The shutdown helps you learn any lessons from the project, as well as archive it.

Those procedures make it more likely that your project will be successful!

Project Tasks

The task list for a project determines what gets done. Each task must be directed toward the desired outcome for the Project.

There may be different threads of tasks in a project. Maybe you have different conversations to have with different people, or work that can only be done in certain locations—and you have several locations.

Project task lists can be overrated. Don’t spend all your planning time plotting a complete project task list. Many—indeed, most—tasks don’t make themselves apparent until you’ve done some prerequisite work. Define enough specific tasks to get going, and then collect and complete additional tasks as they arise.

Project Input & Output

The last components coordinated by a “project hub” are the Resources and Assets that inform the project, as well as the work that is created as part of the project.

There should be links to relevant URLs or other support material, and the work itself should be either in the project or easy to get to.

How can Tools for Thought help?

If you’re new to the Weekend Upgrade newsletter, I explore how processes can be created in Tools for Thought (TfTs). TfTs are apps optimized for linking your ideas, thoughts, notes, etc.—apps like Tana, Amplenote, Roam Research, Logseq, and Obsidian.

My project structure in Tana uses searches to gather my tasks and resources, and fields to define the parameters—who are my clients or collaborators, what dates are relevant, and so forth.

When I create a project, I take a few seconds to fill out the parameters to ensure everything important is defined.

Then later, when I create a project task (anywhere in my Tana graph), I can connect it to the project using a field that links todos to existing projects.

Different TfTs would have somewhat different implementations. Roam relies more heavily on inline tags, attributes, and queries, for instance. But fundamentally, the concept is the same: Projects serve as hubs for other lists—parameters, procedures, tasks, resources, and so forth. Projects are where those components can interact to move your work in the right direction.

What do I do next?

(1) Take 2 minutes and answer this question: What’s one thing I learned in this newsletter that I can put into practice right away?

By committing to a specific action, you make it much more likely you’ll do it.

(2) Review a few of the key projects in your system. Are they serving as effective hubs for their tasks, parameters, and everything else?

If not, update them so your project hubs gather all their relevant information.

If this was valuable for you:

Share the newsletter with someone you think would also get value from it! https://rjn.st/weekend-upgrade-newsletters.

Until next time, friends:

Make sure all your project information is readily available, and you’ll work a lot more efficiently and get a lot more done!

R.J.
​rjn.st/links​