Saturday, February 28, 2009

A Four-Tiered Approach to Standards

Answering the simple question of what is your standard for a particular product, naming convention or password strength is often more involved that just a simple answer. The approach I use to set and communicate standards is a four-tier approach using Preferred, Standard, Non-Standard and Exception as categories.

Preferred is simply the product that I would like to use above all others. This could be for strategic reasons, advantageous licensing, skill base or any number of factors that make it rise above the rest. There is typically only one product signed with the Preferred tag.

Standard is the category for any remaining products that we offer internal support. Anything in the Preferred or Standard categories can be expected to be fully supported with multiple, skilled resources available and with defined Service Level Agreements. Anything rated below these two categories are a warning that issues will need to be overcome before using those products.

Non-standard is usually the catch-all category, naming common products that the internal staff does not have the skill base to support. The importance of this category is to inform decision-makers that additional costs need to be budgeted and that their support team will need to contract with others for support. Making this a dollars discussion usually drives the decision towards a Standard.

Exception means that I do not have the authority to allow this inside my company and that the decision-maker will need to have a discussion with someone higher up the organization chart. I’ve found Exception is better than No. No rarely works until that higher-up says No anyway. Exception says let me explain the situation, agree to disagree and let you know how you can press your case and the obstacles you may find. It turns an adversarial conversation into a useful, and professional, conversation.

Let’s make this more real with a totally fictional database example.

  • Preferred – Oracle – Company owns a site license, maintains a highly reliable database farm and all the staff is certified.
  • Standard – Microsoft SQLServer on Windows and IBM DB2 on AIX – Company has purchased a number of applications that did not offer Oracle as an option and at least three DBA’s are skilled in both.
  • Non-Standard – All others not specially listed including but not limited to Informix, MySQL and IBM DB2 on Windows. Use as an embedded database requires 100% vendor support.
  • Exception – Any mainframe database, since that platform is being decommissioned.
These standards can become quite involved and should explain as much of the “it depends” as possible. But there can be inter-dependencies between standards or special circumstances that make absolute statements impossible to craft. For example, maybe the vendor just started offering Oracle support but has a long track record on SQLServer. Judgments on these types of cases will be necessary.

Also recognize that your standards will change over time and will need to be communicated as they are modified. A good time to do that is a month or so before you get involved in the budget cycle. Maybe you’ll need some additional training dollars for a product you want to make Standard. Perhaps some outside contractor resources will be needed to cover a product demoted to Non-Standard. Or maybe a capital outlay for a new site license for that Preferred standard that is really taking off.

No comments: