New House Rule: Non-Compliance is now Mandatory

In Circumventing the CIO - What's the Harm?, Andy Blumenthal enumerates some of the potential issues when technology is introduced outside of normal IT channels.

In simplest terms, what Andy describes is a classic conflict between IT and the rest of the company. To complicate matters, the ever increasing consumerization of IT makes it easier to bypass the traditional list of project hurdles imposed by most IT organizations.

I am, however, somewhat dismayed at the list Andy provides. Despite his reminder about striking a balance, the list might lead one to believe that there is no room for risk in business. On the contrary, business is about managing, sometimes leveraging, risk. It is perfectly reasonable to expect that business can tolerate a certain amount of non-compliance to the risk aversion common in IT. In fact, there are circumstances where it must be part of a core business strategy. The key, as always, is to ensure the level of risk aligns with the needs of the enterprise.

If the level of non-compliance is out of alignment with business needs, the problem still reduces to one of conflict, rather than non-compliance. Regardless of whether IT is overly strict or the user is overly cavalier, the conflict is best served if IT starts adopting a posture more in line with basic conflict resolution/management/transformation concepts.

To be fair, Andy works in an industry familiar with bureaucracy and the command-and-control model. At the same time, it seems all IT organizations incur another type of risk if they do not allow a certain amount of free movement around the edges.

(Bonus points for fostering and participating in that free movement around the edges)

The Pendulum Flows

In Lamps, lighting our way..., Mark Masterson mentions the age old topic of centralization vs. decentralization. The pendulum swings.

But wait...

Is the vacillation as real as it appears?

Is it more appropriate to view it as a one way flow, with technology generally moving from the edge to the center?

Here's the idea.

There is a relatively steady amount of centralized IT technology. The amount is usually governed by some high-level metric such as percentage of revenue. This amount varies by company, but tends to act as a top-level volume knob for centrally captured budget dollars spent on 'IT'.

The decentralized introduction of technology at the edge is governed by two primary factors - a threshold dollar amount and the degree to which a centralized resource can provide results to the edge.

Since, by definition, a central IT can only provide a finite amount of capability to the edge, there is always an amount of unfulfilled demand.

Once the cost of a new technology drops below a threshold dollar amount, the edge is now faced with the possibility of acquiring the technology. This is particularly true if the new technology can bring a measurable value to the edge. Profits tend to trump politics.

A sufficiently large level of adoption of a particular technology at the edge will gradually prompt a centralization of that technology. Meanwhile back at the top-level PoR volume knob, older technologies are pushed out to make room for the new.

One might argue that there is still a pendular swing, with the power of technology shifting between the edge and the core. It seems reasonable to wonder if this is merely an artifact of our own interests in particular classes of technology, or the result of natural changes in the rate with which edge technologies migrate to the core. Would we still view it as pendular if we accounted for all technologies subject to the phenomena?

What do you think?

Ions ate us for lunch

CIO Insight posted an interview of Bob Otto , the retiring CIO/CTO of the US Postal Service. I found the interview from a linked posted by Bob Gourley in How is the USPS like your IT enterprise?.

Bob Gourley quotes a segment that identifies Bob Otto's three guiding principles, summarized below in bullet form.

• Standardize everything
  If you find a process you like, standardize it
• Centralize everything you can
  If you have services in five different places and you can centralize them, you will have reliability, predictability
• Simplify
  The computer has taken over your life, so I want it to be intuitive [for people to operate and manage]. I also test my own dog food.

Distilled further, we have standardization, centralization, and simplification.

Sigh...

These seem quite reasonable on the surface, but let's think about them for a moment or two.

Standardizing on a process you like? This presupposes that what you like is actually the best fit for the organization. I suppose one could assume that "like" includes this as an assumption. Hmm...

Centralize everything you can? This presupposes that all services are best delivered centrally. I agree that increased predictability is likely, but I question reliability and a small list of other potentially important attributes. Hmm...

Simplify? Yes - we have one point of agreement. Generally...

Hmm...

Still convinced these three principles are sounds? Perhaps they are true for some environments. A slow growth company in a mature market primarily requiring maintenance activities might benefit from these principles. Very few business, however, can assume these conditions.

Still convinced? Let's combine these principles and see where it might lead us.

We are newly appointed as CIO of example.com.

We discover a variety of seemingly duplicated services spread across the landscape. Hungry to show value to the business, we centralize them to achieve reliability and predictability. We even gain some economies of scale, so we get some cost savings to boot.

As part of the centralization, we decide one of the service implementations has the most efficient and effective processes. This becomes the standard process for all of the newly centralized services.

As we centralize, we notice several portions where some simplification can occur, so we do some process trimming. We've also eliminated some of the tasks performed by the once disparate services, so we're starting to see some dramatic moves towards simpler processes and systems. So far, so good.

We expect dramatic improvements. We might even expect some appreciation for our efforts.

For a time, we might actually receive the kudos for our accomplishments.

Then we notice a curious phenomena. The grumbling continues. Needs are not met. Changes are still required. Costs are still steep.

We investigate the situation.

We are shocked at what we find.

It turns out that our centralization bulldozing exercise cause some key functionality to get pitched overboard. The functionality confused the centralization task force, so they accidentally left it off the analysis spreadsheets.

We discover that our choice for most likable process as in fact the result of decisions made during a golf game. (the golf game immediately following one particularly frustrating day of difficult process discovery discussions).

Alas, the process simplification activities further exacerbated the problem. As it turns out, the process simplification team couldn't fit certain features into their model of a perfect world. (more 'inadvertant' deletions).

We also notice that our competitors have been watching our strategic moves, countering them with a strategy based on more balanced principles. We watch as our competitor eats us for lunch.