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: