Thursday, January 3, 2008

Moving beyond version 0.6

As Kathy settles in as interim CIO, she will finalize the IT reorganization plan.

There will be a meeting for IT staff next Friday, the 11th, to outline the next steps. In the meantime, Kathy would like some feedback:
  • "One thing I would like feedback on is the 0.6 model with the two areas reporting to a CIO. Also, I would like to add project management to the list of items under Service Management Admin. Is that a good fit?"
Please post your thoughts.

Monday, December 10, 2007

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.

Monday, December 3, 2007

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.

Friday, November 30, 2007

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.

Wednesday, November 28, 2007

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.

Friday, November 16, 2007

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?

Tuesday, November 13, 2007

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.

Monday, November 12, 2007

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.

Saturday, November 10, 2007

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

Thursday, November 8, 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.]

Friday, November 2, 2007

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?

Thursday, November 1, 2007

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:
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:

Wednesday, October 31, 2007

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.

Saturday, October 27, 2007

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.

Friday, October 26, 2007

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

Thursday, October 11, 2007

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.

Wednesday, October 10, 2007

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:
  • 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.

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