Keep up with the issues and challenges that uniquely affect public-sector IT with TechRepublic's free Government IT newsletter, delivered each Tuesday. Automatically sign up today!
I recently worked for an organization which housed a very large Microsoft Exchange network. They had just hired a bevy of consultants to help manage their transition from Exchange 5.5 to Exchange 2003. When I asked the project manager in charge of the effort if they had considered any other mail systems available he stated, "No, Exchange is our standard." End of conversation on that topic.
I'm going on record to say that an answer like that is just plain wrong. Why? Let's talk about what standards are and why we have them in the first place. The dictionary defines standard as: "Something, such as a practice or a product that is widely recognized or employed, especially because of its excellence." There are a number of reasons why organizations create standards for hardware and software, including: reducing confusion, creating consistency, maximizing/leveraging knowledge, and (hopefully) gaining benefits by volume pricing.
Those of us in government IT may be particularly prone to go with "standards" because of the inherent risk aversion that goes with making decisions in public view. We often have to make our purchasing case to multiple stakeholders across organizations and, ultimately, to the tax-paying citizens that we serve.
The process of creating standards involves evaluating our needs and attempting to find the best possible product or service for the lowest price. The result of this process is usually a matrix of features that have been matched up with the needs of the organization. A cost-benefit analysis is done to determine which of the products is best, based on this matrix.
Think about how you determine standards in the first place. You look at price, performance/features, and needs. Your organization's needs certainly change over time, and new products are developed and prices vary on a yearly basis, if not more frequently. So if you are not reviewing your standards periodically, you are ignoring all the change happening around you.
Review your standards on a regular basis
Unfortunately many organizations only review their standards once per decade. After that, the standards seem to get frozen into place, never to change. While standards shouldn't change willy-nilly, they should be thoroughly reviewed on a regular basis.
Any time that you are about to make a large purchase involving a considerable amount of resources, you owe it to yourself and the organization to review your standards as part of the cost justification for the change.
Explore alternatives to your current standards
Even with the limitations imposed on government IT by model procurement policies, compliance with federal and local laws, and bidding processes, it is possible to explore alternatives. You are obligated to present the best choices—not just the easy ones. The Center for Technology in Government offers very useful guides to help in your decision-making, and most importantly, in making your business case for government IT purchases.
Using the example from the first paragraph, instead of the knee-jerk decision on the Exchange 5.5-to-2003 issue, you should ask yourself: Is Exchange 2003 the best product for our needs at this time? While the answer a few years ago might have been a no-brainer, open source products and other commercial Linux-based messaging systems that are now available do not make the Exchange Server 2003 decision such a slam dunk. For instance, Gordano Messaging Server 10.05, Novell Suse Linux OpenExchange 4.1, Scalix 9.01, and Stalker Software CommuniGate Pro 9.0.1 are just some of the offerings available to an organization. Would any of these have been the better choice? Who knows—the question was never considered.
Messaging-system software is not the only competitive area for software that you may have frozen as your organization's standard. There are competing solutions for office/productivity tools (Open Office and Star Office), data management systems (MySQL, PostgreSQL, Ingres, Cloudscape), Integrated Development Environments (Eclipse and NetBeans), operating systems (Linux, BSD), and browsers (Mozilla Firefox and Opera)—just to name a few.
Periodically reviewing your standards makes good sense. Not doing so is just bad management. So the next time you are preparing to upgrade or are approving your standards list for the next fiscal year, think about your alternatives in a clear and logical manner. Take the time to evaluate your organization's needs and the products and services that can satisfy them. Don't let inertia or your emotions cloud your decisions. You might be surprised how much a change in direction can reinvigorate your IT environment.