Brontekst bekijken van TaskAlot 3.1 - Functional specification

What do I want a custom ''online collaborative project management system'' to be? This is a ''functional specification'', which means that it is independent from any specific technology (like Notion). See [[TaskAlot 3.0 - Context]] for some background.

== Goals ==

Hmm, I haven't stated goals before for this system. Let's do that now - Brainstorm:

* Have an overview - The absence of the feeling of impending doom - Know what the most important projects are in my life and how they are going
* In the blink of an eye, I want to know what the most important tasks are, that are waiting for me
* An easy way to record tasks and be sure that they won't fall in between the cracks somehow - ''Brain deposit - Breindepot''
* An easy way to see what I should be doing right now
* An easy way see what people with whom I work together, are working on, and when they are supposed to deliver stuff
* An easy way to see project descriptions and other project-related info
* Share specific parts of projects with others, including editing rights.

== Tasks ==

''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 mainly for delegating or coordinating 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.

=== Relations ===

* 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, like when I use it as a ''brain repository - breindepot'': 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
* Tasks can belong to multiple categories and therefore to multiple projects
* Tasks can belong to multiple categories but no projects. Example: ''Online shopping list'': A list of both private and business stuff I am assembling to eventually buy it all at once
* 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. See the separate chapter about this, further on in this article.

=== 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.

=== Categories ===

* 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
* Categories don't have a changing status, like ''finished'', ''closed'' or ''inactive''.

=== Projects ===

* Traditionally, a ''project'' is something with a start- end endpoint in time. That's not the case here. A project can last indefinitely. Maybe I should give it another name
* At any one moment, there are about 20 different projects
* I believe that Projects are always associated with Categories, but this shouldn't be compulsory
* Projects get frequently split, merged and especially: ''renamed''
* Projects have a status that can change, with states like ''finished'', ''closed'' or ''inactive''. See ''Cascading'' elsewhere for details.

=== 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''.

== Cascades ==

As mentioned before, concerning hierarchical clustering, there can be ''cascades'', ''contingencies'' or ''propagations'': Changes on one level, have an impact on entities below it. There seem to be only two cases of this right now:

=== Closing a project ===

When closing a project (whatever the exact property and state may be), all tasks in that project, should also be closed:

* 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).

I'm not sure if this is a ''nice-to-have'' feature, or ''need-to-have'': I found it really annoying that when a project is closed, that there are still associated tasks floating around (e.g., when you select tasks per category).

=== Select projects within the category ===

After associating a task with a ''category'', the subsequent choices concerning ''Project'', should be limited to the projects within that category.

This is ''nice-to-have'': I found it mostly unsophisticated, that this doesn't work, especially since it's so obvious to do such a thing in MySQL.

== Notes ==

Include static information to projects (also to other entities?). I used to do this with a separate Kanban state ''static'', but it can surely be done in a more elegant way.

== 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

== Overviews ==

There should be some ''overviews'': Boards where tasks from various projects are brought together. This is the great advantage of Notion for me. E.g.:

* 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).

== 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

== Business & private 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.

== Task Fields ==

An impresion of some fields. This is not complete - Maybe this is actually too detailed:

=== 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

=== Category ===

(universal, optional, no default)

* A task can belong to multiple Categories - See above at ''Tasks'' for details.

== See also ==

* [[TaskAlot 3.0 - Context |                  TaskAlot 3.0 - Context]]
* [[TaskAlot 3.1 - Technical specification |  TaskAlot 3.1 - Technical specification]]