Over the years I have had the opportunity to experience IT in the organization as it has transformed itself from the "glass house" through the PC "revolution;" client servers; web-centric computing; and now the amalgamation of all of these evolutions as IT strives to be a true "business partner."

Interestingly, for those in the government organizations that I have come into contact with in the last couple of years, the concept of IT as a "business partner" is more of a figment of the imagination than a reality.

If you asked people in the departments that IT was serving what their relationship with IT was like, they would say that IT was a business partner in the same vein that the Soviet Union was a business partner to Poland, East Germany, or Czechoslovakia during the Cold War.

One characteristic view that users in these organizations have about their IT department is that it will not allow any IT operations of any kind to exist outside the IT department's control. And should such "rogue" activities arise, they are to be squashed or consumed.

Another common view of users was that IT departments were monolithic and unresponsive - filled to capacity with bureaucratic "goodness" to ensure that each project progressed at glacial speeds.

Of course, these two views led to a lot of user frustration. From their perspective, if the IT organization was nimble and responsive to customer needs, they wouldn't need to engage in rogue activities; and to make matters worse, they felt that taking matters into their own hands was the only way to get around the bureaucratic bottleneck blocking progress on their various projects.

The end result of these competing views is an angry customer base that is frustrated by IT's lack of response and its attempts at squashing the users' attempts at helping themselves.

Politburo IT

Why does this happen? I speculate that the above situation arises when IT remains stuck in its legacy as a "glass house" mainframe shop, or from IT's reaction to a decentralized computing environment that seems to have gotten out of control.

In either case, the end result is a heavy-handed, centralized IT shop that rules with an iron fist. This kind of IT department is likely to struggle in building a true partner relationship with its end-user departments.

We all know the benefits of centralized IT units: Procurement of hardware and software is possible on the broadest scale within the organization, and centralized operations generally produce substantial economies of scale. Additionally, a centralized staff eliminates redundant functions, and there is a greater adherence to standards and a unified vision.

Conversely, in a highly centralized IT department, there are problems like the ones mentioned above. Some of these are: tendencies towards bureaucracy, lack of responsiveness, and decision-making in a vacuum.

The alternative to this is a completely decentralized IT unit--agile and responsive, in tune with the needs of the business, and more tightly integrated with business goals and objectives.

Yet purely decentralized IT structures also have drawbacks, such as duplication of effort, lack of standards across the organization, islands of excellence at the expense of other departments, higher total procurement and operational costs, lack of integration, etc.

The decentralized centralized IT group

I have always been a big believer that a balance can be struck between completely centralized IT and completely decentralized IT--hopefully deriving the benefits of both.

In my opinion this balanced IT structure has "enterprise" functions being performed by central IT such as: data center, network and infrastructure operations, e-mail, procurement, standards architecture, and cross-departmental application development.

While department-level functions include help desk operations, departmental application development (up to a certain size), and IT strategy and planning for the department. All of these activities coinciding with standards which they help develop along with central IT and a strong governance committee.

In order for this hybrid approach to work though, there has to be a strong sense of cooperative and collaborative management at the level of the CIO and with the departmental IT management. I like to view this approach as a representative government model where the departments actually have a say-so in their IT operations.

Ultimately, there is no "right" answer to how IT should be structured in every organization. There are success stories for each model (which I am sure many readers of this blog will point out). And we have to take into consideration the influence of the culture and structure of the organization as a whole when determining the optimal IT configuration.

Yet I am willing to bet that at the end of the day, those organizations which choose a model which is more democratic in its structure and processes are more likely to end up as true business partners to the organization.

It Management White Papers

• Government Web Pages and Information Management - University of Wisconsin
• Identity Management - National Electronic Commerce Coordinating Council
• From the Backroom to the Boardroom: Compliance Drives a New Era in Records Management - Information Today
• Urgent Federal Government Management Problems Facing the Bush Administration - Council of Better Business Bureau
• Acquisition by Government’s of an Integrated Financial Management System - International Management Consultants
• Perspectives (and Retrospective) on the Presidents Management Agenda - BetterManagement.com
• Framework for Federal Financial Management Systems - Financial Systems Integration Office
• Performance Management - Making It Work - BetterManagement.com
• Property Management Systems Requirements: Checklist for Reviewing Systems Under the Federal Financial Management Improvement Act - Government Accountability Office
• Content Management & Document Management for Government - Documentum