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.