PARA

Table of Contents

1. PARA

1.1. https://fortelabs.co/blog/series/para/

1.1.1. https://fortelabs.co/blog/para/

1.1.1.1. the perfect organizational system 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, str.ctu.ing information in a way that supports the delivery of valuable work
  • modular, all.win. different l.vels 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
1.1.1.2. P.A.R.A stands for Projects-Areas-Resources-Archives
  1. Project

    A series of tasks linked to a concrete goal, with a deadline which can be either
    a specific date or a checking point

  2. Area of responsibility

    A sphere of activity with a standard to be maintained over time (indefinitely)
    requiring a certain level of attention at all times

  3. Resource

    A topic or theme of ongoing interest

  4. Archives

    Inactive items from the other three categories

1.1.1.3. Break areas into small projects
  1. You can’t truly know the extent of your commitments
    1. 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.
  2. You can’t connect your current efforts to your long-term goals
    1. Knowledge work requires not only our time and effort, but also our engagement and creativity, personal motivation is the bottleneck (prime problem that supersedes all other problems.)
    2. Considering projects all your areas leads to accumulation of tasks, which leads to psychological overwhelming (a never-ending list of commitments than never go away, taking into account low level and high level details at all times) ⇒
    3. By breaking these responsibilities into bite-sized projects 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. 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.
    4. 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!
  3. You can’t know if you’re making progress toward your goals
1.1.1.4. Projects vs Areas
  • 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.

Projects and Goals

  • Projects ~ Extroverted, analytical
  • Areas ~ Introverted, intuitive
1.1.1.5. Hobby

A project without a corresponding goal
If you’re not committed to or haven’t fully articulated the outcome you want, you must be doing it just for fun.

1.1.1.6. Dream

A goal without a corresponding project

1.1.1.7. Standarize your organizational scheme

across all apps, use the same structure
Instead of fighting the tide and looking for “one platform to rule them all” ⇒ «unless you are a programmer» ;)
P.A.R.A. gives you the best of both worlds: the consistency of centralization, with the adaptability of decentralization.

1.1.1.8. Two primary sins of organizational overengineering

too many categories, and too many levels of hierarchy.

1.1.1.9. Principles of PARA
  • 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 → «too far fetched, and flexible trees bypass the shortcomings of another apps regarding many levels of indentation» “It’s not levels of indentation, and I think some kind of limit is necessary”
  • The second principle is that P.A.R.A. perfectly mirrors your task management and project management systems. (?)
  • 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.

1.1.2. https://fortelabs.co/blog/p-a-r-a-ii-operations-manual/

1.1.2.1. 1. Definitions and distinctions
  1. Project vs areas
    1. 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?
      1. separating the very small amount of actionable information from the much larger amount of non-actionable information
      2. visual and mental clutter (only 4 categories at the beggining, not the number of areas which may be ~20,30)

      -—
      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.

  2. Areas vs Resources
    1. Areas
    2. Resources
  3. Resources vs Archives

    Ongoing interest separates archive vs resources

1.1.2.2. 2. Flows and upkeep

All possible transitions between states. PARA is a dynamic system, not static,
and hierarchy is not rigid and replaced by evolving flows of information between
them More actionable is more likely to get archived

  1. From Projects
    1. to Areas

      Sometimes what starts as a limited-time project becomes a long-term, ongoing responsibility.

    2. to Resources

      During the course of a project, it is common to generate all sorts of
      “intermediate work” (brainstorms, notes, background research, diagrams,
      interview notes, etc.) that has value, but may or may not make it into the final
      product. 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. In my experience, this only applies to a small amount of the material
      for any given project, but the value it creates in the future is immense.

    3. to Archives

      After a project has been finished, one of the most common transitions

  2. From Areas
    1. to Projects

      It is common to start a new project, and realize there is something you’ve been
      collecting for a long time that is potentially useful to the new project. Maybe
      you’ve been collecting ideas in a Travel (area) (more abstract) notebook for
      awhile – when the time comes to plan and schedule a specific trip (a project),
      this is a great place to start.

    2. to Resources

      Sometimes you realize a note you thought was only relevant to you can also provide value to others.

    3. to Archive

      Although it is rare, sometimes an area ceases to be active, and can be archived.

  3. From Resources
    1. to Projects

      Often, what was previously just an interest catches fire and becomes a
      full-blown project. This is one of the primary use cases for resource notebooks
      actually.

    2. to Areas

      This flow would occur if you realized a piece of information in a resource
      notebook could apply to an area of responsibility in your life.

    3. to Archive

      It’s natural to expect some interests to go dormant over time. You don’t want to
      delete the information associated with it, because you never know when it could
      become active again.

  4. From Archive
    1. to Projects

      This use case is one of the primary reasons to keep archived projects in the
      first place. It makes sense that there would be useful information from past
      projects you could use in current and future projects.

    2. to Areas

      Similarly, a piece of information you collected long ago can suddenly become
      relevant for a new responsibility you’re taking on.

    3. to Resources

      I find it quite common for a past project, now archived, to keep simmering in
      the back of my mind, and later become an interest.

1.1.2.3. Just-in-time organization

Perform organizational work opportunistically, as opportunities arise, instead of pedantically, or “just because.”, 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.
“organizing things” is one of those nice-to-have things that people never get around to ⇒ it represents time-consuming overhead work with no clear return or impact.
flossing

1.1.2.4. 3. FAQs
  1. Is it necessary to create corresponding notebooks for every project, area, and resource, across every platform, even if I have nothing to put in them yet?
    • No, create them opportunistically
    • When the friction involved in creating a new notebook or folder on the spot will make it less likely for you to capture information at all (e.g. mobile), then create them upfront
  2. Why break out areas so specifically? (Big-few vs many-small areas)

    Many-small ⇒ makes it easier to determine whether you’re meeting your personal standard in a given area

1.1.4. https://fortelabs.co/blog/para-setup-guide/

1.1.4.1. Setup
  1. Move existing files to a new folder called “Archive [date]” (with today’s date)
  2. Create folders for each of your current projects
  3. Move all the project folders into a new folder called “Projects”
  4. Create a new “Archives” folder and move the existing one into it
  5. Create new folders only if and when you need them
1.1.4.2. FAQs
  1. What kinds of things should I save?
    • Is this something that could inspire or help me if it surfaced at some point in the future?
    • Is this potentially a useful source, building block, or tool for future projects?
    • Is this unique, personal, or hard-won knowledge worth revisiting over time?
    • Is this something that I’m unlikely to find in the future when I need it?
    1. List of examples
      • Book notes
      • Excerpts from online articles
      • Quotes
      • Notes from audiobooks or podcasts
      • Screenshots and web bookmarks
      • Voice memos
      • Photos, graphics, and diagrams
      • PDFs
      • Outlines and summaries
      • Notes from conferences or events
      • Interviews or FAQs
      • Templates & checklists
      • Notes from webinars or online courses
      • Brainstorms & mindmaps
      • Slide presentations
      • Notebook sketches
      • Journal or diary entries
      • Marketing/business ideas
      • Email newsletters
      • Travel ideas and plans
      • Notes from classes or workshops
      • Reading list (or Already Read list)
      • Meeting notes and recordings
      • Project planning notes
      • Work samples and portfolio
      • Goals and dreams
      • Productivity/health tips
      • User manuals/guides
      • Writing ideas/prompts

1.1.5. https://fortelabs.co/blog/p-a-r-a-v-the-project-list-mindsweep/

1.1.5.1. 1. Do a brain dump of everything you think could be a project

Here’s some things to consider and places to look:

  1. Your mind
    • What’s worrying you that you haven’t taken the time to identify as a project?
    • What’s taking more mental bandwidth than it deserves?
    • What needs to happen that you’re not making consistent progress on, that could benefit from a project structure?
  2. Calendar
    • Look a few weeks into the past: what do you need to follow up on?
    • What needs wrapping up?
    • What projects do you want to create out of events that already happened?
    • Look a few weeks into the future: what needs planning and preparation?
    • What requires some goal-setting?
    • Who do you need to catch up with?
  3. To Do list
    • What actions are you already taking, that are actually part of a bigger project you’ve not yet identified?
  4. Agendas
    • What communication or followup actions you’ve scheduled with people are actually part of a bigger project?
  5. Briefcase/bag/wallet/purse
    • What objects or papers have you saved because they remind you to take an action?
    • What have you not gotten rid of because it’s needed for a project?
  6. Physical environment

    Look around your office, home, car, or desk:

    • what physical objects represent projects you haven’t identified as projects?
  7. Computer

    Look at your computer desktop, downloads folder, documents folder, bookmarks, emails, open browser tabs:

    • what are you keeping around because it is part of a project?
  8. Processes or procedures
    • Which processes in your work or life could be more efficient, streamlined, or purposeful?
    • What do you do regularly that takes too long, is too difficult, or hasn’t been thought through?
  9. Creative opportunities
    • What would you like to learn, develop, build, put on, pursue, start, explore, or play with as a project?
  10. Competence building
    • Which skills would you like to learn?
    • Which hobbies would you like to start?
    • What kind of project could advance your career, or make your life more fun or interesting?
1.1.5.2. 2. Organize and refine your list
  1. Delete anything that is obviously not a project

    Sometimes you just need to write something down to realize it’s not something you’re committed to.

  2. Combine projects that are tied to the same outcome

    “Wipe old computer” and “Research new computers” could be part of the same project “Buy new computer.”

  3. If a project can be substituted by a calendar entry, add it to your calendar instead

    For example, “Pick up sister from airport” doesn’t really need to be actively tracked over time. Seeing it on the appropriate day will trigger all the necessary actions.

  4. Move “someday/maybe” projects to the bottom of the list

    Keep track of these future projects, but don’t let them clutter your current list.

1.1.5.3. 3. Define the desired outcome of each project
  • Add a date (specific deadline, endpoint, or checkin point)
  • Use action verbs
1.1.5.4. 4. Prioritize your list by project

Most people prioritize their work at the level of individual tasks. Projects move much more slowly, and don’t change their priority even if there’s an emergency. It’s worth spending the time to clearly identify which projects are the top priority, because that is unlikely to change much during the course of a week.
Rearrange your Project List from most to least important for the current week.

1.1.5.5. 5. Evaluate your Project List
  • Does this include all the outcomes you’re committed to?
  • Look over the whole list from a bird’s eye view: does it accurately represent your current priorities, interests, values, and long-term goals?
  • In which area do you have too many projects?
  • Not enough?
  • Which outcomes or goals you say are important to you don’t have any projects targeted at them?
  • Where are you spending time or attention that has no clear outcome or goal?

For any that are simply unclear, take a step back and ask

  • “What am I really trying to accomplish here?” or
  • What bigger goal is this connected to?”
  • With this whole inventory in front of you, which projects should you cancel, postpone, renegotiate, or clarify?

1.1.6. https://fortelabs.co/blog/p-a-r-a-part-vi-small-batch-projects-for-focus-creativity-and-perspective/

1.1.6.1. Small-batch projects
  1. 1) A tightly scoped, short-term commitment

    Inputs and outputs (projects) have to be small, discrete notes, otherwise the
    system gets clogged up and stagnant

    1. Change in the concept of project

      «Maybe this is not very applicable to my current job»

      1. Hollywood Model
      2. With project-based work, remote teams of contractors wait until the last possible moment to jump onto a project

        flossing»), and once they do, they optimize for speed and intensity.
        This requires shedding as much of the decision-making, consensus-seeking, approval-seeking, and status-updating as possible.
        It requires reducing the project down to the minimum essential core of productive activity.

      3. Partial adoption doesn’t work

        Doing the same old projects with outsourced contractors instead of full-time employees.
        Chopping up our typical projects into tiny pieces.
        Doing so without a corresponding change in mindset and methods just creates massive amounts of extra overhead work.
        «Same as How to Take Smart Notes with sailors not accepting the container, not fully committing to it, there will be weird elements standarize»

      4. The modern concept of a “project” was born in large, traditional companies

        everything is designed for efficiency and scale. The primary threats are internal: bureaucracy, politics, cost-cutting, deprioritization, and competition for resources.
        To survive this environment, projects became large, bloated, meticulously planned, long-running, with vague objectives.
        All the things we hate about modern mega-projects are actually features they adapted to survive the endless path through the bureaucracy.

      5. But put this fattened cow in the jungle of the digital economy, and it’ll get slaughtered.

        A “project” in the new economy has evolved to become a lean, agile tiger: small, adaptable, omnivorous, willing to hunt but preferring to watch for opportunities.

      6. Thus making our projects smaller is not a question of marginal improvement. It determines whether our projects survive

        Whether they become good ideas that never quite see the light of day, or impactful results delivered in a steady rhythm.

  2. 2) Clear desired outcomes that describe end states
    • This is to avoid the biggest risk one faces as a contract – a half-dead zombie project that staggers on for months with no clear resolution is a far

    bigger risk than the project outright failing, which
    robs them of both the opportunity cost of pursuing other projects, and the learnings that would have come from clear success or failure.
    There’s a good reason most people are tremendously resistant to writing out clear success criteria, even for their personal projects:

    • You become much more accountable for their progress.
      Instead of reporting that you’re “still pluggin’ away at Mega-Project X” for the 20th week in a row, you have to explain why “write outline” is still on your list after a whole week.
      What you’re doing, in Toyota terms, is lowering the water level on your work commitments. This exposes the excuses, the procrastination, the vagueness, the miscommunication, the lack of responsibility.
    • You will only consider doing this if you value learning at the expense of comfort.
      • This takes courage, humility, and openness to hearing feedback.
        If you really want accountability, make a Project List exactly as I’ve recommended, and then show it to everyone who will listen.
        Show it to your boss, to your clients, to your direct reports, to your spouse.
        You’ll either gain trust as people learn they can take you at your word, or you’ll hear very quickly what isn’t working.
        «Razonamiento omnivalente»
  3. 3) A deadline or delivery date (which becomes a review date when passed)   process

    Defining a desired outcome is only meaningful if you also decide “by when.”
    It’s too easy to declare ambitious goals with a forecast of “someday.”
    In a large company, putting yourself on the hook for a delivery date for a project you don’t completely control is crazy. Much better to keep everything hazy, so blame for delays can be passed around and diffused.
    !Survival in a large company depends far more on avoiding blame than producing results.!
    But as we move to an economy of more-or-less free agents, accountability is devolving to the individual. No longer do you have a boss, manager, or colleagues to look over your shoulder and make sure you’re on track.
    No one cares if you had a productive day.
    As implicit accountability fades away, you now have to replace it with explicit accountability.
    You have to put yourself on the hook for something. This starts with being honest with yourself about what you’ve committed to, and by when.

  4. Clean edges   process
    1. enable focus

      Organize by horizons of actionability, not by topic ⇒ allow yourself to focus
      your aone horizon at a time. Having very clean edges between the
      stacksnot using precious attention to figure out that boundary on
      the flally, the smaller your projects and the cleaner the edges
      betweelarger the amount of information you can manage on all
      horizoonly focus on something that is distinct from its
      surrouverything is potentially actionable at any given time, of
      courserience information overload.

    2. enable creativity

      There y of networks that is essential for new ideas to take root and
      thrivehe “small worlds” property. Instead of a perfectly even,
      denselcted global network (as in the leftmost image below), it is
      much hhave small “neighborhoods” that are distinct and separate from
      the wi(as in the rightmost image below):
      1*fn2N_BKhAJ5fdjUBRN3Idg.jpeg?w=900&ssl=1
      *The cf your organizational system can increase the likelihood that
      your rt original, and most subtle ideas are protected and incubated
      to mat

    3. enable perspective

      When you start scoping your projects smaller ⇒ you have many more of them, and
      they come and go much more quickly. At first this might seem like a step
      backward in your productivity. You’ll be spending more time creating, titling,
      prioritizing, scheduling, and archiving projects. !⇒! I’ve come to understand
      that this is exactly the point. Increasing project turnover is an explicit goal
      of adopting small batches. Think about the practice of performing a Weekly
      Review. We all know we should do it. We all know we would benefit from it. But
      most people don’t do it regularly. The truth is, unless you have small-batch
      projects, there’s no need. The answer to “What will I be working on this week?”
      is the same answer as last week.
      Rapid project turnover creates the need to
      review these projects on a more regular basis. This trains you in a higher level
      skill: project portfolio management. You become less attached to the success of
      any particular project because you have plenty Gregory Berns - Satisfaction: The
      Science of Finding True Fulfillment → I have come to understand
      as the one thing that we all want

      Lying at the nexus of commitment, motivation, fulfillment, curiosity, pain, and
      pleasure, novelty seems to be what our brains are wired for. But seeking novelty
      can sometimes feel at odds with productivity. We are encouraged by habit
      formation experts to lock down our environment and remove all uncertainty, to
      avoid taxing our willpower. Small-batch projects promote a different set of
      habits that benefit from novelty, instead of being threatened by it. These are
      habits more expansive and powerful than your daily routine: constantly moving
      into zones of greater leverage; transferring momentum from one project to
      another; designing projects so they are more than the sum of their parts; timing
      projects to take advantage of external events. These are the dark arts of
      productivity. “Dark” only because so few have access to the project throughput
      required to practice them. «In How to Take Smart Notes, not to be threatened by novelty» The
      ability to accelerate project turnover simply by reducing the size of projects
      gives you the ability to produce novelty on demand, for even the most boring
      administrative tasks. If I encounter a project I’m resistant to, I simply keep
      making it smaller until the reward feels more tangible than the pain. This gives
      me control of the drumbeat of fulfilled deadlines, which I tune to maximize my
      sense of self-efficacy.

1.1.7. https://fortelabs.co/blog/p-a-r-a-part-vii-creating-a-project-network/

1.1.7.1. The Values-First Era told us that character was the most important thing.

If you were a virtuous person, living according to principles and high ideals, you’d be successful.

1.1.7.2. The Goals-First Era came next, proclaiming that we should have clear goals to help focus our efforts.

No one was going to give us a handout, so we had to ruthlessly drive toward the outcomes we wanted to happen.
As the new millennium began and the uncertainty in the world spun seemingly out of control, we started looking for a process to follow.

1.1.7.3. Process-First Era. promise results if you’ll only follow the process, obsession with habits

People march under the banner of their favorite process: Theory of Constraints, Six Sigma, Design Thinking, Agile/Scrum, Getting Things Done, Lean Startup, Habit Loop.
Every aspect of modern work is being systematically distilled down to 5 steps that promise results if you’ll only follow the process
Obsession with Habits → replacing a far-off outcome with a daily action makes it seem far more manageable.
It gives us something immediate to focus on, in the midst of a highly uncertain environment.

1.1.7.4. From prescribing means to describing ends

The most important part of small-batch projects: desired outcomes.
The scope and the deadline (the other two components) are easy to come up with. It is the desired outcome that defines and shapes what the project is and where it takes you.
Traditional projects prescribe means: we will do X, then Y will happen, and then we’ll have Z. In a slow-moving environment, laying out all the steps in advance was both possible and effective.
The more intermediate steps you completed, the higher the chances of success. Following the plan was actually more important than project success, because you could avoid blame if it failed.
Desired ends are just inherently valuable, worthwhile results, not ultimate, final ends, they are not necessarily aligned with the big picture (e.g. shortcuts)
Paradoxically, the faster and sharper we want to turn, the further out we need to project our desired outcomes.
What tightly scoped projects with clear success criteria really do is surface assumptions*. If you have a massive project taking up 80% of your time for the next 6 months, assumptions will only be revealed after the deadline has passed, and management or the client starts taking a hard look at what’s going on. By then, it’s way too late to take corrective action.
Precise outcomes are designed to reveal assumptions as quickly as possible. They are actually hypotheses — designed to be falsified. By making our projects small, we expose their inner workings to scrutiny. By writing falsifiable outcomes, our assumptions about what will happen by when become public records open to questioning.

1.1.7.5. Desired outcomes as hypotheses

The fundamental nature of goals has changed, from forecasting an outcome to formulating a hypothesis that will yield maximum learning.

1.1.7.6. Your projects form a network, with interfaces defined by outcomes

1.1.8. https://fortelabs.co/blog/p-a-r-a-viii-core-principles/

1.1.8.1. Organize by actionability
1.1.8.2. Organize opportunistically
1.1.8.3. Move quickly, touch lightly
1.1.8.4. Controlled randomness
1.1.8.5. Complex systems have to be grown, not made
1.1.8.6. Focus on outcomes
1.1.8.7. Fail gracefully
1.1.8.8. Shallow hierarchies

1.2. P.A.R.A.more - by Dennis Nehrenheim M.Sc.

  • Projects has containers for each of your short-term efforts a.k.a. “projects” (this can be everything from finishing a monthly report at work to buying a dog, renovating the house, or starting an online business)
  • Areas has containers for contemporary life areas (these are domains like health, work, or family, where you have long-term responsibilities and/or want to maintain a certain standard)
  • Resources has containers for each of your topics of interest (this is usually for more long-term reference materials)
  • Archives contains all the rest (this means: inactive stuff like completed, aborted, or on-hold projects, areas that are no longer relevant to your life, or resources you lost interest in)

these spaces and containers are not storage locations. Instead, they represent the current state of the things they contain. While the P.A.R.A. spaces remain the same, the containers incl. their content are in constant flux

1.2.0.1. P.A.R.A.more #1 — Setting WIP Limits

Whenever I run into a situation in which I would exceed my allowances I now have to make a decision:

  1. don’t add the item and discard it or put it on pause, i.e. in the archives (preferred solution)
  2. trade the new item with an existing one i.e. moving a current item to the archives instead

At least, I have found that by applying WIP limits to my P.A.R.A. setup…

  • I increase the project throughput (while before I would collect more projects without making progress on any of them)
  • I am forced to cancel ill-born projects (while before I would keep zombie projects alive)
  • I reduce congestion & bottlenecks (while before I would keep too many never-ending projects)
  • I review my life areas more often (while before I would only add new areas but never retire old ones)
  • I am forced to focus on the essential few (while before I would lose focus by adding too many items)
  • I do more house-keeping of my resources (while before I would accumulate a never-ending pile of new references)

How strict do I need to be about this?
Applying WIP limits requires some discipline at first. Occasionally exceeding your limit for a few days may be OK once you got the hang of it. You may even be able to remove the WIP numbers again because you have internalized them. But personally, I like to have a constant visual reminder so as to not get lost in thought on a busy day.

1.2.0.2. P.A.R.A.more #2 — Splitting the Archives
  • a ❄️ snowflake ❄️ archive for “the postponed”— this contains recently aborted, paused, or completed projects, areas dormant only for a few months, resources I am unsure about, … stuff with a high to medium probability of becoming active again.
  • an 🧊 ice-cube 🧊 archive for “the obsolete”— this includes projects terminated or completed a long time ago (3+ years), areas I had maintained during past employments or my time back at university, resources I completely changed my mind about, … stuff with low to zero probability of every being revived again.
1.2.0.3. P.A.R.A.more #3 — Managing Personal Programs

Program: A temporary extension for handling multi-project endeavours

Even though P.A.R.A. is project-oriented, it really is optimized for the “slow burn” i.e. a portfolio of little side gigs that you run in parallel. So P.A.R.A. helps with managing everything that goes on “on the side”. Everything except the big things in life. You exclude your business or main profession as these warrant developing a custom organizing system version for your specific needs. P.A.R.A. being for “all the rest”. If you work a normal job most of your time will be spent on some very specific domain and for that, you will often want to use very optimized tools, workflows, etc.

If a project is a bundle of related tasks worked on over multiple sessions, a program is a bundle of related projects, areas, and resources you are working on almost exclusively for many work sessions.

  1. The program space is more actionable than your projects, so it should be sorted/located before projects
  2. The program is a new space in P.A.R.A. It’s not a lower-level container within projects or areas: it can house containers from all the other spaces.
  3. Introducing a program deliberately but temporarily breaks P.A.R.A. And that’s actually what we want here

The biggest benefits in leveraging program spaces I see are these:

  1. They focus my thinking Breaking out progrms into a separate bucket facilitates my thinking and increases my efficiency. If areas are warm and projects are hot, programs are the burning fire that you want to contain in a centralized place until the flame is extinguished.
  2. They spark my creativity If you engage on a personal program and keep all the related projects, areas, and resources far apart it is harder for serendipity to arise. You will make a lot less coincidental and unexpected connections when things are not visually placed next to each other.
  3. They allow for synergies Having all stuff related to a program in one place is a perfect opportunity for on-the-fly consolidation. Maybe you identify some accidental duplicates, come across two highly “mergeable” notes, or simply engage in an opportunistic reorganization by moving notes around across notebooks.
  4. One further advantage is that you even can revive archived notebooks from the dead, temporarily and without letting them leak into P.A.R..

Now, I recommend you be !very strict with programs!. Use them on occasion, when a heavy lift effort is required that you know will consume most of your time, energy, and attention for some time. And, more importantly, use them only for a short period of time. Set a clear termination date and once that is reached distribute all containers back to where they need to go.

1.2.0.5. P.A.R.A.more #5 — P.A.R.I.A. - Unlocking the Incubator
  1. The problem

    A solid capture habit is worth a lot, but it can lead to a problem. It makes us prone to * over-capture; to keep more than we are able to use.

    I see two main options:

    1. Capture more selectively
    2. Channel into a safe area

    In the first case, we try to only let in the good stuff and discard everything else. We only keep the important, not everything “new”.
    While elegant in theory, after many years of PKM-ing, I have to admit: I still don’t know how to achieve this sustainably and with a reasonable effort: it actually requires a lot of you.

    You need to somehow "be selective” about what to capture. You need to have some gatekeeping in place that prevents you from hoarding whole book pages and full articles.
    In the worst case, you try to use self-discipline to achieve this. This means that you either need to make a very hard decision right at the moment of capturing or a merely hard one a little later when triaging your inbox. Frankly, this strategy will most probably fail you more often than not.
    How no to be overwhelmed by too many SOMEDAY/MAYBE?

  2. someday-maybe empire

    whenever I discarded something it left a lingering feeling that I am neglecting what I call my “someday-maybe empire”. A space of unknown potential that 10, 20, or 30 years down the line may spawn a new career, help me rediscover long-forgotten passions, lead to new hobbies, or maybe even help me to know more about myself.
    my tactic became to keep all the stuff I am unsure about and channel it into some safe area (option 2 from above).
    put all the “unsures” and “impulsion captures“, the someday-maybes and maybe-never-needs, the shiny information objects and woke-my-interest thingummies in a separate contained box ** where they don’t hurt me but ease my mind.
    This tactic of “over-capture & channel” has always been way easier for me than to “capture selectively”. So much so that I now think that to only ever keep the best stuff and never let anything else in is a pipe dream. There is simply no way you can honestly make discard decisions so early. After all, often times what is relevant is decided way later in the process.

  3. Introducing the “Incubator”

    The incubator essentially is a space for things for which there is actually no “good" reason to keep them. The thing just woke your interest. Or it looked nice and you don’t even know why. Or you simply over-captured in a weak moment.
    The incubator soaks up all the stuff you are unsure about.
    Incubated items may currently be the least personal, least valuable, least important things in your organizational system… but they are part of it nonetheless.

  4. When is it helpful?
    1. People who are new to P.A.R.A. and PKM. A good capture habit is the starting point of each PKM odyssey. But in this initial phase where you hone this skill but still lack the skills of organizing you will store a lot of stuff you don’t know what to do with. This can rob you of your trust in your system and lead to you declaring “bankruptcy” down the line. Which will cost you time, effort, and mental determination, just to get back on track. With an incubator, you are somewhat protected from this.
    2. People with a chronic illness of over-capturing. Here the biggest benefit is having a place you can channel stuff into. Stuff that would otherwise convolute your system. So the incubator gives you the freedom to capture freely without ever having to wrestle with whether to keep something or not. It’s like offsite storage for stuff you feel you can’t get rid of. This is the reason I first introduced it personally. But it is also the reason why most people will find it useful.
    3. People who think very strategically and far ahead. In the short and even mid-term, it’s to be expected that you will rarely, if ever, even touch your incubator. So there is close to no value other than the aforementioned channeling. In fact, most stuff in your incubator will never again see the light of the day as there is simply not enough time in your life to resurface everything. But who knows if some of your incubated stuff will not become relevant in 10-15 years or even later? Feed your someday-maybe empire!
    4. People in a *very divergent stage in life. If you are a student exploring a broad variety of topics, someone looking to change careers, or someone engaging in a big project related to self-discovery. In such circumstances, you may literally have no idea what could be useful later, and therefore want to make sure it’s all captured for review later. ** If you’re in a phase of your life where you need or want to capture way more than you can take action on in the short or medium term, an incubator may help you to deal with the weak signal-to-noise ratio.
    5. People using PARA as a LifeOS. If you use P.A.R.A. not just for work but also for lifestyle projects an incubator becomes even handier to manage your life. I will have to say more about this in the next part of this series.

1.3. https://braindump.jethro.dev/posts/para_method/

Contrast with Zettelkasten:
proposes no such organization, instead using links between different information («emergence»)

  1. PARA looks like it would form a good hierarchical overview of tasks and information. Zettelkasten does not provide this.
  2. Zettelkasten remains a useful tool for low-level, inter-project information-linking.

«My own stuff from here»

  1. PARA is not strictly hierarchical (there can be areas subareas, projects, subprojects), which lends itself very well to org-mode
  2. PARA is a good framework to break down big org files
  3. Zettelkasten was only used to develop (academic) ideas and thoughts, and the only area you would be considering is “academic/professional” (This is most likely a pillar in PPV). If you use BASB then you are building a second brain for everything

1.4. Contrast with How to Take Smart Notes

Since Zettelkasten is PARA without Areas
PARA without Areas: Projects Resources Archives -> Projects References Permanents

1.5. Project / Area division is true but maybe obvious

Projects are things that you do that have an end deadline and end goal
Areas are things that you do that end when you either stop caring or die
Resources are Areas where the standard to maintain is information and/or shareability
Archive are inactive stuff to avoid clutter

1.7. Automation is converting areas into projects

1.7.1. Creating a new habit is a project

If automatization is converting areas into proyects, and a habit is already the automatization of problem solving, then creating a new habit is a project

1.8. Dev is Projects, Ops is Areas

1.9. Personal Summary

1.9.1. Time Horizons

source

  • Projects -> Short time horizon
  • Areas -> Long time horizon, when you review that area
  • Resources -> Only if and when you decide to take action on that topic
  • Archive -> cold storage, available if needed, not to be reviewed at a predetermined time

1.9.2. Projects

  • A series of tasks linked to a concrete goal, with a deadline which can be either a specific date or a checkin point
  • Any outcome you’re committed to that requires more than one work session to complete.

1.9.3. Areas

  • A sphere of activity with a standard to be maintained over time (indefinitely) requiring a certain level of attention at all times
  • Things that you’re responsible for, roles that you take on in life and the hats you wear
  • Things that take a certain amount of constant attention
  • Areas are personal, normally you won’t share them altogether, unlike resources and/or projects
  • Personally relevant information in Areas, value judgements and feelings

1.9.4. Resources

  • A topic or theme of ongoing interest
  • Things you’re interested in
  • Subjects/thems you’re researching
  • Information assets you’d like to reference in the future
  • Interest, themes (psychology, politics), assets (stock photos, product testimonials, code snippets)
  • Resources, unlike areas, can be shared without fear, nothing personal, no need to remove personal stuff
  • Generally useful information in Resources, no value judgements, just rational recopilation of facts

1.9.5. Archive

  • Inactive items from the other three categories
  • More actionable is more likely to get archived

1.9.6. Interaction bewteen elements of PARA

1.9.7. Clasifications tangential to PARA

1.9.7.1. Hobby
1.9.7.2. Dream

1.9.8. Break Projects/Areas or even Resources in small-batch projects

1.9.8.1. Projects
  1. 1) A tightly scoped, short-term commitment

    Inputs and outputs (projects) have to be small, discrete notes, otherwise the
    system gets clogged up and stagnant

    1. Projects have to be standarized
1.9.8.2. Areas
  1. You can’t know the extent of your commitments ⇒ you cannot know what to change in your life
  2. You can’t connect your current efforts to your long-term goals
    Considering projects all your areas leads to accumulation of tasks, which
    leads to psychological overwhelming (a never-ending list of commitments than
    never go away, taking into account low level and high level details at all
    times) ⇒ By breaking these responsibilities into bite-sized projects you
    ensure that your Project List will change nearly every week ⇒ creates a
    rhythm and a momentum of project completion to maintain your motivation. It
    generates the constant There is no inherent structure or unit of
    work. You don’t have to accept another person’s definition of it!
  3. You can’t know if you’re making progress toward your goals

1.10. Resources are Areas where the standard to maintain is current, shareable information

You create/curate resources because

  1. You want to store that information because it is inspiring/useful/personal/surprising or will be in the future
  2. You want to stay current on what you’re interested in
  3. You find it useful to share that formation
  4. You want something more relaxed than an area, as there are no immediate consequences of failing to maintain your resources (or rather these )


1.10.1. In Areas of Knowledge, the standard to be maintained is having practical experience

Hollywood Model is completely project-centric

In a Matrix Organization, for example:
https://www.pmi.org/learning/library/matrix-organization-structure-reason-evolution-1837 → research matrix organization
Areas of Knowledge are vertical, projects are horizontal

  1. You want to stay current on your area of knowledge, but also you want to actually use it in a real project, so that it becomes an area
  2. Those knowledge then allows you to carry out technical projects, which in turns generates more practical experience in a Virtous Circle

p4-01.jpg

1.11. PARA metaphors

1.11.1. PARA is a budget for your attention

https://mobile.twitter.com/fortelabs/status/1570084301273960454

Projects
one-time purchases
Areas
ongoing expenses
Resources
incidental/as-needed costs
Archives
past purchases

Author: Julian Lopez Carballal

Created: 2024-10-21 Mon 08:41