Hi everyone,
By chance, I came across a reference to JD after spending a couple of weeks mulling over how to reorganize files for my business, and I can see the potential. I’ve also started to think about adopting it for personal file organization. I think I’ve read all relevant posts on the forum and the website itself carefully, but please feel free to tell me to RTFM if this is documented somewhere! A few rookie questions have come up:
What are your thoughts on using the framework for both personal AND work life (where work happens in a company)?
Areas and categories would be very different for one and the other, and I’m concerned about the cognitive friction it will cause to the numbering scheme.
To add to the complication, most of our work (for example, construction management, to name one area) involves elaborate projects that take multiple years to complete. This would require a PRO.AC.ID setup for the business side of things.
The last layer of complication I foresee is my wife adopting this system personally if I do so and if we also adopt it for work (we work together). This would mean multiple setups with disparate areas and categories.
Has anyone encountered a similar (multi-setup) scenario? Will it make the system very inconvenient?
- Personal
For personal file management I’ve been using PARA for a couple of years, so I’m thinking I’d adopt JD keeping some elements from PARA (at least a separate Projects area). I’d have categories such as family, financial, hobbies, medical, possessions, etc., which I think are somewhat standard. I’ve been thinking I’d like to make a couple of major interests into categories (e.g. Emacs), because I can already see that I’ll need a deeper folder structure.
I’m quite sure I’ll need to have additional folder hierarchy depth for some aspects of life, such as photographs, which I currently sort in a “YYYY/YYYY-MM/YYYY-MM-DD-description” hierarchy (though I’m always on the lookout for ways to improve that system); repos I clone (I might want to have a local copy of someone’s Emacs dotfiles, for example); websites and other projects that require an organizational hierarchy to function.
- Business
2.a. I like to use two sub-folders inside many of our folders: “superseded” and “archived.” I’ve thought about going only with one or the other, but there are some things that are no longer relevant because we have a new version of them, and others that are no longer relevant because they apply to a stage of the process that has been finalized but which we still want to have at hand if we need the reference.
2.b. Although most projects share some structure with each other (all have contracts and drawings for example), they are also not identical. Some projects have a Project Development category and others do not. Some have a design component and others do not, some have a QS (cost control) component, others don’t. To add to the complexity, we currently have two business units and some projects are completely disparate and involve actual contracting work, which will require some different categories. I’m afraid to place a lot of this into areas because then we will definitely need to have more folder depth.
2.c. How to deal efficiently with directory permissions? Not everyone needs access to all files. Some of this is easy to separate, so proposals, invoicing, etc. can be placed on the main JD system, but other aspects might require some separation depending on the complexity of the project (for example, we might want to separate access to structural work and QS work).
2.d. Whatever we choose will need to be clearly documented and turned into SOP’s. Some of the people are hired on a project basis while others are part of the core team. Therefore, the system must make sense and not cause too much friction for the core team when transitioning from project to project (or even while working on up to 5 projects at once, as might be the case for the project director), and at the same time must be simple enough to understand for new hires.
2.e. Project names are currently four characters long, and we try to make them easily identifiable. So, if the project name was “Tomato Mall,” we might call it “tmto.” We’ve been thinking of changing this to include the location, so that if we work on more than one project with the same name, we can identify them easily, in which case we would use two characters for the project name and two to designate the area. The idea of a letter followed by two numbers is appealing because it looks short and neat, but it would be more difficult to remember. We don’t have too many concurrent projects for now, but we do want to quickly remember something we did 10 years ago. My feeling is it would be easier to remember “tmto” than “t32.” Has anybody else thought about this? What did you conclude? How has it worked out?
Sorry for the long and somewhat disorganized post. I’m looking forward to your thoughts on the issues outlined above. I’m sure there will be more questions if we take the plunge, but the idea for now is to get to the point where we feel comfortable to test on one project and then slowly roll-out to other projects. I’ll be happy to document the process and share with all of you as we move forward.
Thank you for your feedback!
