Struggling with PRO.AC.ID structure (software dev clients)

Overall, I understand the concept and structure behind PRO.AC.ID, but in practice I find that while I need the “PRO”, I don’t have many "AC"s per client.

I am a consultant who implements software for clients, mostly on a project basis. Most of my artifacts in these projects are notes and to-do items. I use GTD for tasks (in Things 3) and Bear for note-taking. Notes are mostly meeting notes, reference (naming conventions, business processes, checklists, etc.).

Here’s what I have so far:

00.00 Index (note in Bear)

00-09 Meta

  • 00 Meta
    • 00.00 Index

100-199 Personal Projects

  • 101 Personal
    • 10-19 Admin
  • 102 Personal Project
  • 103 Personal Project

200–299 Client Projects

  • 200 Company
    • 10-19 Admin
    • 20-29 Team
      • 21 1:1s
        • 200.21.01 1:1 w/Boss
    • 30-39 Team Sharing
      • 31 Team Sharing Notes
        • 200.31.01 Coworker Presentation A
        • 200.31.01 Coworker Presentation B
      • 32 My Presentations
        • 200.32.00 Sharing Ideas
        • 200.32.01 Topic A
        • 200.32.01 Topic B
  • 201 Client A Proj 1
    • 00-09 Meta
      • 201.00.00 Index
    • 10-19 Admin
      • 10 Tasks
      • 11 Meeting Notes
    • 20-29 Documentation
      • 21 Test Scripts
  • 202 Client B Proj 1
  • 203 Client A Proj 2
  • 204 Client C Proj 1

This is…okay. But it feels highly complex for what I need in practice. In my task manager, I have matching projects (XXX Client Proj) and suffix tasks with their ID (Some Task [201.10.05]).

I also often have most of my work in systems like Jira, with stories/tasks assigned to me on a Kanban board. If I need supporting notes for those, I’ll use their Jira ID instead of a JD ID, such as 201.10.567.

PRO seems necessary, as I’ll have a lot of projects over time, but categories feel less clear/useful to me.

Anyone have experience using JD for client based work with more notes and tasks than actual files in folders?

Yeah I think this is still a bit of an unsolved problem. I know what you mean, creating a full PRO.AC.ID structure for every new project feels like overkill.

The more I use multiple projects the more I appreciate how much better the system is when you only have one project! Or fewer, at least. Fewer is definitely better. Just because we’re human, we really can remember a whole bunch of numbers when we’re only dealing with one project. I can still remember the numbers from a project I did 6 years ago because it’s all I was doing at the time and it was an intense job.

I don’t do client-type work so this isn’t something I can test. But I wonder what would happen if you used areas/categories differently for this type of job. Maybe ditch the idea that every area has to be different and just use them as a basic index.

Perhaps each client gets a project number. Then 10-19 is reserved for client-admin type stuff, and you use 20-29 through 90-99 for projects. How complex each project is will dictate what you do: really simple projects might fit in to what we call a category, meaning you get almost a hundred per client before you run out. More complex projects might need their own area.

Remember, within a category you still have a hundred things, your IDs. And you can standardise a bunch of these if you always handle the same sort of thing: to-dos, import files, export files, whatever. Just build yourself a standard numbering scheme, don’t be afraid to use your IDs a bit like categories, skip over numbers and group things in to 10.

AC.00-09 can be your to-do, notes, etc. AC.10-19 can be files. AC.20-29 is whatever else.

Very keen to hear what happens here.