[Updated May 2008]
We've come a long way towards solidifying the role of the Divisional Liaison within the campus IT community. Some of our greatest wins as a collective body are in our ability to shape services, understand each divisions' priorities and find opportunities to collaborate on ideas that will eventually turn into campus services.
We've slowly moved ourselves towards good meeting practices that include agendas, meeting notes and trying to talk one at a time. On occasion, our guest presenters may feel a bit pummeled when they receive a flood of comments, some rather pointed about their projects; especially when they result in more work (either real or perceived) by the DL's on their operations.
Typically, we are trying to get project updates early in their development so that we can help shape the thinking for a particular project or service development. We regularly keep an eye on desktop related projects (Standard Desktop Services, LANDesk, Eudora Migration, CruzMail, CruzTime, CruzNet, etc.). Our input to these projects helps identify information from the divisions that will impact how a project or service can be implemented with as few disruptions as possible. Other projects that require DL input include Customer Request for Services Provided (CRSP), which has the goal of understanding how we take on work, prioritize work and work with our units and divisions to fund new systems and services.
One of our latest accomplishments has been in the collaboration and incubation of ideas into services that meet our needs where central, global services do not yet exist. Over the past six months, we've started to use SoE's nagios server to monitor servers across campus, established a VPN pilot, and shared hiring of staff between divisions.
Some of the challenges that need to be addressed so that we can continue to move forward on many different fronts include understanding our capacity for operational and project work, priorities in our divisions and within ITS and continuing to migrate local services to global services where ever possible.
[June 2007]
Account Management
As I prepared a presentation for the UC Computing Support Conference, I spent some time working on understanding what and how aspects of account management were applicable to my work as a DL. In essence, without expanding account management to take on more systems, that work falls to the system support.
[Updated June 2006]
As I settle into a new role with the ITS division, I've been tracking issues that have arisen for me in my personal and professional transformation into the ITS division. Some of these issues are specific to me and others are likely applicable to my colleagues. I'm tracking these issues so that as I run into obstacles I have a method to inform our management and engage in resolving process issues.
I started tracking these issues about a year ago as I was in the middle of the who's in/out process. Much has changed, even up to yesterday, where a joint meeting of SMT and the DL's helped develop a unified vision of staffing transitions.
I'll be updating this page with some new thoughts and challenges for the DL role.
- What Matrix Management means to me
- Internal ITS communication
- Who's driving the bus on services and service levels?
- How much risk can the campus (or a division) absorb?
- Thoughts on managing my divisions' needs.
[The comments below were posted in March 2006]
The DL role has be to be able to advocate with Principal Officers, managers, line staff, ITS plans and vision without necessarily having accurate information from SMT or units within the division. I think of this as a communication process challenge.For example, no written communication from ITS has been made to BAS units regarding current status of the ITTP, current status of desktop support plans, current status of server or application consolidation. This leaves the 10 DL's to communicate 10 different messages to 10 divisions, diluting the effectiveness of delivering a change message.One strategy is to supplement the DL toolkit with packaged information via the PMO. Elevator speeches, and canned presentations would help me as I go out to speak to 13 units about how ITS is approaching service delivery in different areas.
The DL role has little no authority to commit to service delivery. For example, I have worked to take two open provisions (salary dollars) from BAS units. I have been instructed to not commit to a service delivery in return for those dollars. While I understand that more work is necessary to determine where we will make hires and there is no clarity on what "typical" desktop service will look like, it leaves me in the uncomfortable position of communicating, "we don't know yet" to my units.
The DL role has no authority to speak on behalf of ITS. For example, in years past, I have been empowered to speak on behalf of the Vice Chancellor on IT issues to BAS unit directors. To-date, I have not been delegated similar authority for ITS.
The matrix-managed organization hasn'y yet evolved beyond a first round of talking. For example, when I need to change a desktop service priority to high, I need to make a decision on whom I need to alert: the individual performing the work? the supervisor of the individual performing the work?, the manager of the supervisor? , do I fix it myself?, or, do I ignore the request for help and ask the individual to have faith that we'll get their problem fixed in due time. In essence, the DL role depicted in the diagram is inaccurate. My "view" into ITS is not from a single point of contact (ITS Directors), rather individuals at two and three levels below SMT, who I know can answer my questions or resolve my issues.What may help me understand the matrix approach is to see some comparison higher ed institutions who have several years of metrics on the effectiveness of this management approach.
The staffing level for maintaining desktops is insufficient. This leaves me in the position of having to maintain desktops or simply ignoring user requests for help. Desperate individuals who are unable to conduct their work are contacting me. Where possible, I am utilizing the 2 BAS FTE who are available. However, some of the priorities of the DL/divisions and ITS are not necessarily in sync. For example, the BAS priority is on stabilizing the desktops. This has only recently become articulated by SMT via the Support Center project.
The risk of failure continues to grow in those units where insufficient desktop support is available. For example .25FTE used to support 40 workstations. Now that same .25 FTE supports 80 workstations. This situation isn't the fault of ITTP or BTP, but is a campus planning issue; no serious debate was given to how BTP or ITS would support the desktops and applications necessary to run the enterprise.
The DL role has the potential for becoming less involved in Divisional issues as the DL becomes perceived as an ITS employee. This will manifest itself in the DL not being at the table with the Principal Officers, AVC/AD, or unit directors on significant issues where IT may play a role. For example, when VPIT Merkley or a SMT director presents a fundamental funding or policy recommendation to Principal Officers, the DL's should be informed at nearly the same time and should understand the issue (and ITS perspective) well enough to answer questions or escalate questions from P.O.'s to the appropriate person.
I'm beginning to think the DL role is more akin to an Assistant Dean or Assistant Vice Chancellor in its day-to-day operation. In my observation, the role is mainly about being "out there" in the division vs. spending most of the day in one place. For me, this means getting regular touch base meetings setup with unit directors in BAS to make sure we're getting feeds of information flowing in both directions. It also means additional "desktop diving" as I struggle to take on oversight over more desktops, servers and supporting databases.