It defines 2 IT units:
- Infrastructure Services
- User Services
Internally, the two units would be structured as follows:
- Infrastructure Services
- Systems administration
- Server administration
- Multi-user application administration
- Networking
- Telecommunications
- User Services
- Student support
- Classroom, lab and event support
- Faculty and staff support
- Faculty/staff tech support
- Training coordination
- Software development
- Web development
- Application development
- Graphics services
- Service management administration
- Helpdesk administration
- Asset management
- Service level agreement administration
- Directory services and user account administration
- Security staff would report directly to the President, as auditors do. If need be, they can be housed in one of the units.
- Dr. Sethna has made it clear that the focus of our efforts must be on how best to provide the IT services we need, want, and can afford.
- The two top-level units would report to the VPAA.
- Technical decisions can and should be made by the IT units, but strategic and political decisions should be made by the University administration, not by technical staff, even at the level of a director or CIO.
- The VPAA, President, PAC, and TPC would, of course, rely on technical expertise provided by the units to inform their decision-making.
- All IT staff would be included in the reorganization.
- There are some four or five positions currently classified as IT positions that may be better reclassified as specialized "super-users" whose duties depend heavily on IT, on the model of Distance Ed staff members.
- The duties of some IT staff will change, but no jobs would be lost in the reorganization.
- This is version 0.5 because, over the next month, we will have many discussions on how to improve the structure that will take it through versions 0.6, 0.7, etc.
- I expect that the "go live" version would be 0.8 or 0.9, in recognition that reviews during the year after implementation will point out the need for some revisions.
- I plan to have that version ready by the end of the month, or early November at the latest.
- To foster the discussion that will yield the subsequent versions, I plan to
- go to PAC and deans meetings,
- hold open meetings,
- maintain this blog,
- meet with whatever departments or units want to talk about the plan,
- exchange emails,
- keep my Gmail account open for those who are afraid to speak publicly or use campus email,
- meet with the TPC and the TCC, and
- do whatever else people think will help keep communication flowing.
- An implementation plan will follow as the reorganization plan assumes a more final shape.
- I've already started thinking about implementation, but don't want to get too far ahead of the structural planning. I welcome your advice about implementation, too.
Thanks, and please start sharing your wisdom,
Will
13 comments:
ITS mangers received your request to meet at 4:54 this afternoon. We will determine if 11 and/or 3 on Wed. works for the majority, and let you know tomorrow. --Kathy
I realize this is just the first iteration, but the major thing that sticks out in my mind at this point is the overlapping between the two groups, for which I see no provisions. The boundary between the doughnut hole and doughnut ring has been brought up a number of times, so I expected to see at least a blurb on that.
For example, the server administration aspect of the infrastructure services unit seems to share responsibilities with items in the user services unit.
Specifically, directory services and user account administration are often a function of server administration. While some systems are complex enough that the physical upkeep of the server is distinct from the management of user accounts, this is not always the case. Directory services and user account administration on our Windows domain controllers are so closely integrated with Windows server administration that separating the two seems quite inefficient. Creating two positions/departments responsible for overlapping tasks, each reporting to a different unit head, is exactly what we're trying to avoid.
Other comments:
- In this two-unit scenario, I believe that security staff would best fit in under infrastructure services.
- Before changing the duties of some IT staff, will the staff members' knowledge, skills, and current responsibilities be fairly assessed to determine which people to shuffle? I'd hate to have a reincarnation of the FLSA proceedings where staff members are judged without their input.
- Helpdesk administration falls under user services, but often times resolving a helpdesk request/problem requires assistance from systems administrators and networking personnel. There must be established lines of communication for involving infrastructure services in resolving user services helpdesk issues.
- A number of employees, myself included, currently perform tasks that fall under infrastructure and user services. Some of these employees are intimately familiar with or have even developed "backend" operations such as email systems, spam filtering, and custom authentication mechanisms. Moving all of these people over to infrastructure services will in my mind create a bloated infrastructure services unit; however, their absence will require someone else to learn a system with which they might be wholly unfamiliar. Unless some provision is made to have people "on the rim" between the doughnut hole and the doughnut ring, we can expect a lot of initial duplication of efforts and loss of efficiency.
According to your town hall meetings you have reviewed several models prior to your decision to select this as the model for success in IT.
With that in mind, could you please cite some examples of universities that have employed this model and discuss the successes they have achieved as a result of operating under such a structure.
Your plan presents a nice text book picture of an IT organization; but if I understand your proposal, you have 2 separate organizations (Infrastructure & User Services) that would be separate governance structures headed by 2 people that would report to you? Your plan to me anyway seems to promote a "solution" which technologists tend to do a lot, but I don't fully understand the problem(s) that your solution is trying to resolve or address. I assume most organizations organize their structure around functions as I assume your proposed chart indicates, but is it IT functions or business functions that is desired to organize IT's new structure around? Organizations/structures also have to be organized around the skills/capabilities of the key managers and critical people that you have though.
As Andrew stated, we (UWG) have a lot of people skilled in both sides of these units so I see a lot of people having vital roles in both the units you present. With your proposed organization and only 2 units reporting to a CIO(?), it seems to me you are promoting a very "tall" as opposed to a very "flat" organization (see
http://en.wikipedia.org/wiki/Organizing for definitions).
I don't have any magic answers or solutions, but I would prefer to see "multiple" structures for UWG's IT organization. What I mean by that though is that I think employees need to be grouped by common skills for training and operational support purposes, but I would like to see the IT organizational structure be able to accomodate dynamic groupings of people to tackle the problems/initiatives deemed critical to UWG Management.
Maybe these web pages:
http://en.wikipedia.org/wiki/Organizational_studies
http://www.analytictech.com/mb021/orgtheory.htm
might help provide some insights on some organizational studies for UWG to consider.
You have a gmail account to allow people to contact you without fear of being found out by current IT managers. I wonder, though, if that is really a concern. The nature of this reorganization process with you having essentially absolute power has effectively neutered the current IT managers. I would be more concerned about how current IT personnel can voice their concerns/criticisms about your reorganization plan without fear of reprisal. It is you who is deciding the future of these IT personnel. How anonymous are these postings? Can the PC of origin be traced by the blog service being used?
From the 2005 audit report-
"There was no effective IT governance structure in place to coordinate and ensure the best use of IT technology across the University. There was no comprehensive strategic or tactical IT plan in place. Cooperation between many of the various IT groups within the University was very poor. This IT Governance finding is a repeat of findings from the State of Georgia EDP Management Audit of July 1997."
How does the proposed structure address this finding?
If your charge was to improve communication across our IT structure then why would you separate application developers from the systems on which they develop? You have placed 'multi-user application administration' under infrastructure yet the people developing these applications are in user support? I fail to see the logic in such a move. While effective communication between the user requesting a new application and the developer is critical, it pales in comparison to the amount of coordination that goes on between system administrators and application developers.
If there are any system admins or software developers on campus with a different point of view, I'd love to hear it.
It seems that ITS is looked upon as a very rigid black & white kind of structure. There is actually a lot of grey area and is that taken into consideration?
It was made clear to us yesterday that up to a certain point people who leave may not be replaced. It's probably very possible that by pigeonholing people through this new infrastructure, there might be a loss of interest with consequent departures. Even with the potential or promise of jobs not being lost in this reorganization, if people who chose to leave are not replaced, that somewhat equals the same end result i.e. loss of jobs.
Maybe this is a very naive sort of statement ... It is really disheartening to me that people i.e. my colleagues feel they have to stay anonymous for fear of their manager's ... how can I say this ... wrath?! It would seem that if people want to speak out it's very simply because they care and that is something that should be encouraged.
Please define what you mean by “Asset management” under the bullet Service Management Administration. Are you referring just to IT assets - only a portion of the work involved with the University’s assets? Is it the intention of the reorganization to control all aspects of technology equipment from tagging equipment to disposal of technology equipment surplus?
Just throwing out organizational charts of sister IT organizations:
BOR OIIT org:
http://www.usg.edu/oiit/about/
GSU IS&T org:
http://www.gsu.edu/ist/units.html
GIT OIT org:
http://www.oit.gatech.edu/inside_oit/organizational_chart/overview.cfm
UGA EITS org:
http://www.eits.uga.edu/documents/pdf/functionalorgchart.pdf
Kennesaw State ITS org:
http://its.kennesaw.edu/about_its.htm
(one is actually not posted currently because they are going
through a re-org per the web site anyway)
Ga Southern ITS org:
http://services.georgiasouthern.edu/its/depts.php
Valdosta IT org:
http://www.valdosta.edu/it/documents/orgchart.pdf
IT Reorg 0.5 Response
Most IT personnel at UWG are currently straddling the fence between the functions of the two IT units you propose, infrastructure and user services. This fact has major, perhaps devastating, implications for our future should this plan become implemented. Consider ITS as an example - we have a structure which interleaves these functions, if not responsibilities, all the way down to the individual personnel, top to bottom, regardless of any labels a section or person may have. Your categorization of functions, infrastructure and user services, represents an increasing division of IT at the institution, because you are creating segregation by placing these functions into two discrete units. This division may be a valid organizational chart for some institution somewhere (if so, please present examples), but it is practically unworkable here at UWG.
Clearly, your two categories of services are valid for classification purposes when it comes to specific duties which personnel perform. These categories are ill-suited to classification of personnel in terms of skills and abilities - personnel represent a collection of skills which come from both of these two, primary categories. The individual job descriptions of IT personnel at UWG also defy classification into these two categories. From your stated assumptions and notes, it is clear that one way you intend to resolve this is by altering job duties for certain positions. Logically, this must be a solely subtractive process, wherein people lose duties from the other category, reducing the skill set required for the position in the process. This action devalues the position, and ties the hands of the institution in terms of what it can expect from the employee in that position, now or in the future. Hiring specialists is not the way to do more with less, in fact it is quite the opposite. This is one negative implication of making infrastructure and user services discrete units.
Other problems with narrowing job duties are more touchy to discuss, but must be stated. UWG currently has the best collection of IT personnel we've had for the past 20 years (yes, I've been here that long, in one form or another). We are inarguably underpaid. And yet, we stay - why? I can't speak for every reason and every person, but I can tell you a few which are common to most of us. We work here because of the unique challenges of scale and diverse requirements that the institution offers. We live for the ongoing development of solutions to problems. Narrowing job duties will, for many of us, result in a reduced job satisfaction of varying degree. This is a legitimate concern - a job is not a job. Each of us, IT or otherwise, has job duties we enjoy and embrace, and duties which are accepted and performed because we know it's part of the job and needs doing. What do you think the response will be, if you remove all of the duties a person comes to work for, and leave them with the duties they perform because it is necessary? This will be a problem, because so many of our employees are performing both infrastructure and user services duties. Some people do not wake up excited about resolving user problems, and would be very unhappy to discover they are stuck doing that. Another person might be dismayed to find themselves relegated to the back room. The truth is many people remain at the institution, in part, for that 30 or 40 percent of their job duties which are gratifying to them. The institution has the right to change the duties which personnel perform, however it should do so only with extreme care and consideration of the ramifications. Harm will occur to the institution if we lose people (and their associated skills), and the effects will echo years into the future.
One aspect of efficiency in our current organization is the way we ensure core infrastructure is 'backed up' by multiple personnel. While one person may be responsible for a service, at least one other employee needs to be fully capable of stepping in. Since we are blessed with generalists, we take advantage of that fact, and the fact that our IT people are interested in being involved in different things, to provide for continuous coverage for core services. In your model, I can only assume that such cross-training would happen within each discrete unit, and not across, and that is a rather odd idea - to have people with skills....already paid for...that you can not use.
If the goal of this process is to increase efficiency by coalescing our IT personnel, and we are not intending to lose positions, it brings up this question - what about the management? If you don't reduce the number of managers, then you've done nothing - our structure has just as many branches as before, unless you have managers who are only managing managers (which would be unmanageable). There is an obvious implication that managers will be demoted, or working under their former peers, or no longer managing - there is just nothing else that can happen, logically. As in the case with altering employee job duties, there is a strong risk of loss of personnel due to intense dissatisfaction. This result would be no better than firing personnel outright.
Another difficulty I see with this structure is that the User Services unit will be, naturally, a client of the Infrastructure unit. Personnel who currently possess the ability to directly manipulate the back-end infrastructure and the user-interfacing component of services will no longer be able to take advantage of this efficiency. The same difficulty that exists with classifying people and job positions as one or the other also exists for the services we provide. Every service will involve both of these units - every service. Each of these units has a head with single point of responsibility and accountability, but this is an impossibility, since each unit supports services which are utterly and mutually dependent.
I do see a possible solution to several of these difficulties - change a few of the things you define as infrastructure. For example, there is nothing about server administration which is infrastructure, unless what the server is doing is supporting infrastructure. Servers are used, often, as part of solutions which are developed locally to answer needs. In other words, we perform "solution development" as well as "application development". It's the same thing, really - identifying the users' needs and satisfying them. Many of these servers are quite directly interfaced with users, are not part of the infrastructure, and are currently administered by people who are not exclusively server administrators. By modifying your classification slightly, you have the opportunity to avoid the personnel issues of changing job duties, and you do not lose the tremendous efficiency of employees capable of wearing multiple hats.
I would also like to hear your thoughts regarding what constitutes a technical decision versus a strategic or political one. Can you give me an example of a decision of any kind which is neither strategic, nor political? Obviously we are not going to decide non-technical things, but what technical decisions are not (or could not be made into) also strategic or political?
From the IT Audit of 2005
"Best practices in Universities the size and complexity of the University of West Georgia usually recommends the designation of a Chief Information Officer to coordinate and be held responsible for the status of Information Technology at the University.
It goes on to say:
We recommend that the University establish a formal definition of the charter, roles, and responsibilities of its information technology function, and that a single University department (i.e. Office of Information Technology) be charged with responsibility for:
• Establishing the long term strategic direction for Information Technology at the University in consultation with various units of the University
• Developing an annual one-year tactical plan that can be tracked and monitored based on a well researched and documented strategic plan
• Developing an overall Information Technology budget. Approving Information Technology expenditures above a dollar level to be determined by the President
• Creating, publishing and monitoring standards and procedures for the implementation and administration of information technology across campus
• Deploying and technically supporting the business critical application systems i.e. Banner / SIS, Financial Information Systems - PeopleSoft, Public Safety and others
• Defining, implementing and maintaining key common components of the University's information technology infrastructure i.e. networks, critical network servers such as name servers and directory servers, mail servers, virus signature servers and others
The current structure deviates from this only to the extent that distributed units have been allowed to develop their individual structures. These can be done in ANY structure, including the current structure. It is an issue of GOVERNANCE, LEADERSHIP, and DECISIONMAKING--NOT STRUCTURE....
Some of those comments are pretty long for a blog. Maybe discussions like that are more appropriate for a discussion board (hense the name)?!
Nedko @
http://www.nedkoko.com
Post a Comment