View source for Structuring the Enterprise IT Organization

<table border="3">
<tr><td>
    <table>
    <tr>
    <td width="60%"><font color="#246196">'''Welcome to the initial version of the EITBOK wiki.  Like all wikis, it is a work in progress and may contain errors.  We welcome feedback, edits, and real-world examples. [[Main_Page#How to Make Comments and Suggestions|Click here]] for instructions about how to send us feedback.''' </font></td>
    <td width="20%">[[File:Ieee logo 1.png|100px|center]]</td>
    <td width="20%"> [[File:Acm_logo_3.png|175px|center]]</td>
    </tr></table>
</td></tr></table>
<p>&nbsp;</p>

<h2>Introduction</h2>
<p>There are a variety of ways to structure the EIT organization. The right one for an organization is one that facilitates cooperation across the various EIT functions, but that makes accountabilities and responsibilities clear.</p>
<p>Early EIT organizations adopted a structure that is still sometimes found today. They divided responsibilities into functions described as Design, Build, Run, or something similar. While it seemed to make sense in concept at the time, it led to silos in real life &mdash; silos with walls between them, hampering communication and therefore effectiveness, as well as leading to finger-pointing across the barriers.</p>
<p>Another problem has been how to manage EIT’s relationships with individual users and user departments, while still maintaining the big picture needed for effective portfolio management and funding allocations. This was because primary communications with users were often limited to development activities at the project level and requests coming through the Help Desk. To some extent, the predicament was addressed by the addition of a project management office (PMO), which both housed a set of project managers and was responsible for aggregating project information. However, because these projects were generally only for application development, much of the work of EIT professionals was left out. This has most famously not resolved the issue of 80 percent of EIT spending going to “maintenance” which usually meant unprojectized work going through the Help Desk, but not overseen.</p>
<p>One approach to solving these problems has been to create ''business relationship groups'' that function in many ways like product managers in technology companies. The business relationship managers provide communication in business language with the user groups and coordinate activities within EIT to support their users. Another approach has been to organize EIT into product lines, where each product line group is responsible for a service (product) from concept to retirement.</p>
<p>The charts below give some idea of the variety of ways in which EIT has been organized. See if you can guess what sorts of problems these structures would solve and what problems they might create.</p>
<h2>Structural Diagrams</h2>
[[File:EITOperations.PNG]]
<p>'''Figure 1. EIT Operations'''</p>
[[File:SharedCommunicationServices.PNG]]
<p>'''Figure 2. EIT Services - Shared Communication Serices'''</p>
[[File:CustomerService.PNG]]
<p>'''Figure 3. CustomerService'''</p>