Eight to Late

Sensemaking and Analytics for Organizations

Chasing the mirage: the illusion of corporate IT standards

with 6 comments


Corporate IT environments tend to evolve in a haphazard fashion, reflecting the competing demands made on them by the organisational functions they support. This state of affairs suggests that IT is doing what it should be doing: supporting the work of  organisations.  On the other hand, this can result in unwieldy environments that are difficult and expensive to maintain. Efforts to address this  generally involve the imposition of standards relating to infrastructure, software and processes.  Unfortunately, the results of such efforts are mixed: although the adoption of standards  can reduce IT  costs, it does not lead to as much standardization as one might expect. In this post I explore why this is so. To this end I first look at intrinsic properties or characteristics that standards are assumed to have and discuss why they don’t actually have them. After that I look at some other factors that are external to standards but can also work against them.  My discussion is inspired by and partially based on a paper by Ole Hanseth and Kristin Braa entitled, Hunting for Treasure at the End of the Rainbow: Standardizing Corporate IT Infrastructure.

Assumed characteristics of standards and why they are false

Those who formulate corporate IT standards have in mind a set of specifications that have the following intrinsic characteristics:

  1. Universality –  the specifications are applicable to all users and situations.
  2. Completeness –    they include all details,  leaving nothing to the discretion of implementers.
  3. Unambiguity –     every specification has only one possible interpretation.

Unfortunately, none of these hold in the real world. Let’s take a brief look at each of them in turn.


To understand why the universality claimed by standards is false, it is useful to start by considering how a standard is created. Any new knowledge is necessarily local before it becomes a standard– that is, it is formed in a particular context and situation. For example, a particular IT help desk process depends, among other things, on the budget of the IT department and the skills of the helpdesk staff.  Moreover, it also depends on external factors such as organizational culture, business expectations, vendor response times and other external interfaces.

Once a process is established, however, local context is deleted and the process is presented as being universal. The key point is that this is an abstraction – the process is presented in a way that presumes that the original context does not matter. However, when one wants to reproduce the process in another environment, one has to reconstruct the context. The problem is that this is not possible; one cannot reproduce the exact same context as the one in which the process was originally constructed.  Consequently, the standard  has to be tailored to suit the new situation and context. Often this tailoring can be quite drastic. Further, different units in within an organisation might need to tailor the process differently: the customisations that work for the US branch of an organisation may not work in its Australian subsidiary. So one often ends up with different organisational units implementing their own versions of the standard.


Related to the above point is the fact that standards are incomplete. We have seen that standards omit context. However, that is not all: standards documents are generally written at a high level that inevitably overlooks technical detail.  As a consequence, those implementing standards have to fill in the gaps based on their knowledge of the technology This inevitably leads to a divergence between an espoused standard and its implementation.


Two people who read a set of high-level instructions will often come away with different interpretations of what exactly those instructions mean. Such differences can be overcome providing:

  1. Those involved are aware of the differences in interpretation, and
  2. They care enough to want to do something about it.

These points are moot  Firstly, people tend to assume that their interpretation is the right one. Secondly, even if they are aware of ambiguities,  they may choose not to seek clarification because of geographical, language  and other barriers.

Other factors

Some may argue that it is possible to work through some of the problems listed above. For example, it is possible – with some effort – to reduce incompleteness and ambiguity. Nevertheless, even if one does this (and the effort should not be underestimated!), there are other factors that can sabotage the implementation of standards. These include:

  1. Politics – It is a fact of life that organisations consist of stakeholder groups with different interests.  Quite often these interests will conflict with each other.  A good example is the outsourcing vs. in-house IT debate, in which  management and staff usually have opposing views.
  2. Legacy – Those who want to implement standards have to overcome the resistance of legacy – the installed base that already exists within the organisation. Typically owners and users of legacy systems will oppose the imposition of the new standards, first overtly and if that does not work, then covertly. Moreover, legacy applications make demands of their own – infrastructure requirements, interfaces, support etc., each of which may not  be compatible with the new standards.
  3. FUD factor – Finally, there is the whole issue of FUD (Fear, Uncertainty and Doubt) caused by the new standards. Many IT staff and other employees view standards negatively because they represent an unknown. Although much  is said about the need to inform and educate people, most often this is done in a half-baked way that only serves to increase FUD.

 In summary

Although the implementation of corporate IT standards can reduce an organisation’s application portfolio and the attendant costs, it does not reduce complexity as much as managers might hope.   As discussed above, non-universality, incompleteness and ambiguity of standards will generally end up subverting standardization (see my post entitled The ERP paradox for an example of this at work).  Moreover, even if an organisation addresses the inherent shortcomings of standards,  the human factor remains:  individuals who might lose out  will resist change, and different groups will push to have their preferred platforms included in the standard.

In summary:  a standardized IT environment will remain a mirage, tantalizingly in sight but always out of reach.

Written by K

September 16, 2011 at 5:53 am

6 Responses

Subscribe to comments with RSS.

  1. I guess one of the main goals of standards is for those who have standard jobs to have a standardized environment in which to do that. It’s very reminiscent of Taylor’s “Scientific Management” process, assuming that management can define the “one best way” to do a thing and then dictate to the masses how it should be done, chopping off whatever edges fall outside the lines (along with any original thought as well). It’s a very “Theory X” concept, in which all computers must be maintained by the organization, so rather than figuring out “how can I make these people more productive?”, they think “how can I reduce the cost of maintaining these computers?”


    Steve Wilheir

    September 16, 2011 at 6:31 am

  2. Steve,

    Thanks for making an important point. Standards are often couched in the language of scientific management. Indeed, the notion of standardisation is itself a key tenet of Taylor’s management philosophy. Further, as you point out, cost reduction is a key justification for standardising corporate IT environments. However, even if this is achieved, it generally comes at the cost of overall reduction in productivity of the organisation.





    September 16, 2011 at 10:35 pm

  3. Most Key Corporate Stakeholders would most probably shudder at the contents of your article. However, I feel that in all topics we need to evaluate the facts of both sides to achieve innovative evolution. I agree that a number of the points raised in your article represent reality, however we should be clear that Corporate IT Standards fulfil largely the goal of achieving economic optimisation within a competitive business world, together with optimising resource productivity and development. I do not believe that it sets out to be the ultimate answer, but we can use the learning’s from the above experiences to innovate and evolve the concept of Corporate IT Standards to achieve better collaborative outcomes. Corporate IT Standards can provide the “direction” with Corporate then relying on its innovative skilled resources to innovate based on local experiences to build the road. Thanks for a very informative article K.



    September 19, 2011 at 5:30 pm

  4. J,

    Thanks for reading and commenting on the piece. I agree, the question of standards is a controversial one: the economic objectives of implementing standards are largely achievable but they come at a high cost in terms of local productivity and effectiveness. As you suggest, the solution lies in developing collaborative approaches to implementing standards – approaches that attempt to reconcile the differences between local and corporate interests. The key to successful rationalisation of IT lies in building on local experiences rather than attempting to replace them.

    Thanks again for a thought-provoking comment.





    September 19, 2011 at 5:42 pm

  5. I don’t know where you get the notion of standards that you’re complaining about. At the very large company that I work for, we have a hierarchical standards structure with at least four levels: corporate standards of business conduct (required by Sarbanes-Oxley), IT Policies that specify general principles, IT Standards that specify how those principles are realized in specific directives, and Specifications that provide technical details, e.g the precise values to set for the configuration options on specific products. These are all backed up by a use case analysis and ongoing gap analyses with a planned update program that revisits every document on an annual schedule.

    The purpose of standards document is to create categories and define crisp boundaries where there were none before. The fact that there are multitudes of individual situations that are not individually treated by standards is not a problem with standards, it’s a feature. Individualized treatment can be just as bad. Our standards are far from one-size-fits-all; in fact some of them have so many combinations that people can’t figure out which one applies to them, and we’ve had to create knowledge-based tools to help people figure them out. In government, those tools are called “lawyers.”



    October 23, 2011 at 3:10 pm

  6. Dean,

    Thanks for a very interesting perspective. I agree with what you are saying about boundaries and categories, as long as the they are drawn up consultation with folks on the ground and can be redrawn as needed to fit an evolving IT landscape. From what you have mentioned, this appears to be what happens in your organisation. Unfortunately, in many cases standards are are applied in a top-down manner with little consultation or concern for local needs and conditions. Further, they are assumed to be universally applicable, unambiguous and complete (insofar as the organisation’s current IT landscape is concerned). It is such situations that I’m referring to in the post.

    Thanks for taking the time to read and comment – I truly appreciate it!





    October 23, 2011 at 8:42 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: