First, OCD may require professional help if you can't manage it rationally.
With that being said, managing personal projects is simpler than "management" which involves human interations.
In short, start with a basic pen, paper or notepad-like software. Update it as shortcomings appear. Managing is like designing data structures or databases: it involves "reads" and "writes" (I actually mean "search and read" and "search and write", to be percise), starts simply, and is designed around use cases.
I've applied this to cooking. I used to struggle finding spices in a deep drawer. I realized they were organized like a stack, making it difficult to reach the ones at the back. I moved them to a wider drawer. The frequent used ones shuffles to the front, whereas the less used are left in the back. And with time, I memorized their rough locations.
This process mirrored data structure design: starting with a minimal structure (linked list), moving to a more complex one when it becomes slow (search trees), and further improving it when it gets imbalanced (AVL tree). You'll not going to invent red–black tree in the first place - even copy it from the text book is a pain.
This perspective can be applied to anything - digital data, paper systems, or physical spaces. 'Reads' and 'writes' costs are determined by the system you use. System efficiency depends on its use case and time as costs are "amortized".
A few examples:
Diary: Easy to write, harder to read. Low overhead makes it enjoyable to write.
Dictionary: Takes longer to write, quicker to read. The large audience justifies the high writing cost for well-organized indexes.
Research notes: Balanced read-write (citations and knowledge graph). Constantly evolving knowledge even makes folders inadequate, hence the popularity of software like Obsidian and systems like Zettelkastens. But such systems take efforts to build so most people adopt instead of developing their own.
RDBMS: Balanced read-write but difficult to develop.
Kafka-ish DB: Designed for high-speed writing. RDBMS is too slow for its use case due to constant indexing.
Your system will depend on your use case, which will emerge over time.
With that being said, managing personal projects is simpler than "management" which involves human interations.
In short, start with a basic pen, paper or notepad-like software. Update it as shortcomings appear. Managing is like designing data structures or databases: it involves "reads" and "writes" (I actually mean "search and read" and "search and write", to be percise), starts simply, and is designed around use cases.
I've applied this to cooking. I used to struggle finding spices in a deep drawer. I realized they were organized like a stack, making it difficult to reach the ones at the back. I moved them to a wider drawer. The frequent used ones shuffles to the front, whereas the less used are left in the back. And with time, I memorized their rough locations.
This process mirrored data structure design: starting with a minimal structure (linked list), moving to a more complex one when it becomes slow (search trees), and further improving it when it gets imbalanced (AVL tree). You'll not going to invent red–black tree in the first place - even copy it from the text book is a pain.
This perspective can be applied to anything - digital data, paper systems, or physical spaces. 'Reads' and 'writes' costs are determined by the system you use. System efficiency depends on its use case and time as costs are "amortized".
A few examples:
Diary: Easy to write, harder to read. Low overhead makes it enjoyable to write.
Dictionary: Takes longer to write, quicker to read. The large audience justifies the high writing cost for well-organized indexes.
Research notes: Balanced read-write (citations and knowledge graph). Constantly evolving knowledge even makes folders inadequate, hence the popularity of software like Obsidian and systems like Zettelkastens. But such systems take efforts to build so most people adopt instead of developing their own.
RDBMS: Balanced read-write but difficult to develop.
Kafka-ish DB: Designed for high-speed writing. RDBMS is too slow for its use case due to constant indexing.
Your system will depend on your use case, which will emerge over time.