CIO update

PAC has decided to go with the single-IT-head model. I'm glad to see this step being taken, and hope it is done quickly so we can all get a better sense of where this all is going.

My understanding is that:

• They intend to hire an interim person internally, and later do a national search for a permanent person.
• The job announcement and description will be posted soon, perhaps as early as next Monday, with applications accepted for two weeks.
  
• Jim Sutherland, the VPB&F, is drawing up the job description.
• The VPs will be the search committee.

The TCC met yesterday and talked about the position. Here's what I sent to Dr. Sethna and the VPs about our discussion:

• Title:
• Those present unanimously backed the title CIO. CIO has an accepted meaning: it's the person who ensures that the organization’s IT investments are aligned with its strategic objectives by mapping IT initiatives to those objectives. A CIO is not the programming manager or chief systems administrator; those duties are delegated to technical managers.
  
• On the other hand, a CTO, which is what we have now, is the techie-in-chief, responsible for designing and recommending appropriate technology solutions to support the policies and directives developed by the CIO.
  
• The TCC didn't want the CIO to be a VP for IT, because that sounds like we'd be adding another silo, rather than establishing a position that supports all the divisions. The CIO has "horizontal" responsibilities that cut across the "vertical" structure of the divisions.
• I mentioned the concern that at some institutions the CIO is in charge of IRP, but they pointed out that there are a number of USG schools that have the two separate, including Georgia Southern, Valdosta, and UGA.
  

• Reporting line
• The TCC also recommends that the position report directly to the President. USG schools mostly have it report to either the President or the Provost, so for UWG reporting to the President makes the most sense. This reaffirms that the job's responsibilities are to the University as a whole, not to any one division.
  

• Job description:
• The TCC strongly recommends that the job description for this position clearly state what its responsibilities will be for the IT reorganization: will this person be charged with refining and implementing the proposed version 0.6, or with starting from scratch?
• Also, the job description should stress the importance of introducing best practices in IT service management.
  

I'll let you know when I hear anything else.

On a national search

I'm not trying to knock anybody by suggesting that we'd need a national search for a CIO.

A CIO would be a new position for UWG, with responsibilities that no current position has. The job of a CIO is different from that of a CTO or a UTO. I want PAC to understand the implications of that.

Besides, a national search wouldn't preclude having a local person selected for the position. I'd expect that some UWG people would apply.

As for the audit being against one person, I don't buy it. It found plenty of blame to go around.

No real news

1. The tone of the 17th comment to the last post was inappropriate. There is no need for personal attacks. There are plenty of substantive matters to address in this forum. If you want to make an ad hominem attack, please do it elsewhere.

We've had lots of good constructive criticism on this blog and at meetings. Flames lessen the credibility of whatever legitimate point you may be trying to make, and are just plain rude.

2. I haven't posted anything recently because I don't have any real news.

I presented the plan to PAC last week, and did a follow-up this week to answer questions they had. I've copied what I presented to PAC below. (The formatting is a bit goofy. I copied and pasted from Word.)

I'm waiting for Dr. Sethna's decisions on two points:

1. Should we have a CIO?
2. Do we move ahead on the functional organizational structure?

The discussion in PAC about the CIO issue was strongly pro-CIO, with the discussion echoing much of what's been said on this blog and at our meetings.

I'll post what I hear as soon as I hear something.



---------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------

IT Reorganization Issues

PAC
October 23, 2007

I. How does the proposed plan address the IT audit?
• Audit item #1
• Assign “responsibility for Information Technology to a single individual or limited group and giving the individual or small group the authority and responsibility to coordinate and manage funding and resources.”
• The directors of Infrastructure Services and User Services would be assigned this authority and responsibility, under the direction of their executive officer. This would address concerns that “no effective IT governance structure in place to coordinate and ensure the best use of IT technology across the University… Cooperation between many of the various IT groups within the University was very poor.”

• Establish “a single University department (i.e. Office of Information Technology)” and designate “a Chief Information Officer to coordinate and be held responsible for the status of Information Technology at the University.”
• This is a biggie. See discussion of this issue in section II below.

• Establish “the long term strategic direction for Information Technology at the University in consultation with various units of the University.”
• The functional units would have the technical expertise to inform this discussion, with less of a tendency to be swayed by the parochial and turf-protective concerns that often dominate in the current organization. Techies should not, of course, set the strategic direction; they should only provide technical advice.

• Create “a formal definition of the charter, roles, and responsibilities of its information technology function.”
“Develop an annual one-year tactical plan that can be tracked and monitored based on a well researched and documented strategic plan.”
Develop “an overall Information Technology budget.”Create, publish, and monitor “standards and procedures for the implementation and administration of information technology across campus.”
• Tactical planning, up-front IT budgeting, and adoption and enforcement of standards and procedures would be more feasible with functional alignment of IT resources and staff, which would allow:
- Clear definition of roles and responsibilities
- Reduction in overlap and duplication of duties
- More streamlined communication channels
The Service Management Administration subunit in User Services would be charged with documenting and monitoring these plans, budgets, standards, and procedures.

• Define, implement and maintain “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.”
• Servers will be administered by the Infrastructure Services group, with appropriate access made available to both User Services staffers and the rest of the University.

• Audit item #2
• “Management should ensure that an IT policy framework is developed which encompasses campus wide IT requirements… Where required, specific procedures and standards should be developed by individual operating units to suit their individual requirements.”
• The Infrastructure Services and User Services groups would:
- Provide technical information in their areas of expertise to PAC, the TPC, and other University committees charged with developing policy.
- Develop technical standards and procedures to meet campus-wide IT needs.
- Work with users to develop standards, and procedures with local application. In particular, this would include development of service-level agreements (SLAs).

Having a Service Management Administration subgroup charged with coordinating, documenting, and monitoring policies and procedures would facilitate UWG’s adoption of IT best practices, as recommended in the audit’s executive summary.

• Audit item #4
• “Management should consolidate [network support servers and] services were possible.”
• The Infrastructure Services group would maintain the servers and provide appropriate access to these services. They and the User Services group would develop operating level agreements (OLAs) to define their responsibilities toward each other, including the process and timeframe for delivery of the services. This is an area that has great potential for improvement in service in directory services and user authentication.
The issue addressed by this item – duplication of effort, resources, and services – applies to IT services other than those involved in network support. Grouping IT staff and services according to function rather than by administrative units would lessen the need for such duplication, highlight it where it exists, and remove the bureaucratic impetus to encourage it.

• Items #5 and #6 addressed system backup and recovery procedures. Disaster recovery practices in the distributed units are inadequate. Placing responsibility for server administration in the Infrastructure Services group would let us address this issue.

• Items #3 and #10 - #16 address concerns with security and logical access to sensitive data. The proposed structure responds to concerns like these in four ways:
- Moving the Information Security Office out of an operational IT unit and giving it a direct reporting line to the President to give it more authority and credibility.
- Consolidating server administration in the Infrastructure Services group.
- Increased emphasis on service management to stimulate adoption of standard practices like change management, configuration control, version control, and IT asset management.
- Separation of duties between Infrastructure Services and User Services to better regulate privileged access to servers for those not charged with server administration.

II. CIO?

• The auditor recommended that UWG establish “a single University department (i.e. Office of Information Technology)” and designate “a Chief Information Officer to coordinate and be held responsible for the status of Information Technology at the University.”

• We discussed four leadership models at the last PAC meeting:
1. CIO, reporting to the President and a member of PAC
2. Executive Director of IT, reporting to the VPAA and not a member of PAC
3. Directors of Infrastructure Services and of User Services, reporting to the VPAA and not members of PAC, with the UTO remaining only as a transitional position.
4. UTO, reporting to the President and not a member of PAC

• The models differ on four dimensions:
1. One IT head or two.
2. Reporting line: to the President, or to the VPAA.
3. PAC member or not.
4. Hired specifically for the position, presumably after a national search, or is the UTO.

• Each of the models has advantages and disadvantages, which I am happy to discuss.

• We could consider variations, like an Executive Director of IT reporting to the President.

• I make two strong requests:
- If we decide on one IT head, we should do so after a national search, for these reasons:
-- Lack of baggage
-- Credibility
-- Skill set

o Whatever structure we adopt, we must move the Information Security Office out of an operational IT unit and give it a direct reporting line to the President

III. Some things we need in IT, with or without a reorganization

In no particular order:

- Increased emphasis on:
customer service
service management
security
tactical planning
accountability
training for both users and IT staff

- A reward system for IT managers that encourages desirable behavior.

- Goal-driven, up-front budgeting

Two items: CIO and Version 0.6

CIO or no

• I met with Dr. Sethna this afternoon and laid out the possibilities we've discussed in the meetings and on this blog about having:
  
• a CIO,
  
• a non-CIO head of IT, or
  
• two unit heads.
• Dr. Sethna asked lots of questions, even suggesting other possible solutions. It's obvious he's thought about this.
  
• He will talk to people on PAC , think about the pros and cons, and make a decision.
  

  ---

  
  

Version 0.6 of the IT organization plan

• Infrastructure Services
• Systems administration
• Server administration
• Directory services management
• Multi-user application administration
• Networking
• Telecommunications

• User Services
• Student support
• Faculty and staff support
• Localized faculty/staff tech support teams
• Training coordination
• Software development
• Web development
• Application development
• Graphics services
• Service management administration
• Service desk administration
• IT asset and change management administration
• Service level agreement administration
• User account administration
  

• Information Security Services
• ISO (reporting to a VP, but with a direct reporting line to the President)
• Security specialist(s)
  

Notes:

• Changes from version 0.5:
• Responsibility for directory services shifted to the sys admin group in infrastructure services. Several of you pointed out that this makes sense.
  
• Faculty/staff support is in one group, with teams whose primary duties will be to serve logically and geographically related units.
  
• Again, several posters observed that we need to preserve good localized service. This change should lessen the fears of some users that they will lose their excellent support, while still offering opportunities to improve service for all users.
  
• Security's place in the plan is clearer.

• All positions whose primary duties are in IT are part of the reorganization.
  
• There are a very few power users whose positions are classified as IT, but whose primary duties are in information analysis, instructional design or support, etc.
  
• These power users would not become part of the IT organizational structure. Their duties must be clarified, and their job classifications changed to fit those duties.
• By "very few," I mean 3 or 4 at most.
  

• Implementation planning is in its early stages, but will progress rapidly in the next few weeks.

• Implementation will begin in January, but will be phased in as feasible.
  
• It can't happen overnight, as several people have written, but we will move as quickly as we can without compromising service, efficiency, accountability, or security.

• I gave Dr. Sethna a "mid-term" report on the plan. He asked tough questions, and then gave his thumbs up.
  

IT capability levels

At last Friday's open meeting I passed out a description of the Capability Maturity Model developed by the Software Engineering Institute. The CMM is for IT organizations similar in purpose to Six Sigma and Lean Six Sigma for manufacturing organizations.

The CMM maintains that to improve your IT processes, you must:

• manage requirements, risks and configurations;
• plan, monitor and control your projects;
  
• measure and analyze the output of your efforts;
  
• focus on
  
• how well you're following your processes,
• whether the processes are working.
  

To succeed at this, an IT organization must:

• adopt and standardize effective processes,
  
• measure and assess what the processes accomplish,
• focus on process improvement,
  
• dedicate planning, resources, and training to the effort,
• involve stakeholders.
  

How well you do can be expressed in terms of capability levels, of which there are five.

• Our IT processes are mostly at level 1, with some moves towards level 2.
  
• We need to reach level 3, and to consider reaching for level 4 for some mission-critical functions.
• We need to change some of our thinking and our behaviors to have a chance to reach level 3.
  
• The organizational structure we adopt must be one that helps us get there, rather than getting in our way.

One note: focusing on processes and process improvement is not appropriate only for companies like GM, as somebody said at the meeting. We can benefit greatly from it, too.

---

Here's a summary of the capability levels:

Level 1 - Initial

Processes are usually ad hoc and inconsistent across the organization.

• Success depends on the heroics of the people in the organization, and not on the use of proven processes.
  
• In spite of this ad hoc environment, maturity level 1 organizations often produce products and services that work, but often exceed the budget and schedule of their projects.

Level 2 - Repeatable

Software development successes are repeatable, but the processes may not repeat for all the projects in the organization. The organization may use some basic project management to track cost and schedule.

• Process discipline helps ensure that existing practices are retained during times of stress. Project status and the delivery of services are visible to management at defined points (for example, at major milestones and at the completion of major tasks).
• Basic project management processes are established to track cost, schedule, and functionality. The minimum process discipline is in place to repeat earlier successes on projects with similar applications and scope. There is still a significant risk of exceeding cost and time estimates.
  

Level 3 - Defined

The organization’s set of standard processes are established and improved over time. These standard processes are used to establish consistency across the organization. Projects establish their defined processes by the organization’s set of standard processes according to tailoring guidelines.

• The organization’s management establishes process objectives based on the organization’s set of standard processes and ensures that these objectives are appropriately addressed.
• A critical distinction between level 2 and level 3 is the scope of standards, process descriptions, and procedures.
  
• At level 2, the standards, process descriptions, and procedures may be quite different in each specific instance of the process (for example, on a particular project).
  
• At level 3, the standards, process descriptions, and procedures for a project are tailored from the organization’s set of standard processes to suit a particular project or organizational unit.
• Effective project management system is implemented with the help of good project management software.
  

Level 4 - Quantitatively Managed

Using precise measurements, management effectively controls IT efforts. In particular, management can identify ways to adjust and adapt the process to particular projects without measurable losses of quality or deviations from specifications.

• Organizations at this level set quantitative quality goals for both software process and software maintenance. Sub-processes are selected that significantly contribute to overall process performance. These selected sub-processes are controlled using statistical and other quantitative techniques.
• A critical distinction between maturity level 3 and maturity level 4 is the predictability of process performance. At maturity level 4, the performance of processes is controlled using statistical and other quantitative techniques, and is quantitatively predictable. At maturity level 3, processes are only qualitatively predictable.
  

Level 5 - Optimizing

The organization focuses on continually improving process performance through both incremental and innovative technological improvements.

• Quantitative process-improvement objectives for the organization are established, continually revised to reflect changing business objectives, and used as criteria in managing process improvement.
  
• The effects of deployed process improvements are measured and evaluated against the quantitative process-improvement objectives. Both the defined processes and the organization’s set of standard processes are targets of measurable improvement activities.
• Process improvements to address common causes of process variation and measurably improve the organization’s processes are identified, evaluated, and deployed.
• Optimizing processes that are agile, adaptable and innovative depends on the participation of an empowered workforce aligned with the values and objectives of the organization. The organization’s ability to respond rapidly to changes and opportunities is enhanced by finding ways to accelerate and share learning.
• A critical distinction between maturity level 4 and maturity level 5 is the type of process variation addressed.
  
• At maturity level 4, processes are concerned with addressing special causes of process variation and providing statistical predictability of the results. Though processes may produce predictable results, the results may be insufficient to achieve the established objectives.
  
• At maturity level 5, processes are concerned with addressing common causes of process variation and changing the process (that is, shifting the mean of the process performance) to improve process performance (while maintaining statistical probability) to achieve the established quantitative process-improvement objectives.
  

CIO: pros and cons

Please send me more advantages and disadvantages of having a CIO so I can present the cases fairly and accurately to Dr Sethna:

Advantages:

• One point of accountability for many facets of IT
• budgets,
• plans,
• assessment,
• management.
  
• One person charged with thinking strategically and politically about IT.
• IT not under any of the other divisions, so no favoritism to one division.
  
• A voice for IT at PAC.
• A unified IT organization:
  
• A "decider" to resolve disputes between subunits.
• An enforcer of best-practice adoption.
  

Disadvantages:

• Many IT eggs in one CIO basket.
• Difficulty of finding somebody that we can afford with the requisite skills.
  
• Expense.
• Having a "techie" responsible for thinking strategically and politically about IT.
• Extra layer of management.
  
• Tendency to push decisions up to the CIO.

---

Interesting reading about the evolving role of the CIO:

• An analysis at the University of North Dakota summarized the research on effective CIOs. They found that "an effective CIO should be

• A visionary, understanding technology trends and their impact on higher education
• An adaptive leader who takes a proactive approach to ensure the university is using information technology to support its mission
• An active member of the university’s senior administration
• A relationship builder, ensuring that IT use and support is efficient and effective throughout the institution
• A strategic planner and thinker, aligning information technology direction with institutional vision, mission and goals
• An effective manager of people, projects and budgets"

• UND decided, by the way, to have a CIO who reports to the Provost and VPAA, not to the President, and to continue to have some distributed IT groups in large academic units.

• The article "What is the CIO's job, anyway" from CampusTechnology.com is also helpful in understanding our choices.

Possible IT structures sent to me

Several people have asked that I describe the IT structures people sent to me after I asked for them in open meetings and before I developed version 0.5. You'll see that I learned (AKA stole) a lot from them.

Here they are:

• A model with three groups:
  
• Enterprise computing
• Networking
• Enterprise systems (Banner, PeopleSoft, WebCT, Pipeline, etc.)
• Security
• Data Center
• Audio-Visual
• Administrative computing
• Budgeting
• Purchasing
• Planning
• Licensing and Maintenance Management
• Inventory Control
• Support Services Computing
• Hardware/Software support
• Academics
• Administration and Advancement
• Business and Finance
• Facilities and Engineering
• Student Services
• Instructional/Curriculum Support
• Design and Development

• A centralized model
• VP for IT
• VP's staff
  
• Director, IT security
• IT administrative support
• Director, Help Desk
• Assistant VP, IT Development Services
• Assistant VP, Enterprise IT Systems
• Director, Network Systems
• Director, Business Systems
• Assistant VP, IT User Services
• Director, IT Student Services
• Director, IT Faculty/Staff Services
• Director, IT Computer Lab Services

• A model that addresses types of services rather than an IT structure per se:
  Three service segments
• Core Service
• Customer Service
• Customer Needs
• The service segments can be further divided into sections to represent specific services

• A model with five main categories:
• Classrooms and Labs
• AV Equipment
• Lecture Halls
• Management of Lab SA’s
• Card Access
• Student Support
• Faculty and Faculty Support Staff
• Software and hardware support
• Training
• Infrastructure
• Telecomm
• Software Development
• Enterprise Application Support
• Communications
• Graphics Services
• Library Systems
• Security
• Operations
• Server Support
• Networking
• Admin (non faculty support staff) Support
• Alumni House
• President’s Office
• IRP
• Business and Finance
• ETC…
• Administrative Application Support
• Management
• Planning
• Budgeting
• Coordination
• Assessment
• Asset Management
• Notes:
• Somewhere within all this would be user account management. Probably, though, like we have now in some cases, each group would access servers somewhere to manage their own group of user accounts.
• Whatever the case, you need to have that single point of contact for all things and an inbound call center with solid first level support and an online database for first level techs. You’d have different levels of escalations, prioritization of issues based upon importance, etc.

On a related note, here's a structure discussed last year by the ad hoc IT reorganization committee (whose work was suspended in light of all the management changes and acting appointments at that time).

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