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, I find that for those in several of 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 the relationship between them and IT was like, they would say that their

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 operations of any kind can not 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 insure 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 were 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.

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.

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.

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!

Subscribe to the Executive Briefing Newsletter

Discover the secrets to IT leadership success with these tips on project management, budgets, and dealing with day-to-day challenges. Delivered Tuesdays and Thursdays

Subscribe to the Executive Briefing Newsletter

Discover the secrets to IT leadership success with these tips on project management, budgets, and dealing with day-to-day challenges. Delivered Tuesdays and Thursdays