Task and Project Management

Hey Folks,

What are the ways you have set up your tasks/projects /goals etc.

I found notion too rigid forcing identical hierachies across domains and I would be spending too long maintaining the system.

Curious if people have built them more as page-integrated with in-line formulas and dates etc. or are tables still the way to go?

Currently leaning towards a page per project so I can capture notes in there, but it could get a bit bloated and things buried “somewhere’”.

Thanks,

Chris

Horses for courses…

I am firmly in the camp of having a single table for all actions that need to be taken. These actions can then have a characteristic for projects they belong to, and people responsible for them.

Then I have pages for the different projects, with views to the relevant actions. Integrated with this are documentation templates to record the requirements, the design and the test scripts.

In this way the “system” manages the project, while at the same time creating the documentation needed for future maintenance and training.

I see you used Notion in the past, but don’t know how well you know SH Docs: One of the really great features is the canvas column, which acts like a page where you can make detailed notes.

But, it’s just a ramble,
Rambling Pete

I just built a pretty extensive project management system for my company which is an architecture firm.

The main tables live in a database doc (hopefully soon to be replaced by workspace-level super-tables) where I have multiple DB tables for: projects, project phases, tasks, company staff and teams. Plus all their helper tables.

Then there are three main separate documents:

1. A Time tracking Doc that pulls the database tables via cross-sync, where every team member then record their working hours spent on each project phase and project.

2. A project managers Doc pulls the same set of database tables plus the project costs derived from the Time Tracking Doc + staff salaries.

In this way they can keep track of project costs versus allocated budget and using a simplified EVM system they can estimate the cost at completion for each project phase. This is the high level view.

  1. A Template file for individual Projects, where a sync view shows the main dashboard from the project managers docs and where multiple pages have replaced the numerous excel or word files we used to have for everyday work: Minutes of Meetings, meeting notes, List of Deliverables, Action Items, Project Contact Lists and so forth. This is the daily document that is shared with all the members of Project Team, to organize operational works.

And yes, to answer your question, everything is a table connected to other tables (often sub tables)for example, minutes of meetings is a table which has meeting notes as a subtable that include assignees, files and deadlines . And a detail view to show it all in a unified form.

When there’s a need for more page text, usually canvas columns are good enough for us.

Are you finding that too much to maintain?

I’m always cautious about meaningful builds like this as it can be hard to maintain and changes often mean a lot of re-writing and reconfiguration.

Unfortunately it wasn’t a choice, as it just replicates the same Company’s SOP we had in place before when we were using Google Sheet files.

Yes it needed maintenance and rewriting in the beginning (especially because cross docs can be tricky at times and I’m no way an expert Coda user) and you need to carefully understand your schema before committing to a certain setup. Now it has been running since January with no particular problems.

I encourage you to check out the many amazing contributions of users in this community and feel free to share a doc where you are building things. I’m sure a lot of people will be more than happy to jump in and guide you through.

Also, I learned tons of knowledge from @Scott_Collier-Weir and @Paul_Danyliuk YouTube channels and @Christiaan_Huizer Medium account, and I could have never done it without their deep knowledge of the software.

Cheers

Something I often say is don’t build your magnum opus as you join SH Docs. You need to “get” the new paradigm first. In that way you will better know how to build in ways that will not be difficult to maintain afterwards.