Alternative user services structure

[Rob] Core or enterprise services should be centralized as much as technically possible and user support should be distributed as low as humanly possible. For example, consolidating the various servers in the distributed IT units that support non-unique functions like Windows AD, DNS, DHCP, email, anti-virus management, patch management, … Just doing these things alone would free up dollars and simplify the budgeting process; not to mention freeing up user support personnel to focus on direct support and less on the behind-the-scenes infrastructure. Very few servers should be left in the distributed IT units after consolidation barring a small number of unique platforms like RCOB MIS and CS lab systems for student projects.

[Leos] Leave the distributed IT support units where they are to continue providing localized services but have the heads of those units directly report to the director of ITS (or to a user services department head to oversee all the distributed service units who reports to the director of ITS). Combine all the localized helpdesks into one that then routes the calls to the appropriate units. Centralize, where practical, all of the distributed servers, DNS, etc.

[Me] We'll leave CIO discussion for another day, as I wrote yesterday.

• The kinds of centralized services Rob and Leos mention go along with what we've been discussing.
  
• To the extent possible, I'd like to see all servers that are connected to the network under the oversight of the infrastructure folks, with secure access provided, sort of on an ISP model, to the user support people and power users who need it.

• An alternate model for faculty/staff tech support:
  
• a faculty/staff support subunit, within User Services,
  
• localized support teams in that subunit.
• Version 0.5 had two subunits of User Services: faculty/staff support and classroom, lab and event support, with "cops on the beat" to provide localized support within those subunits.

This structure would

• keep day-to-day support close to the user,
  
• let users know that they still have "their" techies,
  
• provide the opportunities for cross-fertilization, cross-training, career development, and adoption of best practices we need.

Some things would need to be worked out. For example:

• Fitting in specialized services like training coordination and second-level A/V support.
• How best to provide localized support for Nursing and Biology, which are located away from the other Arts and Sciences departments.
• Providing extended hours of support.
• Providing backup when one team is swamped or short-handed.
  
• Newnan Center tech support.

What do you think of this alternate model for faculty/staff tech support as part of version 0.6?

On an interesting comment from Leos

Leos posted a thought-provoking comment. Here are some snippets and my thoughts on them:

• [Leos] Let us put a person in charge of IT at UWG and let us evolve an IT structure by fine tuning what works and fixing that which does not... There already is a director of ITS on campus. For once, let us let him do his job.
  
• [Me] The current structure doesn't make the director of ITS a CIO. We could change that, of course, but being a CIO isn't part of the current job description.
  
• [Leos] "Simply leave the distributed IT support units where they are to continue providing localized services but have the heads of those units directly report to the director of ITS (or to a user services department head to oversee all the distributed service units who reports to the director of ITS). "
• [Me] That, of course, would also be a radical change that also has great potential to "introduce as many new problems as it may fix."
  Also, most of the services provided by the distributed units are generic rather than localized. One advantage of changing to a functional structure would be that, by reducing the duplication of effort involved in providing those generic services, we could have the potential to offer new services.
• [Leos] "Let us put a person in charge of IT at UWG and let us evolve an IT structure by fine tuning what works and fixing that which does not."
• [Me] A CIO has advantages and disadvantages. So that we can stop rehashing the arguments, I'll ask Dr. Sethna as soon as he recovers from the BOR visit what he prefers. I'll draw up a list of the pros and cons before then and post them so that we're sure that I present a balanced list.

I want to examine Rob's comments from a few days ago, but I'm out of time, so I'll try to get to them later this weekend.

IT reorg: a solution in search of a problem?

A smart techie said to me after yesterday's open meeting that many people see the proposed IT reorganization plan as a "solution in search of a problem," so let me state the problem.

• The IT audit two years ago found a "lack of a functional governance structure" that will "continue to hinder the growth of Information Technology" at UWG."
  
• The audit noted that this repeated the finding from the audit of 1997.
  
• We responded by
  
• maintaining our existing IT units;
  
• adding the position of UTO to improve communication and coordination among those units;
• creating the TCC to provide a forum for that communication and coordination;
• shifting the focus of the TPC from day-to-day IT affairs to more strategic issues.
• Despite improved communication and coordination, these changes have not proven enough to solve our problems.
• We are therefore in great danger of receiving yet another significant negative finding when we are audited again next year.
  

I don't know what happens when a USG institution receives the same significant finding in three audits, but it can't be good.

Continuous improvement of IT

This post contains an outline of goals for the continuous improvement of IT at UWG . Thinking about how to achieve these goals was a major influence on my thinking about IT reorganization.

I'm going to take these to the open meeting tomorrow to get feedback on what I've missed or goofed up. Let me know if you see anything, too.

Five overarching goals:

1. Improve service to users
   
2. Increase efficiency
3. Improve security
4. Improve accountability
5. Improve budgeting and planning processes
   

Some areas in which to effect these improvements, in no particular order, with the relevant goals in brackets:

• User-service orientation [1, 4]

• Decision-making [1, 2, 3, 4, 5]
• Strategic
• Tactical
  

• Service desk (AKA help desk)
  
• Hours of operation [1]
• Problem resolution [1, 2, 4]
  
• Identification of shared and/or common problems [1, 2, 3, 4, 5]
  
• Single point of contact for all user support requests [1, 2, 4]
• Online knowledge base [1, 4]

• Quality of service [1, 4]
  
• Levels of service
  
• Variation in levels of service
• Specialized services
• Administrative
• Academic
  

• Faculty/staff development
• User training [1, 2, 3]
• IT staff training [1, 2]
• IT career development
• Cross-training
  

• Duplication:
  
• "Back-room" services like server administration, directory services [1, 2, 3, 4, 5]
• Computer lab and classroom management [1, 2, 4]
  
• Budgeting [5]
  

• Service management standards and procedures [1, 2, 3, 4, 5]
  
• Issue response and tracking
  
• Service-level agreements (SLAs)
  
• Operational-level agreements (OLAs)
  
• Service catalog
• IT asset management
• Hardware
• Software
• Licenses
  
• Change management
• Configuration management
• Version control (AKA Revision control)

• Standardization (where appropriate) [1, 2, 3, 4, 5]

• Project management [2, 3, 4]
• Process improvement
• Risk management
• Quality management (e.g., validation and verification, defect prevention, standards, best practices)
  

• Incident management [1, 2, 3, 4]
• Security incident management
  
• Bug tracking
• Disaster recovery
  

• Access control and authorization
  
• User access [1, 2, 3]
  
• IT staff access [2, 3, 4]

• Internal IT auditing [2, 3, 4]
  
• Network and software vulnerability assessments
• Intrusion detection and prevention
• Packet sniffing

• Coordination, communication, and IT governance
• IT/user communication [1, 2, 4]
• Intra-IT communication [1, 2, 3, 4]
• Clear definitions of IT roles and responsibilities [1, 2, 3, 4, 5]
• IT budgeting process [2, 4, 5]
  
• Up-front budgeting (i.e., less reliance on end-of-cycle and ad hoc budgeting)
  
• Unified IT budget
• Business case, TCO, ROI analyses
  
• IT planning and prioritization process [2, 4, 5]
• Strategic
  
• Tactical
  

Thoughts on comments, emails, conversations, and the TCC:

- One 'meta-comment' that has been asked sotto voce a lot and openly some is, "Who the @!%# is Will Lloyd to develop this reorganization plan?"

• My best answer is that I'm the person given the task by Dr. Sethna.

- And a paraphrase of a follow-up: "You keep saying that we need to improve communication, trust, coordination, and cooperation. Why are you exempt from practicing what you preach? The appearance is that the lack of communication is deliberate. Successful projects must have the information available to all who need it. If lack of communication is a big issue (and we agree that it is), then shouldn't you be truly communicating instead of dancing around every question with 'uninformation'? The campus IT 'information' meeting week before last just made a lot of folks feel that you would be great in politics. You talk a lot and say nothing. If you can't communicate, then how are you going to solve our lack of communication problem?"

• I've said what I knew at the time all along the way. I didn't answer what I didn't know.
  
• Releasing version 0.5 is my attempt to be as specific as I can at this time.
  
• Version 0.5 is, though, an outline with lots of detail to fill in. I thought it was better to get it out early rather than wait until we had every detail in place, for three reasons:
• To let others weigh in on what makes sense and what doesn't.
  
• To improve communication.
• To give people something more than the rumor mill to go on.
• Subsequent versions, and the implementation plan, will supply missing details.
  
• Beyond that, let me know how to improve my communication. I'd like to do better.
  

- A very important question: "Will I lose my job or have my pay reduced?"

• I've been told by Dr. Sethna that nobody will lose their job or take a pay cut because of the reorganization.
• When positions become vacant, the IT units can look at what they need and set the pay for those positions appropriately.
  

- A comment: "Directory services and user account administration are often a function of server administration... 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."

• I see that directory services could fit in infrastructure services. A question: shouldn't routine user account management task be delegated to the helpdesk staff, especially if the helpdeskers use scripts and templates? What do think about this?
  

- A summary of another comment: "Active Directory systems in ITS, COE and A&S are duplicated. Merging them may become the most difficult part of your re-org effort. Management of this function cannot be overlooked or under-estimated. It is what end users deal with most directly, it is the first line of security policy implementation, and it controls every aspect of workstation abilities."

• Yep. This is an area where a smart unified approach can offer real benefits. We have lots to gain by managing directory services well, and lots to lose by messing it up.
  

- "I believe that security staff would best fit in under infrastructure services."

• The essential thing to me is that the security staff has a direct line to the President.
  
• Ideally, security should be a separate unit from all those it has to guide and inspect, but I wonder if we're big enough to have a separate security group. What say you?

- "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."

• 'Yes' to the question, and 'me, too' to the comment.
• (On a personal, mostly unrelated note, I've never been sure why some people blame me for the FLSA affair. I served as a consultant to HR, and you could argue that my recommendations for particular positions weren't correct, but I didn't run the process. Maybe some reader of this blog can explain it to me.)
  

- "Oftentimes 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."

• For sure. The helpdesk should be the single point of contact, but it has to farm out the things that come to it according to who can solve them.
  
• On a related note: Service management administration comes under User Services in the plan, but service management itself is the shared responsibility of all techies. Somebody has to administer the software, develop and run reports, etc., but every group and subgroup will participate in the service management function.

- "Unless some provision is made to have people 'on the rim' between the donut hole and the donut ring, we can expect a lot of initial duplication of efforts and loss of efficiency."

• We need to reduce duplication and overlap to the extent possible, but the two units will and should touch. They will have to cooperate to get the job done.
• Any structure requires effective communication to work well. Communication and working together should be easier with 2 units with defined sets of responsibilities than with the system we have now, but they are no less important.
  

OK, it's after 7 and I'm all done in. More tomorrow.

Good comments

People have been posting good comments and questions. I'm going to a TCC meeting in a bit, and will do a response to the comments and to what I hear at the TCC this afternoon.

Tomorrow I'm going over to ITS to listen to their thoughts, and I'll schedule an open meeting ASAP.

Meanwhile, keep your advice coming.

IT reorganization plan, version 0.5

This post describes Version 0.5 of the IT reorganization plan.

It defines 2 IT units:

• Infrastructure Services
• User Services

These top-level units would group UWG's IT activities functionally, and their directors would have single point of responsibility and accountability for those functions.

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.

Notes and assumptions:

• 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.
  

Meetings start tomorrow with the TCC. I've asked if I can come to ITS Wednesday, and suggested times of 11 and/or 3, but haven't heard from them yet. We'll do an open meeting soon. If your unit, committee, or group wants to meet, let me know.

Thanks, and please start sharing your wisdom,
Will