Areas of Focus - inside/out - clients/roles

I’m having trouble with my folder outline and i’d like to hear your thoughts. This may seem esoteric but bear with me. If you have many roles at work, or many clients (i.e. lawyers), then maybe you’ve thought about this.

I work in labour relations. I have grievance/arbitration files (projects) that pop up every month, around a half dozen per month, they take one or two months to resolve. Sometimes in settlement sometimes in litigation. The project is often a person, belonging to a client (the relevant Union). These projects require set tasks like: researching case law, writing the brief, presenting the brief, booking travel; interviewing witnesses; etc.

I also have contract negotations with Companies. These take longer (3-4 months) and pop up every few years. These involve negotiation prep, writing proposals, blocks of dates for having negotiations to prepare for, etc.

The remainder of my job is sort of advisory for all of my clients, lots of travel, admin work,

I’m suffering from what I would call an inside/out problem, which must be an old problem in the realm of file management. Put simply what goes at the top of the hierarchy and what goes inside - my roles, my type of projects, my clients or something else - when either starting point seems logical/rational?

For example: taking only part of my work, I could do the following file structure by client:

  1. Work
    -Client One
    —Arbitrations
    ——[Folder or Project] Case One
    ———[Project or Master Task] Research: Case One
    ———[Project or Master Task] Writing: Case One
    ——[Folder or Project] Case Two
    —Negotiation
    —Advisory
    -Client Two
    —Arbitrations
    ——[Folder or Project] Case One
    ———[Project or Master Task] Research: Case One
    ———[Project or Master Task] Writing: Case One
    ——[Folder or Project] Case Two
    —Negotiation
    —Advisory
    -Meetings
    -Admin

Or I could do by type of work (flipping inside out)
2. Work
—Arbitrations
——Client One
———Case One
————Research: Case One
————Writing: Case One
——Client Two
———Case Two
————Research: Case Two
————Writing: Case Two
—Negotiations
——Client One
——Client Two
—Advisory
——Client One
——Client Two
—Admin

Or - and this is new idea i might try- I could think of my job in terms of roles that I play
3. Work
—Advocate/Litigator
——Case One for Client One
———Project/Single Action: Complete Research for Case One (link to project in research)
———Project: Write Brief for Case One (project under “writer” folder)
———Project: Prepare for Hearing Case One
—Researcher
——Project: Research Case Law for Case One
——Project: Research contract language for Client One Negotiations
—Negotiator
——Client One Negotations
—Advisor
—Writer
——Write Brief for Client One Case One
—Employee (for admin tasks)

I hope you get the gist of my problem with folder/project structure: x inside y inside z or z inside y inside x? Either way it seems I repeat folders for either clients or responsibilities inside the master folder, which gets confusing.

On the one hand I’m over thinking, I know. But on the other, I just find a way to efficiently approach my list. Maybe Tags are the missing link here (i.e. tags for clients, or cases), but I feel like I already have too many tags.

If you have similar type of work, without clear lines, I’m interested in how you deal with the problem where a folder structure for AoF could be flipped inside our or outside in.

Thanks

This is something I’ve thought about a lot for myself. I run production projects at work for multiple different clients and internal business units, support enablement projects for broader teams, like process design, tool deployments, reporting, or strategy design, and support a team, so think about development, coaching, and performance evaluations for them.

I think the key for me in determining my folder structure was considering that folders don’t need to be tools to taxonomize everything, but are better thought of (for me) as grouping agents. In other words, what projects does it make sense to look at together when looking at a subset of projects.

To this end, I’ve ended up with two professional folders: Production and Enablement.

In each, I have both “outcome” projects, like client projects, but also “area” (single action list) projects that relate to groups of tasks that are ever present for areas of focus.

To be more “true” I could have many folder hierarchies, but other than filing, I couldn’t find a practical benefit to over-foldering, and found much more agility in having fewer folders, not having to sweat “where does this one go?” quite so much, and instead being more execution focused.

This is just me, of course, and others will likely have other totally different approaches, but I thought I’d pitch considering fewer folders over the organization of same.

Good luck!

ScottyJ

5 Likes

Thanks @heyscottyj for your generous reply. I have been reading some of your previous posts, and I’ve thought about doing the same. It may be that, like you maybe realized for yourself, that I’m using folders as an unnecesary crutch that is getting in the way of doing. Generous use of defer dates and “on hold” projects may be what I need to get around the clutter problem that I’ve been worried about with not having folders but which has nevertheless resulted from those folders.

Hey @heyscottyj, I just read your very useful blog post on the inside omnifocus website. Separating the AoF from the Active Projects makes so much sense. It focuses on the work to be done, not so much on the organization of the work, which was putting me into a rabbit hole.

I wonder where you put your “maintenance” or “routine” tasks, if you put them anywhere at all? (i.e. to you keep a task/project called “Complete Weekly Review” inside omnifocus?)

Another trial lawyer here. I have struggled through this issue as you are now. My law practice is different from yours, but similar enough that this might be helpful. Here is how I structured my system. 1. Folders for AoF. 2. In my Trial Lawyer folder, here is my set up: (a) projects for each case; (b) folders for clients for whom I have many cases but otherwise there are no sub-folders; and © one single-action-list project for little one-off matters that I handle for my partners or quick matters that don’t need the extra admin work of having a dedicated project. Since you seem to have a “templatized” routine for handling certain types of cases, I would put the outline in taskpaper format and use Drafts or Workflow (Siri Shortcuts) to create a new project for each new case you have. Happy to share more details if you feel it would be helpful.

1 Like

I understand the second or third setup better than the first. From the clouds looking down, these two setups have root folders that are truer to the notion of areas of focus. From the grass looking up, I would be inclined to keep everything for a client within one entire folder. In this way, once I would finish everything with a client, I could archive that client’s folder.


JJW

1 Like

I tend to use single actions to refer to simpler or often executed routines, and I home them in the single actions project that they relate to.

My Home and Household list, for example, has routine/repeating actions for watering plants, putting out recycling and garbage, and changing the filters in my fridge or coffee maker. My Kids list has routine/repeating actions about things like prep for swimming lessons, medical needs, and so on.

Meanwhile, I do have a Productivityism and GTD list for things like weekly reviews (I do two) and quarterly reviews, but each has a separate checklist I refer to outside of OF.

I know others tend to group routines together in separate folders for routines, probably because that allows them to not sweat them come review time, but I like tying my routines to their purpose so that I can appreciate why I do them.

Bigger routines end up being repeating projects, because they deserve as much, due to their complexity, or multi-context needs. Routine big reports at work are repeating projects in my Enablement folder, and doing my taxes is a repeating project in my Personal folder.

ScottyJ

4 Likes

To handle most of my single action lists, I have a project called @Admin> (AoR) in the folder for each Area of Responsibility. Examples are @Admin> Surroundings, @Admin> Hobbies, @Admin> Finances, and @Admin> Research. I have a perspective that searches for “@Admin>” to show these projects.


JJW

1 Like

I love using this logic to decide where things go in my database. Projects should be things that I will mark complete some day. Folders are things that can be dropped when I am done with that area of focus. I’m leaning more and more on tags rather than folders or projects. If I didn’t like the hierarchical views I get in project-based perspectives so much, I would probably move all my organization to the tags realm and just have a flat list of projects that aren’t in any particular order–because I would be using my tag-views to find everything anyway. No system is perfect, though, and the way I use OmniFocus tends to evolve with each new feature added. :D

3 Likes

Okay, Scotty, I have to say that with one little implied insight from your “Inside Omnifocus” post, I’ve totally transformed my GTD system in Omnifocus. I was stuck thinking of Project Lists as something that is fully contained within an AoF. So I was using AoF folders to contain projects related to that AoF as well as AoF single action lists. This kept leading me to impasse and over-complicated hierarchies in Omnifocus. Incidentally, this is why I could never make GTD work on paper.

It is much better I think to think of everything in terms of lists. AoF are single action maintenance lists within a sphere of my life (Work , Personal, Community). Folders are used sparingly for these master spheres but they contain the lists that are relevant to my life (wife, kids, admin, boss, key client, etc.)

Folders are also used sparingly for classifying projects in accordance with these spheres (i.e. Work Big Client 1 Projects; Work Other Projects; Personal Projects; Community Projects) but are on equal footing with rather than contained within master AoF folders. If, within an AoF list, more than one task is required to reach a desired outcome by a certain date, it becomes a project: the originating AoF is less relevant once something reaches Project status.

In this way, AoF lists can even come and go (i.e. Big Client 1 Ongoing Negotiations) and if something becomes project-like within that AoF it becomes a project with a due date. AoF, therefore, do not strictly contain projects, they are a separate lens entirely and a functionally different list. To-dos move from AoF to Projects when they become a project and satisfy the criteria determined by the Project lens (several tasks; but finite).

Now, having said all that, I’m still interested in how you handle weekly reviews and other routines (i.e. start of workday routine). I assume you use defer dates to reduce the clutter, but do you have these kind of maintenance tasks pre-flagged/tagged with “Today” so that it pops up in your forecast automatically or do you make it a conscious act to tag it from your “Next” perspective when it pops up (which doesn’t seem like it would work since the new tag would be carried forward)?

Also, you say you do two reviews: is this the same “weekly” review done semi-weekly or do you do separate reviews for work and home? Where is your GTD/Productivityist lists stored in your system?

Finally, what do you mean by “Enablement” projects?

Also, I’m trying using flags for only flaging hot projects as you do. I used to have a “Today” view, but I’m seeing the value of forcing the system into the forecast with that tag, even if it feels unnatural to not use flags to identify most important tasks.

Sorry for the long post and thanks for your contributions to this forum.

2 Likes

Sorry for the long post, I didn’t have time to write a short one.

I’m glad it was helpful! I won’t claim this is the best structure, but it’s the best for me. Certainly, for others, more folders and more hierarchy is helpful or even necessary to drive their workflows, but I found simplifying to be the most helpful for me.

Some routines have due dates (if I don’t properly winterize my home by date x, I’m going to have frozen pipes, and if I don’t change my furnace filter every three months, it will impact HVAC performance, for example), so those are typically deferred to due date minus one week and with due dates, they’ll show on my Forecast.

Other routines that aren’t “hard due”, like reviews, are deferred and Forecast tagged, so they show up on my Forecast view also, but not due.

Yes, it’s a canonical GTD weekly review, but I sort of split it in to two “phases” or “mindsets”. I have a “Friday Reflection Review”, which is more about the “Get Current” phase of the Weekly Review, looking at calendar, reviewing project lists for completions or quick adds, and my Waiting On list. It’s kind of a quick triage "how can I simplify my review and any quick things I need to consider before the weekend.

I also have “Executive Mondays”, which is the balance of the review, from top to bottom. It’s eased, though, by having done a sweep on the Friday before.

As for the GTD/Productivityism SAL project, it’s in my Domains folder. I found it valuable to have a place to put actions about my system, such as “consider a tag for x and apply it to all relevant projects”, or “read Inside OmniFocus articles by Rose, Eric, and Daniel”. I also use it to track actions I have with my productivity coach.

At work, I/my team do a number of production projects for clients (building websites, visual designs, etc.) that are tangible deliverables. These go in a Production folder.

Separately, though, I also do a lot of work about how our team accomplishes this production, from assessing new tools/technologies to process design to strategy development to reporting and analytics, etc. These bodies of work enable our team do what it does, and so go in the Enablement folder. At one time, I had all professional projects in one folder, but found that (a) it was too unwieldy a list to look at all together and (b) each kind of work (production and enablement) require a different mindset, and so are best looked at between two different buckets.

I hope this all made sense!

ScottyJ

5 Likes