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.