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