TaskAlot 3.1 - Functional specification

This is the functional specification for TaskAlot 3.0. See TaskAlot 3.0 (Notion) for context.

Tasks

Basic building blocks

Tasks are the basic building blocks of a project management system:

A task can be anything

Within Extreme Programming, a task can take up to a couple of days
The expert that build TaskAlot 3.0 said that tasks typically take less than a day. That way, they can easily be incorporated in an agenda function within Notion

For me, it seems that a task can basically be anything: From a vague idea for a new project to something as small as put out the garbage tonight:

I think it's important that I can create tasks without having to be specific or having to think whether the thing I want to create is a task or maybe something else. Often, tasks become more specific when they get a due date, but it doesn't have to
Sometimes tasks can be specific and still take multiple days. Or are really simple and still take multiple days
In Notion, tasks can include checklists, textfields, templates, etc. This makes it attractive to make tasks relatively large, and I really like that flexibility
When collaborating, I use boards and tasks only for 'distributing' tasks to individuals. Not for 'operational collaboration'. What I mean: Sometimes I might delegate something small. At other times, it might be a whole project. In both cases, these can be just single tasks.

A downside of this: It might not always be possible to link tasks to an agenda item. And that's fine.

Other aspects

Tasks are usually associated with Projects. In that case, they should automatically also be associated with the corresponding Category
It is possible that a task is associated with a Category, but not with a project - For example when I know already to what Category a task belongs, but not yet to what Project
It is possible that a task isn't associated with a Category or Project at all - Again: When I just want to not forget something, but I didn't yet figure out where it belongs
Tasks can belong to multiple Projects (and therefore to multiple Category-Project combinations) - That's quite important: When I'm not sure to which project a task should belong, I associate it with both, so it doesn't fall in between the cracks
Multiple persons can be associated with a Task - This is important

Clustering tasks

It seems natural to group or cluster tasks into collections or groups, based on shared characteristics. That sounds academic, but it is very practical. e.g.:

All tasks for this week
All tasks for customer x,
All tasks for all customers
All tasks delegated to person Y
All tasks with high priority.

Further:

Some ways of clustering are more-or-less static. Others seem to change with the weather
Tasks don't have to belong to any group
Tasks can belong to multiple groups. E.g.: When I'm not sure if a task belongs to group x or y, I tend to associate it with both, rather than risking that the task gets lost in the cracks

Hierarchical & cascading

It seems that the most visible and obvious way of clustering, is hierarchical. This is also the default way of clustering that I use: Tasks belong to projects and projects belong to categories:

Grouping in projects and categories, is the default way for me to think about grouping tasks, and the default way to navigate them and to view them
Tasks don't have to belong to any project or any category
Tasks can belong to multiple projects and multiple categories.

There is something specific about hierarchical clustering, that I call cascade or contingency: Some changes in property on objects higher in the hierarchy, should effect the objects lower in the hierarchy. E.g.:

When closing a project, all tasks in that project, should also be closed
After associating a task with a category, the subsequent choices concerning Project, should be limited to the projects within that category.

Non-hierarchical

Non-hierarchical clustering can be pretty much around any property of tasks. Some examples:

Kanban state: {Backlog; Next; Current; Done} or {Backlog; Doing; Done}, etc.
Priority: {High; Medium; Low}
Owner: {Alice; Bob; etc.}
Week entered: {Weeknumber}
Week due: {Weeknumber}
Week planned: {Weeknumber}.

The way that membership to these groups is indicated, or how particular elements of the group (taxons or properties) are indicated, can also be anything:

Text
Order of lists on a board (like for Kanban states)
Background color
A colored bar (like for priority)
Icon
...

Categories & Projects

Concerning hierarchical clustering, I seem to have the following levels:

Categories - The most top-level clustering
Projects
Tasks.

Details:

I currently have 7 categories, the first 5 of which are business-related and the other 2 of which are private: Revenue-X, Revenue, Overhead, BizDev, R&D, Private-X & Private
These 7 categories are rather static. Maybe once per two years there is a change
At any one moment, there are about 20 different projects
I believe that Projects are always associated with Categories
Projects get frequently split, merged and especially: renamed.

Project aliases?

I used to have something that I call project aliases: Like alternative views on groups of tasks, e.g., a project alias Klaas for all tasks that are assigned to Klaas.However, this might actually just be an example of non-hierarchial clustering.

Views

Some ideas about different ways to see the information in TaskAlot. The word view is used loosely here - it doesn't mean a specific technical thing:

Startpage: All tasks
Projects - Default: A view for each project, like in Trello. With the Kanban-states as column headings and tasks as their content
Projects - Alternatives: Views where data is presented according to other criteria

Task Fields

An impresion of some fields. This is not complete and even their names can be changed:

Kanban state

(universal, optional, default is Backlog):

I currently use Backlog, Next, Recurrent, Current, Done and Static
Static is for static (non-task) information that I somehow want to incorporate on a board like a task → Don't use this anymore. There are probably better ways to do this
I am not sure what the state would be of an unfinished task, when a project gets closed. Cancelled, Closed?

Local state

(non-universal, optional, no default, a better name might be welcome):

A state that is only used on this very board
You can see an example in the Trello board displayed earlier: Amongst other, it has lists for the various weeks in which tasks were delivered, like OK - Wk 12 and OK - Wk 36. At the end of a year, I usually go back to add the year (so the first would become OK - Wk 2022.12. This grouping is ad-hoc. There is for example no heading for a week in which there were no deliveries.

Priority

(universal, optional, default is Normal):

Priority means different things to different people. To me, it means stuff that I should do before doing non-stuff priority. Funnely enough, something that has priority at any one moment, doesn't automatically still has priority later on. Simple example: On Monday morning Putting garbage outside has priority. On Tuesday, this doesn't have priority anymore, even when I didn't do this task. But next Monday morning, it will again have priority.

I currently use Normal, High & Low
To be more precise: I currently use Normal priority, High priority & Low priority, so that in Board view, I understand what this field is about. Just High might not be enough information.

Week entered

(optional, default is current week number):

For planning purposes, I usually think in weeks
The number of the week in which the task was entered. I use that information to monitor how long a task has been open
It probably also needs an associated year in which the task was entered.

Week of delivery

(universal, optional, no default):

The number of the week in which I plan to finish the task. This is not the same as the deadline for the task
The associated year should probably also be saved.

Project

(universal, optional, no default)

A task can belong to multiple projects - Discussed before at Tasks
All projects have unique names. So, knowing the name of a project, would be enough information to know to which Category it is associated

Collaboration

Some observations, mostly based on using Trello for some years:

What vs. How

When it's about working together with others using online project management systems like Trello or Notion, I usually use these systems for delegating, and not for 'operational collaboration':

Collaboration is mostly about what tasks (and maybe projects) are delegated to whom
Collaboration doesn't cover operational activies: The folks with whom I collaborate, might use their own project management systems for managing the tasks that are delegated to them. Or to put it differently: I care about what they will deliver, but I prefer not to be involved in how they do it
Conversely, I don't feel always comfortable that others can see my 'operational stuff'.

This is another example why to me, a task can be anything: When I delegate something relatively big or complicated to somebody, it can still be just a task to me.

Access is optional

Contrary to the title of this chapter: Folks with whom I collaborate, don't automatically need to have access to the online project management system that I use. Just as others don't have access to my PostIt Planning (frankly, I often don't have access to this planning system myself, and that's why I stopped using it).

Private vs. shared

When sharing a Trello board with someone concerning a certain project, I often run into the baffling problem, that there is stuff that is genuinely relevant to me as part of that project, but that I prefer to keep private from that other person. E.g.:

Pay her invoice this week
Ask why she called X exactly X
...There must be better examples.

As a result, I often end up with two boards or two systems: The one that I shared with the other person, and an additional private system. That's really stupid. It would be nice to have a solution for this.

Contrary example: Meetings & corona

In 2020, I was part of an organisation that had about 40 face-to-face-meetings in The Netherlands. Suddenly, all these meetings moved to online platforms. With four people, we processed all the incoming information about these changes (email, WhatsApp), to update a central website. This was an example where collaborations were indeed operational:

There wasn't any additional level of project management beyond the Trello board that we used
All four of us could do all jobs and take over any other person's job, if needed
We all had access to the same information (it was all on one board)
There was no 'private' information

Overviews

There should be some overviews: Boards where tasks from various projects are brought together, like:

All tasks from all Projects or all Categories
All tasks with high priority
All tasks that don't belong to me.

In order to be able to group tasks in overviews (where data from multiple boards come together), they need what I dubbed common, or universal fields. This is indicated with Universal in the list above at Task Fields. In practice, I suspect all fields will be universal, unless they clearly aren't (like Local state fields).

Contingency - Closing a project

When a project is closed, the status of the corresponding tasks, should be automatically updated accordingly
Example: Project Jamboree22 (a family gathering last July): When the party was over, the project could be closed. There were still a lot of open tasks (e.g., Check inflatable matrasses), but they all became irrelevant
When a task is part of mutiple projects, their state should not be affected (e.g., Hang up shelves yellow room was part of project Jamboree22 but also of project Renovation22 and should therefore stay open)

Business & private stuff in one system?

Originally, I felt that I wanted both my private stuff and business stuff in one system, for in the end, they all should come together in one planning or one agenda. However, I'm not sure anymore about this (Dec. 2022): It doesn't feel good to mix business and private like this - More shall be revealed.