#readwise # P.A.R.A. II: Operations Manual – Praxis This article is part of a two-part series. The first article is [[The PARA Method A Universal System for Organizing Digital Information - Forte Labs]].  ## Metadata - Author: [[Tiago Forte]] - Full Title: P.A.R.A. II: Operations Manual – Praxis - URL: https://fortelabs.co/blog/p-a-r-a-ii-operations-manual/ ## Highlights One commenter wanted to know why I put projects and areas in completely different buckets, asking, “What do you put in areas notebooks, if not the projects that make them up?” There is a subtle architectural question here: **why not use Areas of Responsibility as the top level of your hierarchy, and then drill down into each one to find the projects within them? I have 3 reasons not to take this approach**: --- 1) The first reason, as I discussed in the previous post, is **the importance of separating the very small amount of actionable information from the much larger amount of non-actionable information**. You might have a huge quantity of notes and files on a broad area like “Product Development,” whereas only the tiny minority related to “Product X Launch” might actually be relevant and actionable now. **It doesn’t make sense to have to drill down through a bunch of non-actionable information in order to find the actionable stuff.** --- 2) The second reason is **visual clutter**. Using areas as the top level of the hierarchy means that, even if I collapsed all the stacks, I would still be faced with 22 notebooks. This means 22 starting points to find whatever I’m looking for (below left). Compare this with the simplicity of only 4 top-level categories (below right), each of which can be expanded or hidden as needed. --- 3) **Third, in order to achieve the goal of rapid project turnover, it is important that projects be stored all in one place.** Just like if you want tasks to be completed quickly, you should keep them on a centralized task manager or to do list. Imagine the tediousness of having to drill down into 22 separate area notebooks in order to review all my projects, and multiply that effort by the 5–6 platforms I use. --- What I’ve noticed is that, somewhat oddly, **it’s not that important to associate projects very directly with areas. Because your projects are what you engage with on a daily basis, it’s unlikely you’ll forget what areas/categories they fall into. Whereas it is easy to lose sight of a project’s goal in the midst of daily activity. Thus it’s much more important, in my opinion, to associate projects with their respective goals, rather than areas.** --- **The key here is to keep in mind that areas are Areas of Responsibility. There is a very clear line between things that you are responsible for, and those that you’re merely interested in. Areas of Responsibility are the roles you take on in life and the hats you wear** (Spouse, Mother/Father, Team Leader, Soccer Coach), **the ongoing standards where the buck stops with you** (Product Development, Company Newsletter, Legal), **and things that take a certain amount of constant attention** (Exercise, Finances, Apartment, Pets). **Resources are interests** (web design, crowdfunding, woodworking, frisbee golf, bio-hacking), themes (psychology, politics, leadership, integrity), **and assets** (stock photos, typography links, marketing swipe file, product testimonials, code snippets). I even use lower-case titles with resource notebooks, to remind myself that they are just interests, and capital letters for areas of responsibility. ^0bsm3j --- There is another useful guideline here: **put personally relevant information in Areas, and generally useful information in Resources.** ^tu8eqd ---