Friday, June 07, 2013

SOP Friday: Naming Your Processes and Procedures

File Naming Conventions


One of the most important elements of a "standard operating procedures" collection is the ability to FIND what you're looking for so you can USE it. Any documentation you can't find is worthless. That's why you actually need some norms or standards around the naming of your procedures and processes.

Most of us have phone or tablets with "apps" installed. I don't know about you, but I find it really frustrating when the apps are alphabetized by something other than the most important word. For example, my Delta Airlines app is called "Fly Delta" and is alphabetized under F instead of D. Right next to it is the Free Ringtones app. Under F for free, not R for ringtone.

The earthquake app is under R for Recent Earthquakes. The Verizon app is under M for My Verizon.

I overheard some folks talking about this problem just a few days ago. They were talking about doing a file search since the key word is somewhere in the title. That's probably okay if you have a few procedures. But if you have a lot, a much better organizational structure is in order.

How do you name things so you can find them? After all, you will have a lot of processes and procedures when you're done documenting your business. Here's what we do.

Rule One: The most important word is first. For example
- QuickBooks Invoicing - Monthly.docx
- QuickBooks Quarterly Profit and Loss.docx
- Sales Tax Reporting - County.docx

Notice that you could have name these very differently:
- Invoicing in QuickBooks.docx
- P&L in QuickBooks.docx
- Reporting County Sales Tax.docx

Putting the most important word first allows related tasks to be right next to each other in a file listing. This has several obvious advantages in addition to the fact that it makes it each to avoid duplicates.

One important tip on determining the most important word: It's probably NOT a verb or gerund. For example, Reporting is a bad first word because you will end up bunching several unrelated tasks just because they're all related to reporting. Having said that, you can choose to make exceptions. For example, since all invoice is related, you could start several file names with the word Invoicing.

Rule Two: Be descriptive. Use long file names if you need to, but be descriptive. It should never be unclear what you'll find inside a document. If you have to open documents in order to verify that you have the right process, you need to rename those documents.

Rule Three: Use sub folders if appropriate. See the SOP article on organizing your company files and folders, cited below. A great example is the client onboarding file/folders you see here. In this case we've even numbered the files so they show up in the correct order. (Note that #2 is repeated for each class of employee.)

Rule Four: Always agree within your team about the names for files. Remember, "indexing" and finding these processes quickly is the main goal here. If two or more people disagree on a naming convention, talk it out, make a decision, and then use it consistently.

Rule Five: Do not use the words Process or Procedure in the file name. Everything in the folder should be a Process or Procedure, and the folder might even be named Process or Procedure.


Testing Your Naming Conventions


Testing is easy. Processes and procedures should be in the first location you look into, and should be named with the first word you were looking for. Just like organizing your house. Where do you kee the tool you use three times a year? You should keep it in the first place you went to look for it. If it's not there, put it there after you find it.

File names are intended to HELP us and are not just a required field. Think about the name of the file and make it work for you.

- - - - -

Note: Please see the following two related articles:
SOP: Local Docs, My Docs, and Storing Files on the Server

and

SOP: Organizing Your Company Files and Folders


Comments welcome!

- - - - -



About this Series

SOP Friday - or Standard Operating System Friday - is a series dedicated to helping small computer consulting firms develop the right processes and procedures to create a successful and profitable consulting business.

Find out more about the series, and view the complete "table of contents" for SOP Friday at SmallBizThoughts.com.

- - - - -

Next week's topic: Billing Procedures


:-)


Still the best Quick-Start Guide to Managed Services: 


by Karl W. Palachuk 

Now only $39.95 at SMB Books!

Ebook or Paperback

Learn More!

3 comments:

  1. My friend Russ added the following info on the Facebook note about this post:

    "One more thing Important I've found a lot of SMB's fail at is People will name PATHS and items TOO long for their Third Party Backups to handle and the document doesn't get backed up 260 Characters is a Limit in Windows but Check what Backup Tools you are using! http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx"

    http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx

    ReplyDelete
  2. I'll offer a different view that says you shouldn't be restricting yourself to a file name to provide meta data. Our SOPs are stored in a full text searchable structured wiki. By structured, I mean that you can have search tags associated with each wiki page and enforce a structure to pages where needed.

    By using a wiki instead of a filesystem, or even a Sharepoint library, we can find SOPs, Tech Notes, etc by a similar process to using Google.

    Incidentally, we use foswiki

    ReplyDelete
  3. Good point, Gareth.

    If you want to maintain a wiki, that's a good approach. But when you get a list of articles, you'r still going to want them to have good, descriptive titles. The computer might be able to scan all the text inside the document, but the human who need to click on something will still make best use of the title.

    ReplyDelete

Feedback Welcome

Please note, however, that spam will be deleted, as will abusive posts.

Disagreements welcome!