Portfolio: Tiered Projects and Missions
Missions are like projects, only more so.
In a recent post, Portfolio: Tasks and Simple Projects, I recapped how Obsidian’s native tasks and various aspects of the Portfolio approach can be applied to support simple project management. If you haven’t read that, I recommend you do so before continuing with this post. Likewise, Portfolio: A Knowledge Base Built on Files lays out some of the core ideas of Portfolio’s knowledge base model, which again is critical for understanding Portfolio’s recasting of markdown and Obsidian.
Simple Projects and Beyond
The simplest projects can be managed as a set of tasks. I say set, not list, because very frequently in my journaling in Obsidian, tasks in simple projects might be created independently across many notes, and not defined as a list of tasks in the same note. This crucially means that collating the tasks requires some unique taxon to be associated with every task in the set, like this, based on a project taxon:
The project taxon is •workings.co and a query to find all important/urgent tasks in the project might include this line (along with a lot of other directives):
Here’s the top part of output of a query to find all tasks in the workings.co project:
This query arrays the associated tasks based on the task states. Here, I’ve only shown the most active two task states, but the template I’ve created to generate such queries includes all task states, and a table of contents to be able to jump to any state.
In effect, that set of affordances — the tasks, taxa, and queries to aggregate them — is enough structure to represent a simple project in Portfolio. The implicit goal of the project is to amalgamate information sources — either notes in my vault or externally, through links to the outside world or excerpts clipped into notes — and eventually to write something on the topic, for me or for others.
But there are other projects that aren’t so simple, which I need to manage in different ways. In earlier writings, I’ve referred to these projects as complex, but complexity isn’t the right characterization, really.
I have found that I need to deal with two sorts of projects where the simple project approach won’t suffice.
These are what can be thought of as ‘tiered’ projects, composed of what are more-or-less subprojects, or areas of focus. I use the Projects plugin to implement these tiered projects. If you haven’t tried that plugin I suggest you read First Look: The Projects Plugin before continue, since it lays out the basics of the plugin’s capabilities.
Tiered Projects
A good example of a tiered project is one that follows the form of a kanban, where the columns of the Projects plugin board represent stages of the parent project, with the cards on the board are subprojects, and each of those may have their own task list. Here’s an example:
I reside at 17 South Cedar Street, where we own a 1920’s vernacular four-bedroom home. There are a lot of pending projects which I have collated into the 17 South Cedar tiered project. These subprojects can be undertaken independently, although there are some dependencies that are not obvious at the top level.
Zooming in on fix stockade fence:
Here I am using language that shows the contingent nature of this project: if I am going to replace the entire fence after I build an accessory dwelling unit (ADU) (a two-car garage with an apartment on the second level), then maybe I won’t make small repairs at all. (Note: it would be nice to have a plugin that allows more complex boolean logic like this.)
The task states indicate that the next thing to do is to assess the price of building a new fence, and perhaps to get that out of the way before undertaking the ADU project.
In principle, every subproject in the 17 South Cedar project might be this complicated. And, yes, the Projects plugin does support nesting one subproject into another, but honestly, the complexities of that are too much work for the payback.
There is a special class of tiered project where the approach used in 17 South Cedar doesn’t go far enough. These are what I call ‘missions’: tiered projects that require more views than just kanban-style states-based boards, and which run for a long and indeterminate length of time.
Missions
As I laid out in the previous section, I am involved in several ongoing tiered projects that are of indeterminate length and a great deal of complexity, such as the project information for my workfutures.io newsletter.
Until 2025, I had relied on simple queries-based projects or the board views of the Kanban plugin. I rapidly transitioned to the boards and other views of the Projects plugin once I learned of it.
I had relied principally on status-based boards in projects missions (that is to say, tiered projects being managed through the mechanisms provided by the projects plugin). This coninued the more or less standard Kanban model. The status-oriented approach is based on columns of the `projects` board view, named 0 working, 1 work, 2 waiting, and 0 worked.
I came to see this one-view approach as too limiting, since it's useful to view the same cards through different lenses, not just based on status.
In particular, since ‘workfutures.io’, ‘workings.co’, and ‘stoweboyd.io’ are writing projects, I want to be able to view the project cards organized by themes of the content being discussed and created.
Here’s a detailed example of Projects boards, this time for the ‘workfutures.io editorial project’.
In this case I have created several board views over the same cards, using different attributes to a/ define the columns, and b/ sort the cards within the columns. This is the by status view sorted by the theme attribute.
So, for example, the uppermost card in the 1 work column is fear of AI under the theme of +AI. I use this view to order the sequence of posts I am working on, and I pull together often ideas spanning several cards into a single post, and while writing that or after, the cards are retired by dragging into the 3 worked column.
I can also switch to the by theme view of the same cards. This is a cropping of that view. In the +AI column, the same card mentioned earlier — fear of AI — is now at the top of the column, and the other related card is immediately below, making it easier to consider how those ideas might work together in one post. These cards are sorted by the status field, which was the source of the columns names in the previous example.
In some projects missions, a third attribute (or more) might deserve prominence. For example, if I were assigning writing to contributors, I could create a view and a contributor attribute, where columns of the board would indicate those assignments. At present, workfutures.io does not have other contributors, but if I were to do so that would be quite straightforward to implement. Of course, the table mechanism in Projects allows you to see as many attributes as you’d like, all at once.
A Confession and Conclusions
I've only been using the `projects` plugin a few months (see First Look: The Projects Plugin from January 2025). My use of the plugin has both expanded and contracted as I discovered how it might fit in or replace other techniques for mission project management.
It's only this month that I have implemented this multi-view approach using more than one board view over a project, but I shifted quite quickly to this model for large-scale, ongoing projects, or missions (‘endeavors’, in the past).
Shorter-term, time-bounded projects might not even be complex enough to use projects management for, and in those cases a single view or just a project query might be enough.
My confession is that I had been finding projects to be not enough to manage these larger, more complex projects until I invested the time to experiment with multiple complementary views over the same domain of notes in a project folder. I had become quite frustrated until this small breakthrough led me to further embrace the projects model.
In so doing, I also decided to retire projects that were too simple to justify the time and effort to set up and manage these complex projects for them. In recent weeks, I have been retiring many projects inherently too simple for the overhead, while expanding the long-lived tiered projects with additional views and sorts.
As a high-level ‘dashboard’, I also created a query — importants — to surface all the urgent/important tasks from my four tiered missions (this only shows three):
Below the paywall, paid subscribers have access to the templates and queries that support simple and tiered projects. Users will have to play around with projects to see how it all works.
Keep reading with a 7-day free trial
Subscribe to Workings to keep reading this post and get 7 days of free access to the full post archives.