Monthly Sales Revenue Generation… no

Monthly Sales Group Rev Production… no

Sales Revenue Performance by Month… no

Sales Revenue by Month for Overview… maybe… yes, that one was it.

Speaking from experience, trying to document vital business information when it all is named with generic operational mumbo-jumbo will slowly cause your brain cells to rebel against you throughout the day. If you haven’t given in to their demands by the end of the day, your brain could retaliate by making you forget vital information like your name, favorite color, or the air speed velocity of an unladen swallow.

Concerns for your own health aside, the business is put at risk when vital documents or business processes are not identified correctly. Loss of documentation can lead to costs for replacing it, failed process attempts, legal actions, and bad requirements for projects.

To prevent that from occurring, a system to easily identify information correctly is needed. In the strictest form, the information you are working with should have unique ID’s (not like the ones at the beginning of the post though). If you use requirements management tool like Caliber, then your entries should be given unique IDs. If not you will have to come up with some system yourself.

A combination of letters and numbers work well to prevent ID overlap. I tend to favor a 2 to 3 letter prefix that is some sort of abbreviation for the information such as ‘RO’ for report object or ‘IPD’ for InfoPath Document. This will help add much needed meaning to an identifier without having so many words to say so in the first place. It also serves as a code that is easier for machine side recognition if applicable to your project.

Now we have our lovely hybrid id. What do we name our document? Some people like to use summaries (which unfortunately, in my opinion, are informative mostly based on how you see things.) I try to use a generic name that describes the overall purpose of the doc such as ‘Sales Dashboard’ or ‘Customer Credit Registration’. Those types of names will most likely be commonly accompanied with dates relevant to the creation of the document. Try to append the date in a manner that is friendly to alphabetical sorts (i.e. 2009-08-26).

Now the part that some of us will not like (I am looking in your general direction agile extremists), write down in a list that all these documents exist. Descriptions, owners, and change management rules for these documents will prove invaluable later. While other BA’s are telling stories about how this one employee quit 4 years ago and the sales process is relying on a SQL database running off of an old laptop that person setup which they are now trying to bypass, you will be quickly identifying which documents need to be migrated to the new system and being confident you got all the relevant organization’s buy-in.