What are the most common IT organizational problems? We list them here and tell you why they're causing complications

November  1997

This month we start a Q&A on IT's biggest organizational challenges. What are they and what makes them so problematic? (950 words)

Mail this article to a friend

We thought we'd try something new this month and change the format of this column to a Q&A. In this first segment, we provide a brief outline of answers to one frequently asked question and give you more detailed answers next month.

So let's get right to it.

Q: What are some of the most common organizational issues/problems facing IT?

A: I've performed hundreds of infrastructure reviews providing analysis on people, process, and technology issues over the past few years, and the outcome is always the same: recommendation to restructure the organization. The main three categories are:

1. People: Organization, culture, training, mentoring, HR, customer satisfaction, etc.
2. Process: Change control, problem management, capacity planning, production acceptance, etc.
3. Technology: Architecture, system management tools, etc.

You would think that after decades of bi-yearly reorgs IT would have things more under control. Guess again!

Executives ask for help in implementing the right processes to make their shops more efficient, and it's always difficult to break the bad news to them -- it's impossible to implement processes without understanding and resolving the people issues (cultural differences) first. This always starts with the organizational structure.

Another problem these executives were facing was the lack of clear-cut support responsibilities. With each and every client/server application they were deploying on their corporate networks it was getting more and more difficult to understand who did what to whom and when. They quickly (and painfully) discovered how complex this new networked era has become.

You're not alone
Here's a compact list of the most common problems:

Organizing by technology: Many shops organize to focus on a particular technology (i.e. mainframe, NT, or Unix. This is done primarily to make sure there is no degradation of service to the corporation's legacy environment (usually the mainframe.) This causes finger pointing, poor moral, duplication of processes, duplication of efforts for the analysis/implementation of system management tools, lack of enterprisewide initiatives, poor communication, and lack of resources.

Not having an architecture/planning function at the CIO level: At certain companies this function would be buried in the development or support organization. This always causes preferential treatment with the organization they report to.

Architecture/planning function becoming too large: In certain companies this group would start developing and implementing the latest and greatest with the intent of turning it over to applications development or operational support. But all development efforts usually occur in a vacuum without involving either group until the system is already in production mode.

Architecture/planning function not focusing on its original mission: The attention should be equally divided between business, infrastructure, technology, and similar businesses.

Having multiple executives responsible for global support: This causes major headaches and problems when adhering to corporate architecture, standards, and guidelines. They will do whatever makes sense for their region. The political atmosphere really heats up, and in most instances, all these executives care about is pleasing their own customers in whatever manner makes them look good.

The help desk is not properly organized at the enterprise level: Many times this function is buried within the LAN, desktop, data center, operations support, or network groups. Once again this causes preferential treatment (better service) to the group it reports to.

IT not aligned with the business: It's just in its own little world still operating as if it was in the mainframe days. This causes poor communication practice not too mention poor customer satisfaction ratings.

Infrastructure support group not structured in the most efficient manner to take advantage of supporting a heterogeneous environment with limited resources: Each infrastructure assessment starts out by interviewing key personnel to determine the most critical issues. One of the most common complaints is the lack of resources. Most of the time this cry comes from IT shops that are organized by technology.

Confusion on how to effectively structure desktop and LAN support: Should they be combined or kept separate? What about the LAN? Should the WAN and LAN be combined?

Production control not defined to support the enterprise: This old group evolved from the legacy world back in the sixties and seventies. They're still around, but unfortunately they haven't changed with the times. The primary role here was to schedule resources, own change control, and act as second-level support for mainframe types of problems. So what's the new role for the nineties and into the next millennium?

Confusion as to where to organize the database administration function: Many IT shops structure this function under applications development, and in some shops (very few) this function will reside with operations support. In the world of network computing it's critical to have this function in the right area.

Applications support: Should there be a separate function for distributed computing, or should this function reside under the applications development function? The problem is that in most shops the applications support person is the same person doing the coding. This could potentially cause delays in systems development.

Where should disaster recovery reside? This function has been shuffled around in more places than any other function -- yet it is one of the most critical.

I've said it before, and I'll say it again. You cannot implement effective processes until organizational issues have been resolved. In next month's column we'll give you the answers and illustrate that elusive organizational structure for better network computing management.

Resources

• Full listing of Unix Enterprise columns in SunWorld http://www.sun.com/sunworldonline/common/swol-backissues-columns.html#unix

About the author
Harris Kern is Sun's Open Systems Migration Consultant for NAAFO Market Development. Reach Harris at harris.kern@sunworld.com.

Harris Kern and Randy Johnson are authors of Rightsizing The New Enterprise: The Proof, Not the Hype and coauthors of Managing The New Enterprise: The Proof, Not the Hype, and Networking The New Enterprise: The Proof, Not the Hype. You can buy these at Amazon.com Books. Select the hyperlinks to learn more about each and Amazon.com.

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-11-1997/swol-11-unix.html
Last modified: