The 4 candidates

The four candidates are scheduled for interviews this week, which is a little faster than I said in my last post.

They are, in alphabetical order:

• Matthew Clay
• Kathy Kral
• Mike Russell
• Doug Turner

The VPs have drawn up a list of questions to ask each candidate. After the interviews, they'll make their recommendation to Dr. Sethna, who will make the appointment.

Interim CIO search update

I just got an update from Dr. Hynes on the interim CIO search.

• Four candidates.
• Interviews this week and early next week.
• Recommendation to Dr. Sethna from the VPs by Christmas break.
  

Interim CIO timeline

A bit more info on the hiring timeline:

• VPs are currently reviewing the applications.
  
  
• Dr. Hynes expects to see:
• interviews with candidates this week,
• a recommendation to Dr. Sethna sometime next week.
  

Interim CIO process

Comment: The way this reads it sounds like the applications will be reviewed but no interviews will be conducted. Is this an accurate interpretation?

Response: I don't know.

Comment: Interviews are not required for an "appointment".

Response: Right, at least for an interim appointment. Even submission of applications wouldn't be required for that, as we see in several current interim positions on campus. PAC just decided to do it that way in this case.

Interim CIO status

The interim CIO position:

• The application period closed yesterday.
  
• I don't know how many people applied.
  
  
• HR is going to send the applications to Dr. Hynes.
  
  
• The VPs will review the applications and make the selection.
  
  
• I hope the VPs will move quickly, but I haven't heard a deadline.

Two items

1. CIO job description

• At Wednesday's open meeting we wondered about some of the preferred qualifications for the position. I speculated that the list was a standard one from the web.
  
• That seems right. Look at what Millersville U in Pennsylvania is asking for:
  chronicle.com/jobs/id.php?id=0000531152-01
  It's much the same, though they do specify a master's degree.

2. A techie asked me by email how would people' responsibilities be determined in the revised structure. I asked how the techie thought it should be done. I have permission to post the response:

• "What I would like to see is a structure that clearly identifies the services to be performed and the number of employees required to support that service.
  
  For example, server administration, it has to be taken into consideration that there are Unix servers and Windows servers. Often times each type of server OS requires a different server administrator. How many servers of both types do we have, how many can be combined (if any), and how many server administrators will be required to keep these servers operational.
  
  Then I would either review job descriptions obtained from HR of all IT personnel to determine who already provide this service or obtain this information from the individual IT Managers of the distributed units.
  
  If there are more IT personnel currently providing server administration than is required under the new IT structure, then a process must be in place to decide who maintains this job and who is moved to a new position.
  
  I believe the following should be taken into consideration when making this decision: the services that the servers provide (whether specialty application servers i.e. banner, Public Safety software, etc or printing and data storage), the skill set required to administer the servers and if you have several individuals closely matched in qualifications, then use years of service to make the final decision."

What do you think about this suggestion? What process do you think we should follow?

More on interim CIO

Answers from Dr. Sethna to two questions about the interim CIO position:

• The person appointed as interim will be eligible to apply for the permanent position.
  

• In relation to the proposed reorganization plan, the interim CIO's task will be to:
• refine and flesh out the plan,
  
• be SPA for measures and metrics.

My reactions to comments:

• "You have stated many times that we don't have the funding for a CIO."
• My 60/40 preference was for not having a CIO. The expense was one of my reasons.
• I presented both sides of the argument as fairly as I could to Dr. Sethna and to PAC, and they decided to go with the CIO model.
  
• That decision is made, so I'm trying to do what I can to make it work well.
  

• "It makes no sense to me to appoint an interim..."
• Again, that decision is made. No point in whacking a deceased equine: let's make it work.
  

CIO, open meeting, etc.

Open meeting

• Wednesday, Nov. 14, 10:30, Campus Center Ballroom 108.1

CIO

I don't know the answers to some of the questions asked in comments on my last posting, but here are some answers:

• "Will the interim CIO scrap everything done so far in favor of their own ideas and concepts or will they work in conjunction with the UTO to refine and solidify the proposed model?"
  
• The position announcement wasn't clear, but I think it's the latter.
  
  
• "What is our timetable for hiring or naming an interim CIO?"
  
• The search closes on the 27th. They say they plan to move quickly.
  
  
• "Why hire an interim CIO when we're just going to turn around and create a national search later on?"
  
  
• Whatever we may think of this, that's what PAC decided. I was at the meeting where this was discussed. Dr. Sethna and Jim Sutherland both argued that we should get the reorganization done before bringing in someone from outside, and PAC accepted that argument.
  
• "We have two who could be considered CIO's right now, interim or otherwise."
  
• I disagree, though I like the "let's all get along" plea that followed this. A CIO is a different kind of beast from a CTO or a UTO.
  
  
• "The requirements do not specify a computer science degree or even a technical degree for the 'interim' CIO?"
  
• That didn't surprise me. Since the role of a CIO is to lead, align IT strategies with organizational strategies, and manage, CIOs now come from a wide range of backgrounds. The University of Illinois, for example, has a newish CIO who was CIO at the University of Arizona. She has three degrees in Speech Communication, none in a technical field.
  
• "Is the interim CIO disallowed from being a candidate for the permanent position?"
  
• From what I understand, no. I'll check to make sure.
  
  
• "Sounds like the scenario that was put forth by another poster earlier, where the interim is appointed and then just stays in the job after a period of time seems likely."
  
• That's not what they're saying, and I haven't read that between the lines.
  
• "Should all current employees who will be in the umbrella of this new organization be excluded as applicants? It just seems to me that this would reduce competition and possible hard feelings between people who need to work together."
  
• Any UWG employee who meets the qualifications is eligible. That makes sense to me.
  
• "Will your final IT reorganization plan submitted to the president include IT staff and their new jobs?"
  
• I believe so.
  
• "How/who will determine where current IT staff will fit in this plan?"
  
• I expect that the interim CIO will work with the IT staff to determine who best fits where.
  

Interim CIO search announcement

The announcement is out. I posted it below so we'd have it to look at.

The list of desired credentials looked pretty good. I'm glad to see that PAC didn't construe CIO to mean techie-in-chief, but rather saw the post in terms of leadership, planning, collaboration, and user service.

Let's have an open meeting next week to discuss two issues:

• The interim CIO position: Do we have any input to give the VPs to help them screen applicants?
• Localized faculty/staff tech support: What structure(s) would best provide the advantages of centralization and decentralization?

I'll try to find a place to meet Wednesday at 10:30, if anything is open then. Would a second time be useful, too?

---

Interim Chief Information Officer

The University of West Georgia invites applications for the position of Interim Chief Information Officer (CIO). The University seeks a leader who has significant experience in IT and the skills to achieve goals as outlined by the President and senior administration. The successful CIO will support the existing IT operation, and develop managers and staff to meet goals and continue a history of strong customer service.

Responsibilities:

The CIO will report directly to the President and have access to the President’s Advisory Committee. The overall leadership and general administrative responsibilities for the University of West Georgia’s IT organization including academic and administrative computing, telecommunications (telephone, distance learning, and cable technologies), data administration, network infrastructure, web development, software and instructional technology support, and system support services. The CIO provides leadership in the development and monitoring of an IT plan and fosters a culture that is collaborative and user oriented.

Qualifications:

An earned Bachelors Degree from an accredited institution is required, a Masters Degree or higher is preferred. Other preferred credentials include:
§ Abilities in the planning, development and implementation of IT goals for administrative functions of a complex organization.
§ Ability to identify and communicate a vision and mission for IT aligned with university priorities.
§ Experience in program evaluation, curriculum development, and assessment of educational outcomes and knowledge of alternative approaches in advancing academic excellence.
§ Ability to build teams among IT staff.
§ Ability to work with and provide support and leadership for multiple constituencies including faculty, students, staff and users external to the University as needed.
§ Commitment to diversity and an understanding of the links between campus diversity and academic excellence.
§ Experience with strategic and tactical planning, problem solving and crisis management.
§ Budget development and management abilities.
§ Familiarity with security issues, IT policy development, legal issues regarding technology, and business continuity.
§ Ability and willingness to communicate openly.
§ Capacity to maintain currency regarding IT policies, issues and trends; ability to comprehend, interpret and effectively communicate complex technical information.

Application Deadline: November 27, 2007

Waiting for Godot

I understand that the SPAIT job description is in final edit mode, and should be released "soon."

Quote from "Waiting for Godot":

• Vladimir: Well? Shall we go?
• Estragon: Yes, let's go.
  
• [They do not move.]
  

Putting IT in context, and 2 questions

Putting IT in context:

Dale Driver has created an interesting graphic depicting how the IT organization could be guided by other University entities:

Two related questions:

Thinking about the interactions among IT and its stakeholders raises two questions:

1. How can IT assure users that they will get good service?

• SLAs are part of the answer, but not a complete one.
• With local control of "their own" user support techies, units believe that they can guarantee good service.
  
• The flip side is that this same local control can be an obstacle to following best practices, being efficient, and even being as effective as we'd like.
  

All this gives rise to my second question:

2. How can we get the virtues of both local and centralized accountability?

• When I met with RCOB this week, people suggested matrix and federated management models.
  
• Those seem promising, but we'd need to think through the devilish details, like these:
• How would primary and secondary reporting lines work together?
• What kinds of articulation agreements would work in these situation?
• What structures would support management interaction?
• How would conflicts be resolved?
• Exactly what responsibilities would be assigned to each group?

Thoughts?

In the meantime...

While we wait for resolution on the SPAIT (Single Point of Accountability for IT, known elsewhere as CIO) issue, there are things we can do.

One of the most pressing is to start working on service management issues:

• Service catalogs
  
• Service level agreements
• Operational level agreements
  

We'll need these whatever plays out with a CIO. I mean, a SPAIT.

Some good resources:

• Service catalogs
• IT Service Catalogs in 5 Steps, by Hank Marquis of itSM Solutions.
• The Open Source Service Catalog Community has a number of interesting articles.
  

• SLAs
  • Guidelines, templates
    • Establishing Service Level Agreements, by Naomi Karten.
      
    • Guidelines for Public Sector Organisations from New South Wales, Australia [PDF]
    • SLA toolkit
  • Examples
    • USG OIIT Service Level Guidelines (PDF)
    • Earlham College
    • GeoNOVA Service Level Agreement Template (PDF)
    
    
• OLAs
  • Solving the IT Silo Problem
  • Operational-level agreement: An IT game plan for CIOs
  • Duke University

The guidelines from New South Wales provide a good summary of the benefits of SLAs. An SLA:

1. Sets clear performance expectations of the customer and service provider .
2. Clarifies the roles and responsibilities of both parties.
3. Focuses attention on customer's priority needs.
4. Encourages a service quality culture, and continuous improvement.
5. Provides a mechanism for both parties to plan for the future.
6. Puts purchasing power into the hands of the customer.
7. Provides a useful tool for the customer to monitor performance.
8. Puts service providers in a better position to plan their delivery functions.
9. Can provide greater certainty of income for service providers.

Karten's article gives a good overview of how to create successful SLAs. I especially like these sections:

• How Not to Establish an SLA
• Key Steps in Establishing a Service Level Agreement
  

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

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: