Response to Administrative Systems Campus Out Reach effort

Dataweb Team, IT Workforce Planning meeting members, and Cathy's directors,

In late September Cathy gathered a number of people together (Betsy East, Mike Hammer, Mark Sanford and myself) to gather our reactions to some draft IT Workforce Planning Documents she had received. The two big action items that came out of that were that we wanted to help CIT understand 1) how academic computing is different from administrative computing (which appeared to be their primary focus in the documents they reviewed) and 2) why it is important that they include colleges and departments as true stakeholders in their decisions.

Below is an early effort to address these (particularly the latter item). It is also probably my most cogent description of and justification for the development approach we're taking with GAPS and the Faculty Data Web. I am not convinced that this document will make much difference in how CIT works. That said, it is good practice for when we'll be making the same case when we ask the functional units to help with the Faculty Data Web.

I'm sending this to you primarily as an FYI. The document has already been sent to CIT. That said, I would happily read any comments you send me.
-Paul

Here's the context for the document:

In November Karel Sedlacek from CIT invited people from across campus to meet and comment on why we have the administrative systems we do. As far as I could determine, the intent was to gather our input into a document for input into the IT Workforce Planning effort and to guide improvements to data services. Since then Karel has indicated the document will be uses as input to CIT's strategic planning effort as well. By and large OIT's Workforce Planning effort has been a closed process with few formal opportunities for high level input so this was our first formal opportunity to address our action items.

Karel requested we provide input during a meeting and follow up with a written summary. Much of the discussion during the meeting was about including colleges and departments as stakeholders in administrative systems decisions. This is an issue that is close to my heart, but I was, by no means, a lone voice. In the written summary, Karel asked us to address some specific issues in our responses which I do briefly below. During the meeting he asked us to address the stakeholder issue in the document which is the bulk of the document below. I do this by describing three department led development efforts and the lessons we can take from them.

The final document, which includes my comments is available here. It has a very nice executive summary.

Date: Wed, 07 Jan 2004 12:03:10 -0500
To: Karel Sedlacek <kvs1@cornell.edu>
From: Paul Davis <prd9@cornell.edu>
Subject: Re: Data Administration Campus Out-Reach
Cc: cel3@cornell.edu (Cathy Long), cth3@cornell.edu (Craig Higgins), dme9@cornell.edu (Dawn Esposito), ere2@cornell.edu (Betsy East), ldh3@cornell.edu (Mike Hammer)
Bcc: ƒ\Work Force Planning

Karel,

Here is the response to your query. I've copied the other people from Engineering invited to the November 10th meeting. Cathy Long and Craig Higgins both commented on earlier drafts of this document.

In response to your query, I have attached the list of local systems we provided for the IT workforce planning effort. I've added newly created systems supported by the college, and, where I can, I have included my best assessment of why we have each of the systems. I have not taken the additional step of interviewing administrative systems' stewards to determine the reason for systems I'm not as familiar with. Obviously this list does not address many business processes that could be improved with administrative systems that would require more resources than are available in academic departments.

I welcome this effort by CIT to identify the "data-related issues having the most impact on [our] business". My hope is that this process will result not only in a list of systems we've built and why, but to the root causes that lead different units to build their own systems to address the same business needs again and again using multiple implementations in multiple  infrastructures. While there are situations where some of this diversity is appropriate, I doubt anyone would argue that Cornell's level of diversity is good business.

My hope is that as a result of this effort, resources will be applied to address these problems. I have no doubt that by doing this we will save resources overall. The issue is how resources are being applied, and by extension, how the resource decisions are being made. Before I present my suggestions, let me describe three examples of administrative system developments that have started in departments and migrated to larger audiences. I feel they have important things to teach us about addressing academic department administrative systems needs in a way that does not lead to one off development. The two examples I know best are from Engineering, but I also describe CALS's Web Financials.

GAPS
Our college has developed a Graduate Application Processing System, GAPS, that allows faculty to view and comment on graduate applications and their scanned loose credentials via a web browser. This replaces a multiple and different paper folder based workflows. Departments that are using this system tell me that it has saved labor for their administrative staff and has improved process consistency, and the quality and availability of admissions data. The biggest win, though, has been for the faculty. They no longer have to return one set of paper folders before they get the next set. They can view each others comments, and they don't need to spend as much time in meetings. The faculty deliver the mission of the university and are it's most expensive resource, so this has been a huge win all around.

Because of the close relationship between the faculty and the academic department staff, leading edge faculty were able to propose this system, Electrical and Computer Engineering built a prototype and used it for two years. The college then funded re-developing GAPS with the intent of expanding the population to four departments this year and the whole college next year. Viral marking among the faculty appears to be making this an easy sell. We have started discussions with the graduate school about having them eventually adopt GAPs for broader deployment and in the process take over its on-going support. Because we adopted an infrastructure that CIT can support, Mark Mara's group sees no problem hosting GAPS, should the Graduate School adopt it. Mark Mara has also told me that when he proposed a similar system, he was told that the faculty would never buy into it. I believe that the close relationship between the academic department and the faculty was vital to this project's success.

The Faculty Data Web -- Pilot
Another example we are just beginning to undertake as a pilot is a project we call the Faculty Data Web. Currently aggregating data about a faculty member is a labor intensive manual process we undergo many times a year. We have to do this for grant applications, compliance reporting, and annual reports to list just a few examples. Like the graduate application processing, this is a process every department does, but no two departments do the same way. We're in the process of re-implementing a web tool initially developed by Civil and Environmental Engineering. This re-implementation will deliver a consistent entry and presentation mechanism and will, eventually incorporate data from many of the disparate university data systems. The resulting tool will also give each faculty member a public profile page that should help market them to students, researchers, and the media. Again, this is not a project the college administration would have prioritized, but the academic departments, when they evaluated several options, felt it was the next priority to address. Our intent is to roll this pilot out first to a few departments and eventually on a college wide basis.

In this case, much of the data we are bringing together belongs to disparate functional groups so our current administrative systems funding process would have a difficult time finding a business owner for this project. Eventually we hope that we can find a business owner, perhaps the dean of faculty, but even after we find a central business owner, using a bottom up approach will be vital to identifying and evaluating the business requirements to be addressed.

Much of the effort in bringing the data together from the different units is adding the appropriate keys to the data sets provided by the functional units (HR, OSP, DFA, etc.). We need to represent account totals by faculty member, courses by the instructors who taught it, space by the researcher responsible for it, etc. Generally the keys to link the functional data to the faculty member don't exist. Initially we anticipate adding these keys in our own system, but we are beginning to make the functional units aware of our effort so they can do the data capture earlier in the data entry process and add them to the warehouse tables.

CALS Web Financials
My final example is the CALS web financials project. This is, again, a project that was initiated by an academic department but had much wider applicability. One of the most important questions faculty need to ask is, "Do I have enough money on this grant to do that?" Currently it involves asking the administrative staff in the department to do a manual calculation using the existing balance from ADW and adjusting it for known commitments. Web Financials allows the faculty member to get the answer from a web site. They can see current expenditures and commitments and know where they stand. My understanding is that CALS has implemented this tool college wide. Engineering and the Vet College are evaluating or planning on implementing it in the near future.

Lessons and Recommendations
In all three of these examples the business need was identified first in the academic department. I believe that in at least two of the cases, the prototype was developed by someone working outside their job description, they just happened to have the web skills needed to develop the tool. Through this good fortune, a small "skunk works" addressed an business need that was important enough to develop wings. Imagine the returns we could achieve if we didn't have to depend on people working outside their job description to produce tools of this type. Sadly, academic departments, and even many college administrations, seldom have the resources to hire dedicated programmers. CIT and the administrative systems group could provide some of the resources necessary. (Engineering does not have the capacity to do our own re-development efforts either, but rather than depend on people working outside their job description, we outsourced GAPS and the Faculty Data Web.)

The CALS example provides an additional lesson. DFA sponsored a presentation of Web Financials for college administrative staff across the University. Unfortunately, the benefit of this sort of tool accrues to the departments, not the college level. As a result there wasn't as much interest as I believe their would have been if it had been presented to department level staff. My understanding is that that fact, combined with the fact that the tool was written in perl lead DFA to drop thoughts about centralizing the tool.

There is a further lesson in the CALS effort. Since the DFA presentation, the tool has been re-developed in VB.Net, CALS standard infrastructure. Unfortunately, while it addresses concerns about perl, the new platform choice makes the tool unacceptable to DFA for adoption and University wide deployment. If CIT had a standard recommended architecture and could entice units to adopt it by providing development resources and support based on that platform, Engineering and DFA would not be in the position of evaluating whether it makes sense to re-implement the tool a third time to conform with our infrastructure standards.

I do not want to imply that valid business needs don't exist at all levels of the University, simply that academic departments, like college and central administrations, and functional and enterprise units have vital business needs that need to be addressed. Because of the particular history of the University, business needs held by the most distributed levels of the University don't tend to be addressed by centralized solutions. By including appropriate stakeholders from all these groups, academic departments, college and central administrations, and functional and enterprise units, in prioritizing administrative systems projects, I feel we will begin to see more balance in the University's administrative systems portfolio. I believe a better balanced portfolio would do much to leverage the efforts of both our faculty and academic department staff. Furthermore, because this area has been so neglected in the past, the returns available may be greater than in areas that have historically received more resources.

Below are a few concrete suggestions for making academic units true stakeholders in the administrative systems decisions. Obviously, as requested, these suggestions address administrative systems primarily. Suggestions could also be developed for improving stakeholder-ship for research computing, instructional computing, and outreach.
- Earmarking a substantial amount of the yearly Administrative systems funding to systems prioritized and specified by the academic units
- Including members of the College Officers Group (COG) or their designates and a few carefully chosen academic department managers on the ASP (or what every group eventually is charged with overseeing the Administrative systems funding)
- Work to change the culture in the functional groups from, "We'll provide the systems you need" to, one that asks, "what are your business needs and what systems can we build together to meet them?" It is important that new systems address the processes being effected prior to the point when functional units get involved in them.
- Actively seek out "skunk works" projects developed by academic departments and colleges and provide resources to redevelop them for broader scale use.
- Work to help units coordinate the "skunk works" they focus on. It would be terrible if another department was develop a Graduate Application Processing System at the same time we were. Currently there is no way to know if this is the case.
- Actively seek out common academic department's business needs and identify potential solutions to feed into the administrative systems evaluation process. Keep the academic departments as the business owners of the solution or at least keep them in the roll of defining the business needs to be addressed.
- Include colleges on a panel to develop a set of recommended infrastructure targets, both for development environment and target client computers. Then support those targets with incentives. College's needs and resources are likely to be different than the functional units. Also, including us may lead to greater buy-in for the resulting standards if the process is run effectively with appropriate constraints.


Additional Administrative Systems We Are Considering Undertaking:
To address Karel's final question, we are considering or undertaking a number of additional administrative systems developments in the next year. Academic departments may be considering other projects I am not aware of, though much of their effort is directed at the data web projects described above. At this point we have committed to only the first one listed below:

Redesigned Web Presence
We will be completely redesigning our student services web site and implementing it on a CMS. Proposals were due December 15th. The RFP is at http://intranet.engr.cornell.edu/it-public/ . We have posted the proposals and our evaluation notes to a private site. We are very interested in the project CIT is undertaking to host a CMS for the campus, but may not be able to wait until CIT chooses a CMS before we need to select a CMS for our project. We have included Donna Taber, lead for the CMS evaluation in CIT, on our evaluation team.

Pre-Hiring Work Flow
Currently their is a great deal of work that goes into hiring a person before the HR-Online's workflow begins. We are beginning to define the business requirements for a workflow and document management system for staff and faculty hiring. This would address the process prior to filling out the UPAF on HR-Online.

Graduate Student Appointments
Another project that has garnered some interest is a similar workflow and document management tool for student and grad student appointments.

At 09:55 AM 10/28/2003 -0500, you wrote:
I have scheduled a meeting on 11/10 at 10 :30--12:00 in Biotech G01 under the auspices of the Data Administration Committee, chaired by Michael Whalen, to discuss your organization's data-related issues.  I have organized the meeting to include related units so as to provide as much commonality of discussion as possible.  A number of you have indicated who you would like to attend this meeting, and I have included them in the distribution of this invitation -- if you have not done this already, please let me know in response to this invitation.  Feel free also to update you current list of attendees in response as well.

Preparation
I would ask that your college or unit prepare a concise, written listing of your data issues, and to forward that listing to me ahead of meeting time, if possible.  Please include issues that are actively being resolved.

The general question to be considered is:

What data-related issues are having the most impact on your business?

A possible way of thinking about this is:

“Why do we have a given local system?”
§         Purely for value-added data capture/delivery?
§         Missing or un-suitably defined central data?
§         Inaccessible central data  security?
§         Lack of integration across central systems?
§         Timing of central data delivery?
§         Heterogeneity of delivery mechanisms, formats or business definitions?
§         Inaccurate data in central systems?
§         What about accurate/timely information about the data?

An example might be:  “ we have built (or bought) a local HR system because we can't get an accurate FTE, or Compensation value for non-standard appointments, or a Modified Title date from the central system. ”

or

“ we have our own budget reporting system because in the final days of the budget process we need to create management reports several times a day, but the central budget warehouse is only refreshed nightly. ”

or

“ we need to track soft commitments and provide our own accounting descriptions not available to us in the central system. ”

or

“ we are planning to build web services based Faculty information application that ties diverse central and unit information together.  An integration issue for us is lack of faculty information on class data to allow us to tie it in. ”

As you can see these examples include data definition, delivery, integration and capture issues.


In addition, some “data issues” may include requests for collaboration, e.g., “building a web services based Faculty information application that ties diverse central and unit information together…”   This item leads to the discussion of: ·         Standards that all can build to

§         E.g., Centrally provided APIs (e.g., web services)

·         Commonality of solutions across colleges and units re:

§         E.g., Shared campus application development/deployment  in house, purchased

§         Data definition that work across colleges and units

Agenda
The primary focus of the meeting will be: ·        

Triaging issues as to commonality, impact, scope, solution, ownership, process, etc.

o         Looking for “Low hanging fruit” i.e.,  “if only….”,

o         Is an issue already being addressed?

o         Have they been resolved but not communicated?

o         Are we positioned to respond to these issues?

o         Who owns them, are they aware of their constituency?

I hope to set aside a few minutes to discuss:

·         Is a goal also a long-term relationship with Central Units, CIT?

o         What is the best forum or mechanism?

My intent is to, at a minimum, compile the information across all the meetings into a report in a timely manner, ask for your review; and share this information with various stakeholders including the Data Administration Committee, the Central functional units, and relevant units in CIT.

I appreciate having had the opportunity of speaking with many of you in preparation for this meeting.  Please contact me with any questions.

Karel Sedlacek
(5-7742, kvs1@cornell.edu)
______________________________________________
Paul Davis
Programmer/Analyst Sr.
Engineering Dean's Office, Cornell University
245 Carpenter Hall
Ithaca, NY 14853
(607) 255-6227 (office)   (607) 255-9606 (fax)
mailto:prd9@cornell.edu
http://www.engr.cornell.edu/IT
http://intranet.engr.cornell.edu