Standards Now Or (Lots Of) Cash Later

By Steve Andriole

(Back to article)

The whole area of standards is fraught with emotion. Nearly everyone in your organization will have an opinion about what the company should do about operating systems, applications, hardware, software acquisition, services and even system development life cycles. Everyone. Even the people who have nothing to do with maintaining your computing and communications environment will have strong opinions about when everyone should move to the next version of Microsoft Office. In fact, discussions about standards often take on epic proportions with otherwise sane professionals threatening to fall on their swords if the organization doesn't move to the newest version of Windows (or Notes, or Exchange -- or whatever).

It's likely you've heard references to return on investment (ROI) and the total cost of ownership (TCO) every time the subject of standards comes up. Let there be no misunderstanding here: Environments with less rather than more variation will save money. Or put another way, you have some choices. You can aspire to be sane or insane.

What does business management really want here? Standards are a second-order business driver. Most companies don't associate standards-setting with business models, processes, profits or losses. Whether the environment has one, five or 20 word processing systems has probably seldom been associated with business performance: It's hard to link homogeneity with sales! But the fact remains that expenses are clearly related to sales, and standards are closely related to expenses. Herein lies the subtlety of standards and alignment.

What else does business management want? They want flexibility -- and that is the real argument against standards. If your environment doesn't support the business computing or communications processes the business feels it needs to compete, there will be loud complaints. Business managers want to compute and communicate competitively. Standards are often perceived as obstacles, not enablers.

Try out these standards questions:

The answers you give to these kinds of questions will reveal a lot about your attitudes about standards, standards responsibility, authority and accountability -- and whether your chances of standardization are high, low or miserable.

If we've learned anything over the past few decades, it's that standards are as much about organizational structures, processes and cultures as they are about technology. The ability to actually control computing and communications environments through thoughtful governance policies and procedures will determine to a great extent how standardized organizations become. We've also learned that the more you succeed the less you'll pay.

Elements of Standards Alignment

The elements of a standards alignment strategy appear in Figure 1.

Standards Alignment Figure 1: The Elements of Standards Alignment

As always, everything needs to sync with your business strategy -- assuming one exists. If none exists, then make sure that you cover your political you-know-what. The real key here is governance and the processes that make standards management effective. Without serious support for a standardized environment, you're toast. Clearly, less variation in your platforms, applications, architectures, acquisition and disposition practices, and life cycles will reduce your costs. And as always, you need to focus on what the environment should look like in the next two to three years.

The following figure will help you implement your standards strategy. It offers cells in a matrix that you can use to identify, define and prioritize requirements.

Note the distinction between the enterprise and the business division or units. This is a killer distinction since it determines ultimately whether you succeed in your quest to reduce variation in your environment. If you're in a strong centralized organization then your chances for success are much, much higher than they are if you're in a decentralized organization with a weak enterprise group responsible for infrastructure. Put another way, it you're in an organization that has a central CIO whose job is really a "Chief Infrastructure Officer" and whose charter is full of authority holes then you're not likely to reduce variation in your environment. In fact, you're likely to find yourself suiting up for one standards crusade after another.

The organizational structures that have the greatest chance of success are either a strong centralized IT organization or a decentralized one that has unambiguous separation of duties, with the infrastructure usually belonging to the central group. This later model only works when there is buy-in to standardization and when buy-in begins to weaken the central management is willing to step in to re-establish standards authority.

The figure can help with a current baseline assessment and with the prioritization of standards requirements. This assessment should be focused on today and tomorrow. An assessment of current variation in each of the areas should be made followed by a strategy for reducing variation over some reasonable period of time.

Standards Framework

Figure 2: A Standards Requirements & Planning Matrix

The figure requires you to look at your governance and processes, your platforms, your primary software applications, your architectures, your acquisition and disposition standards, as well as your life cycles. The objective of these assessments is to reduce variation as a means to save money and preserve flexibility. The figure also requires you to realistically determine your organizational structure's relationship to standards-setting. If you're decentralized then you have some serious governance work to do; if you're centralized then you'll have fewer religious wars over standards. The figure asks you to think about the enterprise versus the divisions or business units and proceed accordingly.

Here are some standards recommendations:

Since standardization does not generate direct impact to the bottom line, you'll have to communicate why it makes sense to standardize. Use industry benchmarks to communicate why you should standardize and how the process might work.

If you're lucky you'll avoid a few religious wars over standardization. Good luck.

Steve Andriole is the founder and chief technology officer (CTO) of TechVestCo, a new-economy consortium that focuses on optimizing investments in information technology. He is formerly the senior vice president and CTO of Safeguard Scientifics and CTO and senior vice president for Technology Strategy at CIGNA Corp. His career began at the Defense Advanced Research Projects Agency where he was the director of Cybernetics Technology. He can be reached at steve@techvestco.com.