I’ve known about the JD system for a while, but only recently I became aware there was a workbook and other resources. I’ve just finished reading the book, the updated website and I have a question.
In Section 13 of the website you present the problem of a freelancer with many clients. You show that the classical JD system built on a AC.ID (= 10/10/100) structure does not work so well with that situation, as the structure can either be “Work / 10 clients / 100 jobs” (no subfolders) or “10 clients / 10 jobs / 100 subfolders”. There is no way to arrange the structure to have more than 10 clients with more than 10 jobs each and subfolders.
To solve this problem, you present a “Multiple Systems” update in which the items are organized as SYS.AC.ID, allowing a lot more items (= 2600/10/10/100). What I don’t understand is, how does that solution apply to the “freelancer with many clients” problem? Unless I’m mistaken this is not explained. Is each “SYS” supposed to be a client? In that case, you end up with something like a C01 (= Client01) system containing 10 areas, each area containing 10 categories, and each category containing 100 items. To me that looks like way too much granularity (what do you do with those 10,000 possible folders per client?), and this approach does not fit with what I’ve understood from other parts of the website/book – that a “system” should be reserved for really, really large initiatives like “building a farm”. Also, in that structure, at what level are the jobs supposed to live? Area, category, ID? The first two levels are still limited to 10, so how do you record more than 10 jobs per client? I fear I’m missing the point.
Reading up on the forum, I realize I might be part of the “Academics” cohort that create so much confusion, sorry about that
Here’s an interesting thread The Freelancer system discussing this problem. Check out the video Johnny posted in response if you have time.
I have my own version of this problem. I won’t go into too much detail, but here’s some advice: forget about the SYS.AC.ID numbers. I’ve found using ‘YYYY-MM-DD’ is useful for titles, and I sort projects into folders by year (‘YYYY’).
Yes, that’s way too many folders to functionally manage.
It might help to take a step back and think about what it is you need to organize as a freelancer. Consider “How many clients do I expect to have each year?” and “How many ‘projects’ can I expect per client?”. You probably don’t need as many folders as you think.
At scale, a database becomes helpful. The website and workbook hint at using databases, but in this case, I would definitely consider using one to manage project and client metadata. A good database will provide more functionality than a folder structure can.
I was mostly trying to understand if 1) the reasoning of section 13 is sound and I’ve misunderstood something, or 2) there is a flaw in the reasoning, and the SYS.AC.ID system is not a good solution for the problem that is described at the outset of section 13. I’m not even a freelancer
I’m just starting to try out the system, so I feel it’s a bit too early to stray away from it
I’ve been moving our own stuff over all day today. There’s a bit here, I’ll blog about it shortly as an interim document. I think we’ll want to run this ourselves for a little while to iron out any kinks before I make it official.
(Copying this text from this post as it’s very relevant here.)
I’m just playing with this myself in the context of the ‘creative’ or ‘freelancer’ pattern that’s mentioned in these same threads.
What seems to work is a strategy where you expand the ‘middle’ of your system. So if you’ve usually got:
Areas | Categories | IDs
10x | 10x per | 100x per
…what I think is good is to keep that first level, areas. Don’t mess with them: stick to 10, stick with the naming scheme.
But then categories is where it falls apart. Now we’re talking customers or projects or jobs or whatever, and you need more than 10. So in the scheme I’m trying out, here’s what I’ve got.
that create so much confusion, sorry about that
