PARA Part 2 Operations Manual

rw-book-cover

Metadata

Highlights

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? (View Highlight)

Projects are not a subset of Areas!

  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. (View Highlight)

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. (View Highlight)

There is a very clear line between things that you are responsible for, and those that you’re merely interested in. (View Highlight)

On Areas vs Resources

I even use lower-case titles with resource notebooks, to remind myself that they are just interests, and capital letters for areas of responsibility. (View Highlight)

This seems excessive

put personally relevant information in Areas, and generally useful information in Resources (View Highlight)

When you finish a project, before moving it to Archives, it’s a good idea to scan it quickly for any such material that might be useful for future projects (View Highlight)

I would suggest performing organizational work opportunistically, as opportunities arise, instead of pedantically, or “just because.” I call this approach Just-In-Time Organization. What this looks like is making changes to your organizational structure in small batches, as you go along and happen to notice incremental improvements, not in big batches as part of a dedicated effort. (View Highlight)

it represents time-consuming overhead work with no clear return or impact. You don’t have time during a project to “stop and organize things,” because you need every spare minute to race toward the deadline. But you also can’t do it after the project is over, because it’s off to the next one. There is no line item in your department’s budget for “getting organized.” Thus this overhead work gets postponed again and again, until it reaches a breaking point where all systems start breaking down. (View Highlight)

Oh hey it’s tech debt

If I had only “Work” and “Personal,” it would be difficult for me to identify where I was falling short and what changes I should make. But having my life broken out into 22 areas allows me to evaluate them more objectively. If I decide I’d like to raise the standard in a given area, it’s then easy to create a new project targeting it very directly. (View Highlight)

Two things:

  1. Be specific about your projects
  2. If you feel like you’re falling behind in an area, create a project for it
    (Projects are meant to be short term)