True Confessions of a PM: I Do Care about Document Management
Ever have one of those moments as a PM when your team asks you a question, and you hear yourself responding but think to yourself--wow, that statement was a bald-faced lie? I had that experience last week when discussing file sharing protocols with my team. We are using Microsoft OneDrive to organize working files. We also have a Microsoft SharePoint site that is client facing. Now, before you say anything, I agree with you that this is inefficient. I'd love to use a single file sharing site. Working with clients, however--particularly in a government setting, where a lot of information is fire walled--makes that an impossible dream. So, yes, I've thought about it--but, unfortunately, we are stuck with two sites, which we have carefully distinguished in terms of purpose and audience. One is a file repository for our clients to access deliverables. The other is an internal collaboration and file sharing repository for the team to use as they see fit. Hence, when the team asked me what naming convention we should use for our files, I responded that I didn't care.
“Ever have one of those moments as a PM when your team asks you a question, and you hear yourself responding but think to yourself—wow, that statement was a bald-faced lie? ”
L-I-E. Any PM worth her salt knows that document management is a foundational element of any project. There's an entire section of the Project Management Body of Knowledge dedicated to managing project knowledge. You could have the best content in the world, but if it isn't organized consistently, it actually hurts you instead of helping you. Think about it--how many times have you wasted time searching through your e-mails to find a file? Accidentally edited an outdated version of a white paper? Struggled to locate a file when you're on a webinar with your client? Being disorganized is not exactly a hallmark of trust when a client is paying you to make sure that things are in order. PMBOK's point about all of this is that knowledge management requires cultivating an atmosphere of trust in which people feel comfortable to share their knowledge but are also interested in learning what others have to share.
So, if document management is so important, why did I lie? The simple truth is that the team should decide what naming convention they want to use. You as the PM should rejoice if people understand the need to organize files. Unless a client or organizational requirement exists, PMs should therefore adapt to whatever organizational method the team selects, as long as that method is consistent. That being said, here are some knowledge management tips to consider:
Consider your audience. One of the sites that my team manages is client facing, while the other is internal. Consequently, different types of files will be stored on the two sites. The sites may also be organized differently based on what information the client references most often. For example, you may not want to share working files or editable versions of deliverables on the client facing site. Also, if the client is looking at the schedule every week, that document should be front and center.
Adopt a flat file hierarchy. As file sharing repositories increasingly transition to metadata tagging and away from folder structures, this will become less and less of an issue. If you're stuck with folders, though, keep the document library as flat as possible. This means fewer libraries and fewer folders to click through. Follow the same principle as a website--the more layers people have to click through to access your content, the less likely they'll be to read it. Another pet peeve: when I find a folder that contains a single document, I actually get angry. Kind of the opposite of not caring. The one exception is meeting notes or agendas or other documents that don't get referenced very often. If you have so many meeting notes that the list of files takes up the entire computer screen, by all means create a folder to group together the notes from last year. These aren't referenced as often, so doing a little extra digging will do more good than harm in this case.
Keep it classy. Name your files in a way that makes sense. What do I mean by this? Pay attention to the details. If your file is named "Copy of...", it tells me that you couldn't be bothered to rename it. I'd also suggest dating the file. If you're working on multiple versions of the same file within a day, consider adding your initials and/or a time stamp to distinguish different versions. Also, make sure the date format is consistent. If one of your files doesn't line up with the others in the document library, it probably means that you forgot a space or a dash somewhere. In the grand scheme of things, a misplaced dash probably doesn't matter too much. But, if every member of your team spends an extra 30 seconds searching for a file that's out of order due to a missing dash, that time adds up and translates to lost productivity and lost money.
Create an archive folder. Archive outdated versions of documents to avoid version control issues. The archive folder should be the top-level folder in a library. If it's not, insert a special character (I'd suggest an underscore) to keep it that way. By the same token, use numerals with two places (e.g., 01) for situations in which you'd like "1" to come before "10".
