I’m frequently asked the question, “how should IT be organized?” Let me start by saying there is no right answer, at least no answer that’s right for all situations. There are a lot of different aspects of the IT organization issue, and I address some of them in this article.
Where should IT report?
Where IT reports in a company is directly related to how IT is viewed in that company. If IT is viewed as absolutely key to the future success of the business, then IT will usually report to the CEO or President. If you’re in a manufacturing company and IT is critical to the management of the manufacturing and manufacturing engineering processes, then IT might report to the executive in charge of manufacturing or operations. If IT is viewed as a way to automate accounting systems and manage PC purchases, then IT will typically report to the CFO or even the Accounting Manager.
According to a joke I once heard, you can always tell when the head of IT reports to a financial department because the company knows to the penny how much it’s losing. The idea behind the joke is actually pretty accurate: a company which focuses its IT efforts on accounting won’t be putting technology to use in creating and optimizing revenue or profit, but it will be able to track its losses accurately.
Where does IT report in your own company or organization? If you’re in IT and you’re not happy with the answer, then you’ll have to convince your company’s executives that IT can serve a bigger role. Just bear in mind that the bigger role may require a more experienced senior executive as head of IT. If you’re in charge of IT and your own personal limitations are holding the IT organization back in its reporting relationship, then you’ll need to gain some experience and training, or you’ll be left behind by your own organization.
Should IT be Centralized or Decentralized?
I talked about this question in my June, 2005 newsletter. Most companies go through cycles of centralization and decentralization unless they arrive at a compromise that seems to satisfy everyone. Centralization offers economies of scale, and decentralization offers better responsiveness to user needs. If you’re lucky, you’ll figure out how to centralize the aspects of IT that need economies of scale (e.g., purchasing or standards) and decentralize the parts of IT that need more user responsiveness.
Should IT reporting be split? Matrixed?
Some companies don’t have a single IT organization; instead they have divisional IT or departmental IT. They may also have different parts of IT reporting to various functional managers, for example infrastructure management and system maintenance to someone like a COO (Chief Operating Officer) and new projects reporting to the various departments sponsoring the projects.
Matrix management offers a way to split the IT organization while keeping it together at the same time. Under matrix management, each IT manager has two bosses: one functional boss in a user department who provides functional leadership and direction, and another technical boss in the IT organization who provides technical leadership and direction. Picture a matrix as a rectangular table of numbers with rows and columns, only in this case the numbers represent the IT managers, with a manager’s leadership provided from both the row (functional) direction as well as the column (technical) direction. The functional leader makes sure that the manager is doing the right things for the company, and the technical leader makes sure that the manager is doing things right (i.e., doing them using company standard technology, tools and techniques).
Although matrix management offers a theoretical way to balance functional and technical needs, many companies have trouble making matrix management work. When conflicts arise between the two leaders, it’s not always easy to figure out the most reasonable solution, and often one of the sides of the matrix becomes much stronger than the other. When matrix management works, it works well. But when it doesn’t work, it confuses the employees who are caught in the middle between two opposing forces.
If the IT reporting relationship is split, what should be the basis of the split? User oriented? Technology oriented? Project oriented?
I didn’t mention reporting basis in my June, 2005 newsletter, but this goes through cycles as well. There are good reasons to organize a department in a certain way. A user-oriented department is more attuned and responsive to user needs. A technology-oriented department is more effective in implementing a new technology (e.g., RFID) that requires focus on issues with the technology itself. A project-oriented department is best for organizing a group of people brought together solely for the purpose of building and implementing a major new project.
All of these types of organizations make sense in specific cases, and that’s the best way to use these organization types: for specific cases. Compare this type of organization to the group of people who create a motion picture. The organization doesn’t exist before the movie, the organization doesn’t exist after the movie is done, it just exists for the duration of the production process, and it’s optimized specifically for that movie. Similarly, you can put together temporary teams to accomplish specific objectives for your company, and then dissolve the teams (moving the people to other teams) when the objective is accomplished.
Although temporary teams work great, I do not favor the idea of permanently splitting an IT organization along user or technology lines. When you make such teams permanent, the organization begins to suboptimize itself around the lines of the split, and the organization responds poorly to overall change. So my preference is to create teams for specific purposes but to leave the teams in place only long enough to accomplish their objectives.
What should your IT department look like?
You know the answer: It depends. You already have an IT organization (even if it’s just a few people), so you have a starting point for making improvements. There’s no “right” organization, so you choose the best compromise between economies of scale and user responsiveness, focusing your employees on the things that matter most. That best compromise is likely to change over time as the players change and as the needs of your business change. The key is to listen to feedback about the performance of various parts of your organization, and to make your organization better as a result of that feedback.
In my own experience I’ve found that some of the more routine aspects of IT like infrastructure management and support tend to benefit from being pulled together across departments. And if you want your various systems to work together and share data or objects, then standards for data and software should be managed – or at least coordinated – centrally as well.
Projects, on the other hand, tend to be primarily associated with specific sets of users, so you need to do what it takes to build a strong relationship between the users and the project team. That way the project gives the users what they need, and the users feel confident during the project.
Although having projects report to the user organization will achieve this result, it tends to deemphasize the technical side of a project, and you can end up with a project result that may not fit well with other systems. There are alternative ways to build a strong relationship between project teams and users without changing the organization structure; sometimes you can build the relationship just by physically moving the team members into the area near their users, or by having the IT people on the team spend more informal time with the users.
The key is to end up with an organizational structure that allows project functional requirements to be determined in cooperation with the people who will use the results of the project, while project technical standards remain in the hands of a (usually central) group that looks out for the technical needs of the overall company.
The Fundamental Rule of Organizations
People who aren’t satisfied with the service they’re getting like to change the reporting relationship of the service organization so that the service organization now reports to them. In this way, they feel more in control of the service. On the other hand, people who are satisfied with the service they’re getting usually don’t care where the service organization reports.
If you keep your customers satisfied, then you can organize any way you like. Just pick an approach that seems to work, and adjust it as required by changing conditions and projects.
Related Posts and Articles
- “How to Become a CIO,” from December, 2005, describes the 8 qualifications you’ll need if you want to become a CIO
- “Why Middle Managers are Important,” from January, 2005, describes the 4 key aspects of a manager’s job.
- “10 Rules for IT Job Success,” from August, 2006, provides some career advice that I wish I had been given a long time ago