After a question on the Discord, I wanted to showcase a potential project management workflow that you can use in Logseq. Hopefully the below article provides you with enough information and food for thought to implement a workflow in Logseq.
In this articles we will review an example of how I record information on projects (from setting up the project page to taking meeting notes) as well as namespaces and tasks. I will not touch upon queries or templates as these are discussed here.
The method listed below is what I have used over the past year and a bit. I have finetuned it and tweaked it along the way, and even though there are some aspects I would like to refine further, it is working in an effective manner.
When I obtain a new project, I will create a page straight off the bat with the name
Project/abc (change based on what works for you and the actual project name).
I like adding
work/ before the name of the project to define a namespace. This is explained below but think of it as a folder and file structure. The Project would be your folder and abc would be the file within the folder.
One the project page, I will typically enter a few key metrics/pieces of information of the project . These include:
- Some info
With the above I am trying to capture information I think would be useful to be able to compare and contrast against other projects using queries. I like to consider properties as data I would want to see in a database so that I can transform this to determine useful information from it. You can of course have any other property that you might deem worthwhile.
After the properties, I like to have a few lines about the project. I treat this as my area to include the key synopsis of the project. I am only looking for key, punchy lines to be able to create a snapshot of what the project is about – I like to keep these to a maximum of 15 to 20 blocks. The purpose of this is to create my elevator pitch. Lets say in six months someone asks about project abc and what it is about. A quick search will return the page, I now just need to spend a few minutes reading the key information and off I go.
A complete example may look something like the following:
- Status:: #Open
- PM:: [[Chris]]
- Colleagues:: [[Bob]], [[Pat]]
- Budget:: USD 100,000
- Completion:: January 2023
- Location:: South Africa
- Involves a new cell phone mast
- Rural communities, so need to be aware
- Power supply issues?
With the project page set up, let’s look at how we might go about taking notes on it. There are really two schools of thought on this:
- Create the meeting notes in the project page with each parent block being the date of the meeting
- Create the meeting notes on the Daily Notes Pages with the parent block referencing the project.
I always use the latter. To me the DNP is the starting place for everything. This avoids having to think / find the page where the note should go. I am on the DNP and I can type at free will – much less friction.
When I am capturing meeting notes, I separate them out in three main section:
This allows me to add structure to my meeting notes. I could of course go straight in and create a bullet point for each but this get messy when referencing information later on.
An example of a completed meeting note, may look like this:
I will follow the same structure for each of my meeting notes so that when I click on the project name, I can see the information in a uniform manner, like so:
I can then expand and collapse as I see fit. The advantage of the above is that with a quick review I can easily see what has been done on the project.
The issue of not introducing section headings, means that your data is returned like this on the project page (see 4th July entry):
Yes, with 4 points it does not make much difference, but think if there were 10 attendees, lots of discussion points and even more tasks. If would simply be a long and messy list.
The purpose of the above is to be able to retrieve information with the least possible resistance. Adopting the above allows me to do exactly that.
So why did we add
project/ when naming out project page? The answer is to create a little bit of structure in an otherwise flat storage.
You can see that when we create a new project and also name is
project/def it will add a page to the hierarchy. We can go many levels deep – it really is a matter of preference/
I like using this as it gives me the possibility of seeing all of my projects in a quick and easy manner. The last thing I want to do is hunt around for project pages or tags in my graph. It does take disciple to always call it in a similar manner, but after a few you should get the hang of it.
Tasks / Todos
So you might be asking, in the meeting notes, why did we indent the tasks under the name of the person responsible. The answer is again, for ease of retrieval and review.
If I click on the Bob page, I can see what that person is up to. I can see the meetings attended, the tasks to be done and maybe a brief description of him.
And, even better, in my opinion is that if I do to the TODO page, I can see all of the tasks, when they were set and who they were set to without much friction.
This is useful as it gives me an overview of who still has what to do, and whether someone is falling behind.
It would be useful to be able to filter out tasks by say Bob vs those assigned to me, but this may be something that can be implemented in Logseq down the line.
So how do the pages appear within file explorer?
Well, you have your normal Logseq folders (journal, pages etc.) and if we go to Pages, we can see the pages that we created in Logseq. You may see some with a
%2 in the filename – this is normal and I believe it is the ascii character of the slash when the file is saved.
Opening the files, you will see the content of what we created in Logseq.
Here is the whole process in a video:
Thank you very much for reading hope you found that useful