Alternate project naming idea

I had to re-write this as I lost the original in the forum upgrade disaster.


The original JD implementation had no way of handling multiple projects. Fairly recently I came up with the PRO.AC.ID method, which assigns a 3-digit number as a project ID.

After using it for a while, I don’t think I like it. I don’t find the project IDs memorable and, worse, I find that the extra numbers make it harder for me to remember my category IDs.


It is worth noting that I think projects should be used sparingly. Before the idea existed, my entire life was a single ‘project’. I ran a 3-year Australia-wide data centre deployment as a single project.

You should aim to exhaust the basic AC.ID notation before you reach for multiple projects.

A previous idea

I had explored the idea of using letters rather than numbers before I documented the existing system. The idea was 3-letter abbreviations for project names. ‘Home’ becomes HME, the data centre project at work becomes DCP, and so on. I didn’t like this because it’s not memorable, it’s easy to get confused (did you choose HOM or HME?), and there’s no easy way to group projects.

The new idea

I suggest a new project ID format: a letter, followed by two numbers.

The letter serves as a grouping, and a mnemonic reminder: P for personal, W for work, whatever you like.

The numbers follow sequentially. Or not, if you prefer. It might be more memorable not to start at 01.

So now we have:

  • P01 for my first personal project.
  • Q01 for the first project at work, because the name of the company I work at starts with a ‘Q’.
    • Leaving the other letters available for when I change jobs.
  • If you’re a freelancer you might use C01 for the first client, and so on.

If you exhaust 100 projects within a letter, or all 26 letters, you’re doing it wrong.

What do you think?

Let me know! As soon as this occurred to me it seemed like the head-slappingly obvious solution. What am I missing?


I see some merit in this if you need that wider level of project-based split-out for your projects and files. The alpha suffix will keep things nicely separated and if the alpha has meaning, then it has served its purpose as an easier-to-remember structure. Let’s face it, you’re trying to be kind to your future self and make things easier to find.

As you indicated earlier, you ran a 3-year project on AC.ID alone, so it pays to think a while about what your actual needs are and live with the structures for a bit to see how they go.

I have some similarities to your suggested approach, as I use the project number more like an “entity” number and have folders that house both reference files and project numbers together. To explain, I am a self-employed IT consultant and have the following Project structure, albeit not with the alpha prefix that you’ve suggested.

My structure is:

100 - Personal
200 - My Company
3XX - Client projects and files.
301- Client 1
302 Client 2, etc

So, in Dropbox, For the project of putting my daughter’s CV together, I have 100 Personal\30-39 Career\30 Resumes\100.30.03 [Daughters name] to house my daughter’s resume and supporting documents. In my task management system (Notion) the project number/name was “100.30.03 Daughters resume” while we were putting this together.

I’m still wrestling with Projects and file storage numbering existing in the one structure, so I’ll give the approach you’ve indicated some thought. I sometimes have projects that have no supporting files and no folder in the system but still need to be identified within each area that they belong to as that’s easier for me to remember and find in my task manager. Likewise, I have reference files that have no active project relating to them.

But that’s the subject of another post! Thanks for putting this idea out there and for coming up with Johhny Decimal in the first place. As a former PARA user, I’m finding JD a solid foundation to base my storage and planning needs upon.

The journey continues!

1 Like

I have a question about running your three-year long project in just AC.ID format. Did you have other subfolders within your ID folder that did not have an ID? Because I find it very hard to wrap my head around the idea of managing materials from across many different areas of life with just two levels of organisation. For reference, this is my current JD setup but I’m finding it a bit unwieldy and am seriously considering moving to an AC.ID structure. But for example, I’m having trouble visualising how I would organise my modules.

I did cheat, and in such a specific way I can still remember the exact details 7 years later.

The project was ‘deploy data centres across Australia’. The issue I ran in to was when I needed to do the same thing at each location.

I had 72 Cabling & patching and within there 72.02 Structured cabling. This is a particular type of cabling that is installed in a data centre.

So far, so neat. I liked the simplicity of one number to capture that whole thing, and wanted anything to do with structured cabling in one folder in my email.

But then I ran in to the classic issue: I need another level of organisation. Because I want to distinguish between the data centres.

This would have been a solution, but I didn’t want to do it:

  • 72.02 Structured cabling (data centre 1)
  • 72.03 Structured cabling (data centre 2)
  • 72.12 Structured cabling (data centre x)

Instead, I created folders and an ad-hoc extension to the JD IDs:

  • 72.02.DC1
  • 72.02.DC2

And actually the DCs already came with their own 3-letter codes that I won’t share here, so I used those vs. ‘DC1’. This was pure luck and made them all super memorable.

This worked super well and is a strategy that I endorse. In this situation you have to break my system somehow: it’s a two-dimensional system, and we need to store three dimensions. So the question becomes how to do that the most gracefully.


At yes. Good to know this. And I kind of like the idea of doing a 2d system and then creating an ad hoc third dimension when necessary. I might adopt that.