PARA
Abstract
The PARA (Project Areas Resources Archives) method is a way to organize digital notes. It resolved around 4 main folders:
- projects: series of tasks linked to a goal with a deadline
- write blog post, finalize product spec
- areas: sphere of activity with a standard to be maintained over time
- health, finance, professional development
- resources: topic or theme of ongoing interest
- habit formation, project management
- archives: inactive items from the other 3 categories
- projects that have been completed or become inactive
It differs from the Map of Content as the latter is using the index based method.
Imagine for a moment the perfect organizational system. One that supported and enhanced the work you do, telling you exactly where to put a piece of information, and exactly where to find it when you needed it.
This system would have to be:
- universal, encompassing any conceivable kind of information from any source
- flexible, able to work with any project or activity you take on, now and in the future
- simple, not requiring any time-consuming maintenance, cataloguing, tagging, or reorganizing beyond a bare minimum
- actionable, integrating seamlessly with task management and project management methods
- cross-platform, able to be used with any application, now existing or yet to be developed
- outcome-oriented, structuring information in a way that supports the delivery of valuable work
- modular, allowing different levels of detail to be hidden or revealed, depending on the needs of the current task
- opportunistic, in the good sense, taking advantage of work already being performed, instead of requiring dedicated overhead time
I believe I’ve developed a system for organizing digital information that meets all these requirements. After several years of introducing it to a wide variety of people, I’m confident that it works. In this post I will attempt to show you how.
P.A.R.A. stands for Projects — Areas — Resources — Archives, the four top-level categories that encompass every type of information you might encounter in your work and life.
Let’s start with definitions. These are very precisely formulated:
A project is “a series of tasks linked to a goal, with a deadline.”
Examples include: Complete app mockup; Develop project plan; Execute business development campaign; Write blog post; Finalize product specifications; Attend conference
An area of responsibility is “a sphere of activity with a standard to be maintained over time.”
Examples include: Health; Finances, Professional Development; Travel; Hobbies; Friends; Apartment; Car; Productivity; Direct reports; Product Development; Writing
A resource is “a topic or theme of ongoing interest.”
Examples include: habit formation; project management; transhumanism; coffee; music; gardening; online marketing; SEO; interior design; architecture; note-taking
Archives include “inactive items from the other three categories.”
Examples include: projects that have been completed or become inactive; areas that you are no longer committed to maintaining; resources that you are no longer interested in
Let’s move to a visual metaphor:
We spend our days completing tasks, which are grouped naturally into projects, which fall under areas of responsibility.
For example, you might find yourself writing the first draft of a blog post, which is linked to the project “product X launch,” which falls under an area of responsibility called “Product Development.” This might be just one of several spheres of activity you are responsible for in your job, along with “Business Strategy,” “Hiring/Staffing,” and “Financial Reporting.” In your personal life, you have still more areas, such as “Parenting,” “Hobbies,” and “Apartment.”
Projects vs. Areas of Responsibility
These definitions seem fairly straightforward, but I want to zero in on the difference between projects and areas of responsibility. After much trial and error, and seeing many people struggle to differentiate between them, I’ve come to believe that even the smallest confusion between these two categories is a deeply rooted cause of many personal productivity problems.
Let’s break down the definitions for these two categories into two parts each:
A project has a goal to be achieved — a discrete event that will happen, allowing this item to be completely checked off and struck from the list. And this goal is supposed to take place by a specific moment in time. It has a deadline or timeframe, whether externally or self-imposed.
An area of responsibility, by contrast, has a standard to be maintained. And there is no end date or final outcome. Your performance in this area may wax and wane over time, but the standard continues indefinitely and requires a certain level of attention at all times.
Projects always fall into Areas. A few examples:
- Running a marathon is a project, whereas Health is an area
- Publishing a book is a project, whereas Writing is an area
- Saving 3 months’ worth of expenses is a project, whereas Finances is an area
- A vacation to Thailand is a project, whereas Travel is an area
- Planning an anniversary dinner is a project, whereas Spouse is an area
In all these examples, the projects have completion dates. They are either complete or incomplete. The areas of responsibility, on the other hand, have standards of performance that must be maintained indefinitely.
Making Lists
Now that we’ve laid the groundwork, let me show you how even subtle confusion between these two categories can cause so many problems.
When working with a client as a productivity coach, one of the first things I will ask them is to show me their Project List. I need this to get a sense of what kind of work they do, their current workload, and what outcomes they are actively working toward.
They usually hand me something that looks like this:
Do you see the problem? Not a single item on this list is a project. Do “vacations” ever end? Is there ever a time when you can cross off “productivity” from your list once and for all? No — these are ongoing areas of responsibility, not projects.
So what? This is just semantics, right?
I don’t think so. There are three absolutely critical things you cannot do unless you break out your areas of responsibility into clearly articulated projects.
The first is that you can’t truly know the extent of your commitments:
Quite often I’m asked questions that fall under the category “capacity/utilization”:
- How do I know if I should reduce my workload, or increase it?
- How do I know how many projects I should have going at any given time?
- What is the right mix of short-term to long-term projects (or research vs. production, or planning vs. execution, or analysis vs. synthesis, or any other dichotomy)?
But I cannot even begin to answer these questions for a specific person until I have a sense of their current workload and project mix.
Look at the list on the left in the above image — does “hiring/staffing” give you any sense whatsoever of this person’s workload or commitments? Nope. That could encompass a few minutes a week, all the way to a full-time job, and anything in between. It is a black box, giving me no information.
Now look at the list of corresponding projects on the right — doesn’t that give you a much better sense of this person’s workload, and even the nature of the projects they are engaged in?
You cannot know what to change until you know what you’re committed to. And what you’re committed to is not a collection of vague responsibilities, but a short list of tangible outcomes. In other words, projects.
Second, you can’t connect your current efforts to your long-term goals:
I often say that with knowledge workers, the biggest bottleneck is always getting up in the morning. Knowledge work requires not only our time and effort, but also our engagement and creativity. For that reason, personal motivation is the prime problem that supersedes all other problems.
Now, imagine the psychological effect of waking up to the list on the left day after day, week after week, month after month, even year after year. Areas of Responsibility rarely if ever change, remember? No matter how hard you work, how many years of service you put in, the list of never-changing obligations only gets heavier and longer.
I couldn’t design a better method of killing personal motivation if I tried.
By breaking these responsibilities into bite-sized projects (as in the list on the right), you ensure that your Project List will change nearly every week. This creates a rhythm and a momentum of project completion to maintain your motivation. It generates the constant novelty that the latest research suggests is essential for satisfaction.
And you can always break down your responsibilities into smaller projects. Even for research that might take years to produce a new product (as in the example above), there is a clear succession of experiments leading to outcomes, even if they are just “hypothesis confirmed” or “results obtained.” Remember that there is no inherent structure or unit of work. You don’t have to accept your manager’s, teams, or organization’s definitions of what a project is!
Third, you can’t know if you’re making progress toward your goals:
Have you ever had the experience of preparing for your annual performance review, and not being able to think of what you accomplished in the past year? This is demoralizing, and puts you in the exact wrong mindset to walk into your manager’s office and proudly name your accomplishments. Not to mention negotiate for a promotion or pay raise.
Now imagine if you broke down this “events” area into each individual event that you planned and executed. Not only would this show the clear progression and growth you’ve experienced, each event building on the one before, it would also conveniently provide you with a catalog of outcomes you’ve reached to include in your performance review at year’s end. And you’d have much more than a list — you’d have separate folders for each completed project, with tangible notes, assets, and learnings you’ve produced for each.
One final note on projects vs. areas: they require completely different ways of thinking, approaches, tools, and methods. Projects require you to be laser-focused, to ruthlessly drive toward an outcome, to smash through or circumvent obstacles, to ignore distractions (i.e. people). Areas, on the other hand, require mindfulness, balance, flow, and human connection. This is the realm of habits, routines, rituals, and intentional communities. Areas require introspection and self-awareness, because determining whether or not you are meeting your standard is an intuitive exercise, not an analytical one.
You can easily see how failing to make this distinction leads to common frustrations: if you have a project that you think is an area (for example, the book I’ve been “writing” for a couple years now, that feels like a never-ending part of my life), it will tend to continue indefinitely. If you have an area that you think is a project (for example, a health outcome like “losing X pounds”), you’ll revert right back after it’s been achieved, because you didn’t put in place any mechanism for maintaining the standard.
There is a very illuminating exercise you can perform once you’ve taken the time to formulate a clear Project List. Put it side by side with your Goal List, and draw lines matching each project with its corresponding goal:
What most people find is that they don’t completely match. This is problematic because a project without a corresponding goal is known as a “hobby.” If you’re not committed to or haven’t fully articulated the outcome you want, you must be doing it just for fun.
And if you have a goal without a corresponding project, that’s called a “dream.” You may desire it with all your heart and soul, but without an active project, you are not in fact currently making any progress.
Now there’s nothing wrong with hobbies and dreams. They give life meaning and purpose. But please don’t confuse them with projects and goals. To be clear about what you’re making progress on, you must be clear about what you’re not. To feel comfortable saying no to what isn’t important, you must be crystal clear on what is.
Start by defining your project list
The bottom line here is, define your projects, or they will define you. You’ll be constantly pulled and pushed into the projects of others, and find that even when others offer to help you with yours, you won’t even know what they are.
What this means concretely is that you should define your projects apart from any particular program or tool. Write them down on a piece of paper or in a blank document, away from the hints, incentives, constraints, and assumptions of any software program.
What this allows you to do is extend and manifest these projects across any program you choose:
The exact same project list is replicated across every program
Here’s why this is important: you will always need to use multiple programs to complete projects. You may use a centralized platform like Basecamp, Asana, Jira, or Zoho, but technology is advancing too quickly on too many fronts for any one company to do every single function best.
Instead of fighting the tide and looking for “one platform to rule them all,” formulate your Project List and then replicate that list across every single tool you use, now and in the future. I recommend doing so down to the exact same spelling, punctuation, and capitalization, so that your transitions between programs are as seamless as possible.
I’ve noticed that people tend to use different organizational schemes in every program they use. They try to adapt a different scheme to the capabilities of each program, forcing their brains to “load up” and remember a different one every time they switch programs. This creates a friction to learning new tools that might be better suited to specialized tasks, inhibiting innovation.
In the example above, the list of projects is identical in every program, and could be further extended to any number of other programs. This leverages the unique capabilities of each program, while keeping the project layer unified across interfaces.
P.A.R.A. gives you the best of both worlds: the consistency of centralization, with the adaptability of decentralization.
It operates according to three core principles:
The first principle is that it uses the number 4 as a guidepost. The entire hierarchy is four categories wide (projects, areas, resources, archives), and no more than four levels deep (using Evernote as an example, the levels would be: application > stacks > notebooks > notes).
The number four has been called “magic” due to research indicating it seems to be the natural limit of all sorts of cognitive processes, from working memory to object-tracking to rapid enumeration. In more speculative findings, some primitive tribes seem to have specific words only up to the number four, and many animals seem to be able to distinguish up to four individual objects.
Whether or not it’s a real limit, it is a useful constraint to prevent the two primary sins of organizational overengineering: too many categories, and too many levels of hierarchy.
The second principle is that P.A.R.A. perfectly mirrors your task management and project management systems. The relatively young field of personal knowledge management (PKM) has a lot to say on the topic, but I believe that any PKM approach that doesn’t tie into execution tools is destined to languish on the back burner forever.
All four top-level categories are replicated across programs
The third principle is that P.A.R.A. preserves and actually enhances the most important distinction that any productivity system must make: between actionable and non-actionable information. Making this distinction allows you to set aside 95% of the information coming your way, to focus on the 5% necessary for the task at hand.
How does it enhance actionability? By recognizing that actionability is not black or white. It is instead a gradient, a spectrum that should be hidden or revealed depending on the context. This follows a well-known design technique called progressive disclosure — only show the user as much information as they need in the moment. This helps minimize the cognitive load that knowledge workers must always contend with.
Day to day, in the trenches of getting things done, you might focus on the first column, looking at material related only to the active projects. This would probably include your task manager (or at least the “Today” or “Next” section of your task manager) as well as the “Projects” stack in a note-taking program like Evernote:
On a wider horizon, for example, while doing a weekly review, you would expand the scope of information you’re considering to include Areas of Responsibility. This is a deeper level of introspection: are you currently meeting the standard you’ve set for yourself in each of the areas you’re committed to? If not, are there any new projects, habits, routines, rituals, or other practices you’d like to start, stop, or change?
On an even wider horizon, perhaps during a monthly review, you could expand the scope of what you’re looking at to include Resources. Are there any new interests you’d like to pursue more seriously? Are there any you’ve allowed to stagnate, that you’d like to reboot? Do any of your current projects give you an excuse to also pursue a related interest?
The Resources stack is also where “research” lives. The notebooks here tend to have the most objectively valuable information, which you may want to access when looking for material to use in a blog post, to recommend to someone, or for a work project. My own collection, below, gives a pretty good indication of my interests, with the number of notes to the right of each notebook title showing how many notes I’ve collected on the topic:
And finally, the Archives are your portfolio of completed projects, each one inactive but ready to offer up potentially useful material to reuse and recycle in future projects. I often find that being able to reuse my notes on a topic, a well-designed slide, a section of a proposal, or other assets saves me tremendous amounts of time, which is especially critical in a freelancing business in which I am doing everything myself. It is also easiest to recall where an asset is located based on when it was created and which project it was associated with, if search doesn’t do the job:
Besides reusing project materials, the Archives can also be used for project retrospectives, annual retrospectives, and resumes and proposals where you need to “show your work.”