Reactions to comments

Several good reactions and questions to the meetings and my postings have come in. Here are some, with my responses:

• Comment: "Don't publish my remarks verbatim. It's not that I don't TRUST my management..."
• Response 1: I've disguised the commenter in some of what follows by paraphrasing and by leaving out identifying details.
  
• Response 2: The IT managers who have tried to silence their staff members are derelict in their duty to the University.
  

• Q: [The meetings and postings] "lead me to believe that in the reorganization there may be some people who end up with different job titles and responsibilities. Is this a likely scenario?"
• A: I think it's inevitable.

• Q: "While the current structure certainly plays a role in this problem, isn’t the root cause the lack of an IT governance structure? To continue with our pastry model, doesn’t the donut need a baker?"
• A: We certainly need to improve our organizational structure, and to do better planning and budgeting. As I said in my last post, I don't think that this means we need just 1 "baker-in-chief," but we'll see what arguments people lay out.

• Comment: "I’m not sure I agree that software/app development should be a part of user support and here’s why. This area should be mostly focused on project status and not the day-to-day concerns or complaints of users. Sooner or later you have to draw a line in the sand and say; this is what we are building no more input. Input from users is appropriate and essential early in the project and distracting and deadly once an end product has been decided on. I guess what I’m saying is that user interaction with developers should be more structured than it would be with a typical user support person."
• Response: Software development process models have evolved to require more user input at every step of the way. User/developer interaction certainly has to be structured properly to be effective, but is essential early and often. The old waterfall development model is rarely the way to go. I could go on and on about this until our eyes glaze over, but this blog is probably not the place to do that. If you're interested, send me an email.

• Q: "Enterprise apps are infrastructure for sure. I think I know but what do you see as enterprise apps?"
• A: Some, like Banner, are obvious, but I'd defer to the systems folks to come up with a list.

• 2 related comments:
  - "Security must be outside the normal chain of authority."
  - "As with the VPAA, the President might not have the technical knowledge to correctly handle security issues. It seems appropriate for the security staff to have a direct line to an upper level, but a CIO should be better prepared to make IT security-based decisions than the President. A CIO might also be more readily available in the event of immediate threats."
• There are two issues here.
  
• The security staff must have a direct line to the top, just as auditors do. And by top, I mean the President, not a VP.
  
• Effective response to security incidents depends on procedures that ensure that all the relevant skills can be brought to bear: technical, investigative, administrative, and sometimes even legal and PR. Mardel Shumake, our Information Security Officer, is currently documenting those procedures so they can be incorporated into our Security Plan. This doesn't conflict with the need for direct reporting.
• Also, as Rob pointed out, a security person may also wear a non-security hat, and when doing so, report in the normal chain of command. I don't know that this will be true here: we probably need more people dedicated to security.

• Comment: "[W]hile the TCC has its merits, it has not produced many results. Can we in good faith expect a similar grouping of unit heads to "do the job" without direction?"
  
• No, we need a very different IT structure, or we're doomed to continue on the same path.
  

• Comment: "Also, making decisions by committee does not fall in line with the strategic plan's desire for a single point of accountability."
• Response: We don't need or want one single point of accountability for everything. That would mean that the President would make every decision. What we want is to delegate each responsibility to a person who has the authority and skills to do the job well. In a restructured IT organization, that would mean dividing responsibilities as clearly and effectively as possible, and then holding the responsible person accountable. The unit head will have authority and responsibility for the functions assigned to the unit, and will delegate some aspects of that authority and responsibility to people in that unit, without giving up final say and accountability.
  
• Objection 1 to my response: "But some redundancy is a good thing."
• Yes, and we want to build appropriate redundancy into our structures. That doesn't conflict with the need for accountability.
  
• Objection 2, by 2 people:
  - "About the 'clear roles and responsibilities.' Not to sound cynical, but this will never totally happen... we're always going to end up with gray areas, with some overlap and potential conflict areas."
  - "The notion that each IT unit will have clearly defined non-overlapping responsibilities is hard to imagine. Discussion so far has blurred the line between the proposed donut hole and donut ring, and I have no doubt that the line will continue to be blurred as the model becomes more concrete. Even under a new structure, we will probably see a number of the same problems inherent in the current structure."
• True, there will be overlaps, by the nature of what we do. We can, though, reduce the areas of overlap, recognize them, and develop procedures to manage them.

• Comment about the difficulty of finding somebody with all the skills needed to be an effective CIO: "By 'unlikely that we could find somebody,' does somebody == somebody currently working on campus? If so, then yes it might be difficult to find somebody with the range of skills. If not, I do not think this is a concern."
• Response: Nope, unfortunately I mean anywhere.
  

• Comment: "The VPAA might not have the technical knowledge to correctly settle disputes among IT units. A CIO would be expected to be familiar enough with the IT world to understand the scope of disputes and provide better resolution."
• Response, part 1: I wish the tough decisions were technical ones. They rarely are. The toughest decisions are political, bureaucratic, and/or strategic. Techies are good at resolving technical issues, but should not be responsible for solving nontechnical problems. They can and should provide technical insight to inform executive decisions, but they shouldn't make them.
  
• Response, part 2: Living by part 1 requires something of a cultural shift for us. Too often, techies at UWG have set policy rather than giving the administration the appropriate information and having them set the policy.
  

• Comment: "We would need to assess our current structure before we can use it as any basis for future results."
• Response: For sure. That's what the auditor, the committee formed in response to the audit, the TPC subcommittee charged by PAC last year to assess it, and what I've been charged with doing. Luckily, with all the help I've been getting, we're doing pretty well.

• Comment: On a reason I listed as a good thing about having a CIO (If a CIO were a member of PAC, IT would have a voice at the highest level of University decision-making.): "This certainly sounds like a good way to improve the decision-making process and help alleviate the timelines associated with getting approval through the chain."
• Response: As long as PAC includes in its deliberations the unit manager or unit managers with responsibility for the matter in question, this shouldn't be a problem. For instance, when a PR issue has come up, they've asked Lisa Ledbetter to be present, even before she started attending PAC in the absence of a VPUA. And, depending on the nature of the IT issue, they've included me, or Mike Russell and me.
• Besides, I wouldn't wish regular PAC attendance on any techie! Most of what they discuss is simply not germane to what we do.

• Comment: "We talked a lot about users and customers, but those terms don't adequately define who we serve. I prefer information consumers. I think ID'ing the consumers of the product is a large first step toward making sure that the 'market' is satisfied."
• Response: Interesting term. In an earlier response I wrote the jargon-y word stakeholders to try to get at the same thing. We serve more than the users of the particular software and hardware we're working on, and most of those with an interest in what we do aren't customers who pay for our services.
  

• Comment: "A large problem with IT on campus is unfunded mandates... As long as the demands are uncoupled from the money, there will be a disconnect, and IT will suffer. I think this gets back to the budget constraints, and the requirement for the budget process to be reformed/reworked along with the IT reorg before the reorg can be successful/complete."
• Response: What he said.

• Comment: "People are worried about the loss of control and accountability, like getting orders contrary to the 'best running' of 'their' group. SLA's are great, in theory, but they still mean the loss of control."
• Some lines of authority will shift, and that will be painful for some. Nobody, however, will have less accountability. We don't have that luxury in "this changing world." Service level agreements won't save us, but they can help us define what's reasonable and what's expected.
  

Two questions

Two questions I'd particularly like you to consider, stimulated by discussions at and after the open meetings:

1. Must we have a single hierarchy under a CIO, or will a small number of units be able to do the job - and work together - without a boss?
2. If we don't go with a unified hierarchy, what should we do about cross-cutting concerns like security, asset management, budgeting, purchasing, and planning?

My thoughts on these issues:

• On whether to have a CIO:
• Con:
• Putting all our managerial eggs in one basket is dangerous. I would argue that it is unlikely that we could find somebody with the wide range of managerial, technical, planning, and budgetary skills needed to do the job well.
• It adds executive redundancy.
  
• Primary tasks for a CIO are to resolve disputes and to make tough decisions. IT unit managers should be able to make tough choices, and the VPAA to settle disputes. If not, we'd have more serious problems than a CIO can solve.
  
• A small number of IT managers, each responsible for a unit with clearly defined responsibilities, should be able to function well without the problems inherent in our existing IT structure, with its large number of IT units with overlapping, and often nonsensical, sets of responsibilities.
  
• Having a CIO report to the President removes the focus of IT from Academic Affairs, where I think it belongs in a university.
  
• Good CIOs are expensive.
• PAC has been resistant to the idea.
• Pro:
• IT would have a single point of accountability: a decider, as W would say.
• Those who work on cross-cutting concerns could live in the CIO's office.
• If a CIO were a member of PAC, IT would have a voice at the highest level of University decision-making.
• As I said at the meetings, I lean toward the anti-CIO side, but I can see the advantages of having one. I think they are outweighed by the disadvantages, but my mind could be changed by convincing arguments.
  

• On where to house cross-cutting concerns without a CIO:
• Security is a special case. The security staff should have a direct line to the President, like the auditor does.
• Four possibilities for the others (asset management, budgeting, purchasing, planning, etc.): they could live in either
  
• one of the IT units we create, with the responsibility to serve all the units;
  
• the VPAA's office;
  
• a separate IT unit, called something like "IT administrative services;" or
  
• a combination. (Just because they are all cross-cutting doesn't mean that they all necessarily should be treated the same.)
  

Your thoughts?

An aside: I'll post more about the meetings and some ideas people have shared, but I wanted to get these questions up first.

Open meeting, 9/18

Since the meeting, several people have asked me to post my private email address:

• wlloyduwg@gmail.com

If you're worried about using campus email and don't want to do a public post, send an email to that address.

I was asked to videotape the meeting, but didn't because two people said that it would inhibit openness. One of the IT people sent me decent minutes, so I'll paste them:

• Dr. Will Lloyd opened the meeting with an overview of most of the information already posted on the IT Reorganization blog that he maintains. He requested input from those in attendance and others via phone, e-mail, posting a question to the blog, or setting up a meeting with him. Dr. Lloyd wanted to make sure that everyone knew that they have access to him to give input on this process.
  Dr. Lloyd also noted that we need to place an emphasis on "Service and Services" offered for IT support at UWG.
  Dr. Lloyd gave a brief overview of what he calls the "donut" model and talked about creating a Service Catalog and Knowledge base for users of technology on campus. Dr. Lloyd noted that he hopes to place in the next few weeks that donut model on the blog for review. He continued to ask for feedback as we go through this process.
  Dr. Lloyd discuss that when the new model is implemented that he considers it version 0.5 and notes that if people or services do not seem in the correct place that a process will be in place to recommend a change, although it might approved.
  Dr. Lingrel asked "How will priorities be set and who will set them?"
  A discussion ensued on setting priorities. Dr. Lloyd acknowledged that a lot is getting done now as units set their own priorities but maybe this system in inefficient. Dr. Lloyd stated that priorities are set now by users probably because support is located at the unit level.
  A short discussion on creating Specialist and Generalist and to not create redundancy in services.
  Then Mardel noted that sometimes users call in and don't know what they need or do not describe them properly. Dr. Lloyd indicated that we need to help users define and revise their needs and help set the priority.
  Then someone noted that this seems like a paradigm shift and that we need to be more service oriented. Someone noted that "We can mandate change but we cannot mandate success".
  Dennis Gould noted that users drove us to the structure that we currently employ. Dr. Lloyd indicated that is probably true but that it is time to assess our organization and determine if and what changes need to be made. Dr. Lloyd indicated that there should be an ongoing review of the organization structure even after changes are made and that changes will happen again in the future.
  Dr. Lingrel noted that we need to "Look at what is working and not throw the baby out with the bathwater" Dr. Lingrel noted that they like their current level of support and have identified staff who have become Super-users in the their area.
  Someone noted that we should fix the problems...don't just change the structure.
  Dr. Lloyd noted that there is now more of an emphasis at the BOR and university level or be measured and accountable for results. (All helpdesk calls should be collected and analyzed, project management should be improved, etc..) "We need to Justify ourselves"
  Price Hall noted that the lines of access are often blurred and that some people have access to get things done faster than others. He indicated that all requests should be pooled so that a bigger assessment can be made if there is a continuous problem.
  Price also noted that users often bring a solution, not just a problem and that this can cause confusion as not all solutions may be the best answer to a problem. Price asked the question, "What happens when you have to say NO." Price indicated that a service catalog could help users know what they could count on.
  Dr. Lloyd noted that even PAC members have stated such things as "We need this now" and it might not the best solution or "we must purchase this now or pay more." Dr. Lloyd has been trying to inform the Administration that we have to say NO and that supporting and on-going costs should be considered along with the request. There needs to be justification and support for projects to be successful.
  Dr. Lloyd also noted that IT staff must learn how to say NO the correct way. He noted that he read that users often request such things as last minute software installations and that may not be possible to be more efficient. A discussion ensured that users must also be more accountable and not wait until the last minute.

Some of my thoughts on the meeting, and on comments and questions I've gotten:

• The paradigm shift we talked about - from emphasizing what unit we're in to focusing on the services we offer - is central in my thinking. It has major implications for organizational culture, planning, budgeting, security, and our day to day lives as techies.
  
  
• The donut model - infrastructure support wrapped by user support - is a simplified abstraction, but offers the best picture of what structures we need that I've seen so far.
  
• This abstraction doesn't answer some important questions:
• Where is the boundary between the "donut hole" and the "donut ring"?
• How should the hole and ring be organized?
• What management structure will the boundary and organization require?
  
• I'm starting to get a picture of the answers to those questions, but I'd like to hear your take on them.
  
• And, if you have a better model than the donut, I'd like to hear that, too.
  
  
• Proposed timing:
  
• Release version 0.5 in the next few weeks.
• Hold meetings and get feedback to refine the plan through versions 0.6, 0.7, and 0.8 during October.
• Nail down the details of version 0.9 in early November.
  
  
• We must recognize that version 0.9 is the one we'll go with, but that we'll review how things are going in 3 months, 6 months, a year, and periodically after that.
  
• This means that life won't be easy for a while, but it is important that we assess how we're doing and make corrections rather than blindly stay the course.
  
  
• In fact, whatever structure we have needs to adapt to changing technologies and user needs.
• Our current structure may be seen to have evolved in reaction to the change from a mainframe world to an desktop world.
• What we need now is a structure that responds to the change from the desktop world to the current interconnected world.
  
• Five to ten years from now, IT organizational structures will probably have to accommodate something else.
  
  
• However we organize IT, we have to become more accountable. In this "changing world" we have to be able to show what services we provide, how effectively we're providing them, and how we're going to improve.
• There's a danger there, of course: we can end up wasting time collecting data. We have to figure out what data is helpful, and how to collect it most painlessly.
  
  
• A comment and question emailed to me:
  
  
• The comment: IT is basically organized into 3 functional areas that need to be structured into a working organization:
• Infrastructure/Core – network, security, background application support
• Software/Application development
• User Support – hands on , face-to-face, possibly end-user Web and application support.
  
• The question: Where does enterprise application support (not development) live in this view?
  
• My answer:
  
• First, I'm not sure that separating software development from user support is wise. Developers need to be in close contact with users and user representatives, and that may be accomplished better as part of user support.
• Second, support for enterprise apps seems so intimately related to server management that it probably makes most sense as part of infrastructure support.
• Third, is security really part of infrastructure support? Isn't it more like an auditor, who has a direct line to the president?
  
• What do you think?
  
  
• Another question: Do faculty and staff need a different interface to IT services than students?
  
• Probably. User support will have to be structured to let both groups get the service they need.
  
  
• A comment that I heard in the meeting and by email: Don't forget administrative staff support!
  
  
• Another view of the donut model sent me by an intrepid techie:
  
  
  

A question about the IT groups

A question from the comments on the last post:

• "Is there a listing by each IT group showing who their customers are and how much interaction they have (daily, weekly, monthly, yearly)?"
  
  
  • Not across the board. Some of the groups have not felt able to afford the licenses to the help desk software that tracks that stuff, and some have felt that it takes too much time away from solving problems to use the software. All have agreed, though, that in this "changing world," we have to be more accountable. So, we're going to make a budget request to get enough licenses for everyone to use, and then we're going to use them.
    
    On a related note, I mentioned last time that we're exploring becoming more compliant with industry practices in IT service management. Kathy Kral in ITS has arranged for the help desk vendor to give us a demo of their asset management tool on Sept. 25 at 10:30. I'm still working with the person from the Atlanta Local Interest Group (LIG) of the Information Technology Service Management Forum (itSMF) to set up a time when she can talk with us.
    

Thoughts on three questions

Three questions, two from comments on this blog and the third from a conversation:

• "Do you think a lot of people want the same thing, but language is a barrier? What I am saying is, words like "good service" can mean different things to different people (that's just one example)."
  
  
  • Yes, definitely. That means that, whatever the organizational structure, we have to move towards a comprehensive IT service management model with a service catalog, service level agreements, process improvement strategies, etc., that will let us define what "good" means.
    
    ITS is already exploring how we can use the Remedy service desk software to support some of those efforts, and I'm arranging a meeting for us with the Atlanta Local Interest Group (LIG) of the Information Technology Service Management Forum (itSMF). These will help us define our terms and expectations.
    

• "As the rumors have been flying, is the overall design for the campus IT structure at the end of this reorganization somewhat clear in your head, but just haven't worked out the details yet?"
• I have thoughts, but no fully-worked out plans. As Dr. Sethna said in his letter announcing my charge, "[W]e will reorganize IT structures at UWG to reflect the need to handle operations and enterprise systems on the one hand, and user services on the other." What I'm trying to do now is to figure out what structure will best meet that need.
  
  If you have suggestions for an organizational structure, whether high-level or detailed, please send them to me or post them on this blog.
  

• "What criteria are you going to use to create a new organizational structure?"
• To me, my charge states the primary criterion: the structure must "handle operations and enterprise systems on the one hand, and user services on the other."
• Other criteria include cost and available resources. I've not been given any dibs on the budget, so we're sadly constrained by fiscal realities.
  

On the TCC's comments

Thoughts on the post about services and standards to preserve, and of those to jettison or improve:

• Comments on the comments:
  
  
• "Shouldn't the users who receive support be the ones to answer what services should be preserved and which should be improved?"
• Good point. Yes, their answers are essential. The value of IT is in the support it provides to the teaching, research, and service missions of the University. That being said, I had a captive audience of smart people who have thought about this a lot, and I want to get their input. I'll get more input from other groups, too.
  
  

• "Sure, all the IT departments want to maintain autonomy. That is what got us into trouble in the first place. Too many chiefs and not enough Indians."
• Going back to my response to the first comment, the value is in the service we provide. Decentralized organizations and centralized organizations can both work well, given the right circumstances. We need to define an effective organizational structure for our particular set of circumstances.
  
  

• Most items seemed reasonable. Many do point up the need to define what we mean by good, quick, secure, etc.
  

• Not surprisingly, the lists overlap:
  
• Support is good, support needs to be better.
  
• Training is a strength, we need to do better with training.
  

• There are possible tensions between some items:

• Flexibility vs. consistency.
• Standardization vs. customization.
• Autonomy vs. coordination.
  

• Most issues are things we've discussed in the TCC, but one hadn't come up: workload. I was glad to see it, because it's talked about often sub rosa but rarely openly.

• I'll be interested to see how these lists compare to ones from other groups of stakeholders.
  

TCC report

The TCC discussed IT reorganization at its meeting on Sept. 4.

The members answered these questions, working in small groups:

1. What services and standards of service do we want to preserve?
2. What services do we need to improve? What are we not doing, or doing poorly?

I edited the responses to

• remove duplicates,
• group related answers,
• expand some shorthand to improve readability, and
• exclude elements that refer to providers rather than services and standards,

but not for content. The order of the responses is not meaningful; I just started transcribing cards, then grouped related responses. If you see something I goofed up, let me know.

I haven't fully digested the responses, so I'll reserve comment until my next post. You can start commenting now.

- Services and standards of service to preserve:

• Security, safety, and privacy.
• Physical security of servers and network devices.
• A security plan that is used, updated and maintained, and that is supported by the University administration.
  
• Short response time 24/7/365, especially for networking and services provided to Public Safety and students.
• Emergency services.
  
• Robust network infrastructure - routing, switches, wiring - to the data port on the wall.
• Networking management.
• 24/7 up time on the network.
• Response to access problems for any campus IT.
• Well-maintained network and phone services.
  
• Ability to provide software images to satisfy needs of specific units, labs, faculty, and staff.
• Hardware and software support to faculty and staff in the classroom and the office.
• Immediate support for faculty in classrooms.
• Quick response to faculty and staff offices.
• Install software and hardware at last minute to use in class.
• Provide just-in-time assistance with good response time.
• Customer service.
• Flexibility to meet faculty, staff, and student needs.
• Meet expectations for use of technology in teaching.
• Meet program needs.
• Familiarity with programs.
• Response to faculty needs at a level that enhances and never impedes teaching.
• Quick communications about needs of units.
• Facilities response time.
  
• Ability to provide technical training to faculty and staff.
  
• Software development.
• Report generation.
• Application troubleshooting.
  
• Qualifications for PC technicians.
• Technical expertise.
• Accuracy.
• Professionalism.
• Close relationships with stakeholders.
  
• Website integration.
• Integration of all software and hardware.
• Standardization of labs, network, software.
  
• Enterprise applications to support efficient and coordinated use of IT: email, SIS, HR, management, assessment, user access via web to resources like the library
• Development and production servers, e.g. web and MySQL, on which to mount applications.
• Backup and restore.
• Machine room specifications.
  
• Business office functionality provided by Pharos, PeopleSoft, Pamet, reporting, Lenel, etc.
  
• "Easy" access to my personnel records.
• Appropriate data access without restraint and with good turnaround time.
  
• Researching new technologies.
• Diversity in thinking, innovation.
  
• Money, resources, space.
  

- Services to improve, provide, or do better:

• Web support for main and UWG pages.
  
• Human resources role to help IT, not to dictate.
  
• Central software purchasing, deployment, support, and license management.
• Accurate, up-to-date records of equipment and software.
  
• Duplication of resources.
  
• Standardization, consistency.
• Standardization of labs.
• Consistent use of software across the University.
• Common communication tools: email, calendaring, scheduling.
• Ease of use for faculty, staff, and students (e.g., true single sign-on).
• Integration of hardware and software solutions.
  
• A/V support difficult because of heterogeneous systems.
• Confusion about who to contact, who supports what.
  
• Data collection and reporting.
  
• User training in some areas.
• IT staff training.
• User retention of training.
  
• Advertising and communicating about available services.
• Evening and weekend support.
• Student support before the start of the semester.
• In some cases, customer service has room to improve.
  
• Response time in some cases.
  
• First-time resolution.
• Single point of contact, with problem farmed out to appropriate problem solver.
• Solving a problem vs. closing a helpdesk ticket.
• Clarity of both provider and solution: communicate solutions so the provider isn't sent back and forth to solve the problem.
  
• Looking at current practices and determining how they can be improved (e.g., manual to automated).
  
• Project management.
  
• Secure access to data from off-campus.
  
• Communication among IT staff and between IT and the users.
• Trust among IT staff.
• Coordination.
• Cooperation.
• Sharing ideas, solutions, etc., among IT staff.
• Less duplication of efforts.
• Areas of responsibilities not well defined.
  
• Confusing IT problems and people problems.
  
• Lack of understanding of where we are going.
  
• Equitable distribution of workload, based on accurate data.
• Better workload data.
  
• Differentiating between IT support and those people who support IT.
  
• Need to satisfy requirements of the IT security plan.
  
• Staffing, resources, and time to test, assess, and report upon alternative solutions.
• Explore new technologies.
  
• Classroom and lab scheduling.
  
• Campus event coordination.

Responses to questions and comments

I've gotten interesting questions, comments, and suggestions since my last post. Here are my thoughts on them:

• "While I can see the value of an integrated IT for the University, I would not like us to lose the 'personal touch' provided by our dedicated college support staff. I would assume faculty and staff in each of the 3 academic colleges feel this way about their own IT unit. Ours is really special and I feel strongly that they should remain independent."
  
  Providing good service and a personal touch are essential to successful IT support. What we have to do is to focus on the services being provided - the outputs, in computer nerd terms - rather than on the current structures that provide those services - the inputs. It's hard to separate the two when we're so used to how we've been doing things, but too often, the current structure gets in the way of providing the best service.
  
  
• A related comment: "We don't want to lose the autonomy that lets us provide the services our unit needs."
  
  Our emphasis must be on the needed services. Where autonomy is necessary to provide the services effectively, we should support it. If it isn't necessary, autonomy has to be weighed with other goods like efficiency, economy, consistency, accountability, and communication.
  
  
• " Why isn't Computer Science's IT group/staff listed under Academic Affairs?"
  
  When I made the list, I was thinking of CS as an academic services unit, sort of like Distance Ed, rather than as an IT unit. This relates to questions that we discussed in the TCC (Technology Coordination Council) yesterday, and that I'll talk about more in my next post later today: Who is an IT person? Where should we draw the line between IT and other functions, especially when somebody wears several hats?
  
  
• See Mike's comment on my previous post about computer labs. He makes good points.
  
  
• "How do our comparable institutions organize IT?"
  
  Finding out that is part of the fact-gathering I'm just starting. I'll post what I find.
  
  
• "Does this reorganization effort fit with the UWG strategic plan being developed?"
  
  Definitely. The plan is still in the draft stage, but it includes these subgoals under the "Managing Resources" goal:
  
• "Organizational Assessment/Reorganization Efforts to increase functionality, eliminate redundancy and review the outcomes of the organization."
• "Customer Service Improvements"