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
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!