Logseq Project Management

Journal as source

To maximize organization and efficiency, I maintain my journal as a single source of truth for note-taking. After jotting down notes, I use block embeds and updates to these blocks to refine them into well-structured notes, categorizing them into topics, projects, and other relevant categories.

As I’m updating these blocks they slowly turn from random thoughts into well optimized thoughts that can easily be re-used.

More about that in my Why Journal-Based Note-Taking with Logseq is My Go-To Productivity Tool

But, there is an exception…

Larger Projects

Using a page reference to collect notes and tasks works wonderfully most of the time but there is one exception for me and that is task management in Projects. And the issue I have there is that on complex projects it can become messy. What work has been done, in what order does it need to be done how are all these things related.

So with projects, things turn around, instead of block embeds that point to the journal, the journal points to the tasks in a project.

Benefits of putting the task in Project

The primary reason for categorizing tasks into a project is to enable effective organization and progress tracking towards project completion. With the use of an outline, I am able to identify task relationships, determine the next steps, and obtain a quick visual overview of task dependencies.

But, couldn’t I just do it with a block reference? Why the change?

Because by pointing journal entries to these tasks, each task contains a logbook of the work, notes and thoughts I had while trying to complete it. Creating a roadmap so to speak of all the work done. Just click on the block reference number as you can see in this screenshot.

Workflow for doing tasks

To get this log, what I do is during my workday, when I log work I create a block reference to the task and add notes to it. It reminds me about what I’m trying to do and allows me to create this running logbook.

Collection phase

One problem however is collecting tasks, as I don’t want to switch pages while making meeting notes to add a todo to a project. So what I do is just create the task in the meeting, link it to the project and add a #O tag. O for Organize.

Later, as I’m planning for a project, I will move the task from the journal to the project and replace the journal version with a link to the task. Creating the first log entry. Showing when the task came into existence.

Finally I remove th #O tag, so I can easily filter for tasks I need to Organize later.

Isn’t this a bit complex?

This is true, and it’s overkill for small projects where just linking together is more then enough. Keep things simple as long as possible.

But once a project becomes complex and you start to lose overview or get a desire to create a steps outline to get back control? Time to start moving all the tasks into the project page.

And then I won’t even talk about how to deal with projects with sub-projects. That’s it’s own insanity