Assessment of CIT Services for College Intranet

I wrote the following email to Mark Mara of CIT in order to frame a discussion and to present my perspective. I wrote almost all of it in a four hour sitting before work so it may contains factual errors. (Correcting these misunderstandings on my part, was, after all, part of the reason I wanted to talk with Mark.) As I learn more, I will try to correct and update this document as I can, at least through our intranet discovery phase.

• Single sign-on authentication (CU Web Auth / Kerberos)
• Web content management (CommonSpot)
• Data delivery and reporting tools (Brio)
• Portal infrastructure (uPortal)
• Directory services (LDAP directory, Authorization directory)
• Web collaboration tools & project workspaces (not currently offered by CIT)
• Work flow management (Web Methods, OneStart, & DFA's MetaStorm)
• Document management (Fedora, Hein On-Line)
• Course management (BlackBoard, Sekia)

• Single sign-on authentication (CU Web Auth / Kerberos)
• Web content management (CommonSpot)
• Data delivery and reporting tools (Brio)
• Portal infrastructure (uPortal)
• Directory services (LDAP)
• Web collaboration tools & project workspaces (not offered by CIT)
• Work flow management (Web Methods, OneStart, & DFA's MetaStorm)
• Document management (Fedora)
• Course management (BlackBoard, Computer Science's course management system)

• Because CUWebAuth using sidecar re-authenticates the client each time it serves a document, it slows down web pages unacceptably. This is particularly a problem with byte served pdf documents where each time you hit the scroll bar you have two wait for a full re-authentication of the client. On our existing intranet we have addressed this by using CUWebLogin, but this is not an optimal solution. Currently my plan is to us CUWebAuth to authenticate users the first time they come to our intranet and then use CommonSpot's built in cookie based session management to authentication transactions from that point forward.
• CIT's implementation of Kerberos means that each user can have only one login account. This is a problem for development and testing. Our intranet will display different information for different users and thus, we will need to create a "back door" authentication method to address this. This back door will also allow us to include people without netIDs, such as our vendor's programmers, to use our site. We will use CommonSpot's user management for these accounts.
• I have asked and been promised to be included in assessments of functional needs for the future of single sign on for campus. Despite repeated promises to include me in a focus group over or other input mechanism over the last few years (the most recent promise was in May), none of these offers has materialized. I have little confidence that my input will be considered or our needs will be addressed. It is unlikely that CIT will deliver less functionality in the future, so I think there is little risk with our current plan.

Steve Edgar from Andrea's group in CIT has called me about these isseus and the directory. I will meet with him shortly to explore the guest authentication spec and see if that meets our needs. We'll also talk about the speed issue of CUWebAuth.

• It is very hard to use and to navigate.
• You can't have a URL that leads directly to a portlet, so you can't share an important portlet with others.
• The channels you need aren't in the default set up and the default channels aren't very useful.
• Adding channels is arduous, even when you can figure out which channels to add from the very limited descriptions available.
• The campus news available on the default portlets is often out of date.
• The system is slow. So slow it exacerbates the already weak usability.
• From an intranet design perspective, currently we can't provide a default group of portlets to our users based on their job title. This is a fundamental piece of functionality we intend to deliver to our users.
• The governance of uPortal is in the hands of CIT technologists, and as such, is unlikely to ever meet our business needs as delivered. Our web vendor may be able to modify uPortal's delivery to meet our college's needs (as CALS is attempting to do), but it may be easier to develop our own portal implementation (either a uPortal implementation or from another vendor).

Directory services: CIT has put a great deal of work into it's LDAP implementation and it serves well as a phone directory. It currently has relatively weak membership authorization functions and CIT is planning on developing an entirely separate authorization directory. In both cases it appears that there is no functionality for authorized department staff to assign membership to other staff. The permit server provides some of this functionality but it is slated for retirement and does not have a good, general purpose user interface. It also does not allow our CMS to capture the full set of permits for a given person in one query. This later requirement is a necessity for our CUWebAuth work around (see above).

The end result is that we will build our own staff directory tool. Ideally we would want to develop a web interface for our tool, but a lot of authorization checking and validation needs to happen in the user interface so it may make sense to use a FileMaker interface. Clearly, once the campus LDAP system can incorporate our membership information, we will be in a position upload our membership data into LDAP. We may also be able to provide our tool as a general purpose front end for the campus LDAP authorization directory.

My immediate plan for starting discussions about the directory are to write up our business needs and perhaps the beginnings of a functional spec for our "people and memberships" tool and then discuss them with Steve Edgar (see above) and whomever esle would be appropriate and see how we can best work together.

Web collaboration, project workspace & knowledge management tools: CIT offers no technology offering in this space. Based on the success of the CMS purchase, if there is enough interest, I may propose a similar process to choose a campus solution for this domain as well. (At the first CommonSpot SIG meeting I addressed the history of the CMS purchase process and why I think this process was so successful.) Lacking broad interest, Engineering may select and purchase its own solution.

Work flow management: Currently there are three workflow solutions available or being considered on campus. DFA uses Meta Storm but they are phasing it out. CIT has a workflow tool associated with Web Methods but it hasn't been offered as a service and, if Kuali is adopted, it likely to be superceded by Kuali's OneStart work flow solution. In this case, financial transactions will be managed by OneStart so it is likely to become a campus standard.

Unfortunately, CIT plans on maintaining governance for this project internally. CIT's prior track record for projects governed internally is not good. See my notes about uPortal and LDAP above and the counter example of the CMS purchase. This gives me little hope that this work flow system implementation will be suitable for our business needs, especially on it's initial delivery.

As a result we will try to put off projects that require work flow and should CIT's option not be acceptable, we will augment OneStart, or develop or purchase our own.

When I left UC Davis 5 years ago they were using the University of Indiana's Work flow solution (in conjunction with the financial system they had acquired from Indiana). From what I saw, the work flow solution was well received but was, at the time limited in scope to financial transactions. OneStart has clearly moved beyond what UC Davis adopted.

Our graduate application processing system (GAPS) uses a custom work flow and document management solution which is unsuitable for more general use, though we will continue to use it for additional modules we add to GAPS such as faculty search processing.

Document management: We will want some document management functionality associated with the workflow tools on our intranet. Currently GAPS stores scanned documents on the file system and stores the metadata in a database. This doesn't allow full document life cycle management but will probably be acceptable for our initial needs. From what I've read, Fedora it targeted at a very different set of business needs and may be more suitable, but I don't know enough about it. We're only beginning to understand what our business needs are likely to be in this area, but clearly we would like document versioning, rich indexing and searching, ability to tie a document to the work flow that produced it, metadata and knowledge management functionality, and finally archive and destruction management.

Possibly course management: CIT offers Blackboard as a service but I haven't evaluated it. I know that Computer Science offers a similar home grown service as well. I have done no business needs assessment in this area.

----------------------------------------------------------------------

Governance models

CIT's CMS selection process was very promising. The history of the selection process and outlines of the governance model are described in the CMS SIG kick off meeting presentation. In planning this governance model I wrote a document about Improving Stakeholder Involvement in IT projects .

My thinking has changed a bit since I wrote this. I wrote it from end users perspective up. More recently I've been thinking about it from the executive sponsor's perspective down through a steering committee, that is influenced by an advisory board and a SIG, and has oversight of the project manager. I think the best description of this sort of approach I've seen recently was Sarah Hale's description of the governance model for the GAPS project once it is taken over by the grad school. See below:

How will we make sure that the on-line application working group includes PeopleSoft representation?

We recognize that PeopleSoft integration issues need to be taken into account in development of the on-line admissions application.  We will develop a leadership structure for GAPS that will involve stakeholders from Engineering, CIT, the graduate faculty, the graduate field assistants, and the Graduate School.

The governance model relies on:  1) a steering committee of six individuals--two each from the College of Engineering, CIT, and the Graduate School--to guide the GAPS implementation; and 2) an advisory committee of 10-12 individuals to report to, and advise, the steering committee.  CIT would be represented on both the steering committee and the advisory committee.  We will ask CIT to appoint individuals who have technical knowledge of PeopleSoft and who can assist in representing the functional aspects of the PeopleSoft implementation as appropriate.  Functional PeopleSoft issues would be represented on the steering committee by Sarah Hale, who is a member of the University Admissions Advisory Group convened by Doris Davis as part of the PeopleSoft implementation. We would also ask the Graduate School's functional lead for the PeopleSoft Admissions effort (Doug Elliot) to serve on the advisory committee in an ex officio capacity (meetings only) as a link between the projects; that individual would serve in an advisory role only and would not be asked to take on any tasks for the committee.

Steering Committee:  As noted above, CIT will appoint two individuals (at least one of whom has technical PeopleSoft knowledge) to the steering committee.  Engineering will appoint Paul Davis and Craig Higgins to the steering committee.  The Graduate School will appoint Sarah Hale and John Tonello to the committee.  Craig Higgins and Sarah Hale will co-chair the committee. 

Advisory Committee: The 10-12 person advisory committee would be comprised of the two steering committee co-chairs, graduate faculty representatives, graduate field assistants representatives, and other staff as appropriate.  The Graduate School PeopleSoft functional lead would serve in an ex officio capacity (meeting attendance but no assigned tasks).  The charge of the advisory committee would be to:  1) assist in defining functional requirements for the on-line admissions application and the on-line application review system (GAPS); 2) prioritize requests for system enhancements; 3) develop communications and training plans; and 4) provide constructive comments and criticisms.  Advisory Committee members would be expected to attend one meeting per month and to provide ongoing advocacy for the initiative as well as to assist with testing and training as appropriate.

Open Membership Working Group:  We also envision an open membership group--tentatively named the Cornell Application Review and Tracking (CART) working group--chaired by members of the advisory committee.  This group would be comprised of faculty and staff who share an interest in graduate admissions.  The advisory committee would report to this open membership group to ensure that graduate faculty and field assistants have a voice in the GAPS implementation.

I will note that even the right organizational structure can still fail due to "implementation details". Here are some examples:

• The wrong stakeholder concerns are identified when choosing members for the steering and advisory committees. For instance the steering committee could founder because it includes powerful members who don't care about the project or service. Alternatively the results could be seen as illegitimate because powerful people who do care are not consulted.
• The individuals placed in the steering and advisory committees are not given the right charge. For instance, if the steering committee members are supposed to represent the campus needs, and they represent their own interests, the results could be seen as illegitimate. (Thanks to Mark for this example and for making me thing about this. Based on his suggestion, I would propose that each steering committee member be given an individual charge. In most cases it will include representing the needs of a specific body of stakeholders.)
• The steering committee is not created early enough in the decision making process or is not given the time they need to get the stakeholder input they need to make a decisions that are viewed by the broader stakeholders as legitimate.
• The steering committee does not have the leadership, skills or resources it needs.

Informal Relationships

Organizational culture, forums for open communication at many levels of the organization (especially between middle managers), and the informal relationships within and especially between units are also important considerations for effective discovery and governance. It will help us get beyond thinking of CIT or the functional and academic units as "the other". We need to see that we are all in this together. There are several ways we can encourage this:

• Create training opportunities that would be of interest to and open to all IT staff across the university.
• When either the functional and academic units or CIT has a retreat, if the topic is appropriate, invite members from other units to the retreat.
• Continue and expand the very effective CIT Division Forums. Perhaps add an explicit networking time after the meetings, perhaps with snacks and so forth.
• Functional and Academic unit staff and CIT staff should make an effort to, and be rewarded for, calling each other up for advice, etc. (This of course requires that these staff have slack in their schedule to allow this sort of informality.)
• Obviously the IT administrative systems funding model works against informal relationships on many levels. Fixing this would be a great help in many areas.

Getting Stakeholder input

One of the big problems with gathering sakeholder input is getting the stakeholders interested enough to become engaged early in the process when their input can be really useful. Once they can start seeing what is happening, normally late in the implementation phase, they will get themselves invovled, normally to the detriment of the project. There are many examples of decision processes where stakeholder input was taken, but important and powerful stakeholders didn't get involved until too late and they stopped the process during the implementation phase or later. The earlier stakeholder process wasn't seen as legitimate.

This leads to the question, what are the best ways to gather stakeholder input? How do you get them interested in the issues early enough to be useful to the process? And the related question, how do you educate them enough so they are interested and their input is useful?

There is a whole discipline associated with gathering stakeholder input and requirements. Actually they are sub-disciplines of many different areas. The area I know most about, because of my wife's research, is public participation for technical decisions, siting hazardous waste facilities in her case. Fortunately, for Cornell, we all have a common organization and mission so many of the really difficult issues she studied are much easier here.

I think the most important things I've learned from the public participation literature is:

• Getting disparate stakeholders to work together is possible, it takes time and resources, but done right the results are seen as legitimate and there is real buy in. The buy in creates opportunities for synergy and for real respect accross organizational boundaries.
• The stakeholder process, by it's nature educates all the participants. They are likely to be a supporter for a outcome they might have been opposed to without that education.
• Stakeholder processes, done right, can turn the biggest enemies of the project into the biggest supporters of the outcome (sometimes).
• Done wrong (stakeholders input doesn't have the expected impact on the outcome), a stakeholder process will educate the stakeholders who are opposed to the project and they will become more formidible enemies.
• It generally doesn't serve your purposes to do a stakeholder process half way, either you are interested in their input and it will use it, or you may not want to do the stakeholder process.
• A stakeholder process is very different than a series of focus groups or user input sessions. The focus group participants and users are unlikely to have, or through the input session, to gain a great deal of knowledge of the situation. They are unlikely to become invested in the outcome. As a result of their lack of interest and knowledge, generally they don't provide much useful input. In a stakeholder process, the participants have a real stake in the process, they become educated through the process, and it is clear to them that they will have an impact on the outcome. They can see the value of their effort.
• Stakeholder processes work better when failure would clearly be worse for all the stakeholders invovled. All the stakeholders have to know that their is a hammer over their head (and what the hammer is) if this doesn't work. Sometimes you have to work hard to educate the "under interested" stakeholders about the "hammer" to get them interested.
• Sometimes you can be creative in creating that hammer. The Tanner Act uses government policy to define failure and create a situation of great uncertainty for both sides if failure of the process occurs.

Now to switch gears to a more directly relevent material, my brother does IT consulting associated with developing new systems for banks, etc. The way he describes his standard practice is they do a day long retreat with the president of the bank and the prime stakeholders. For the first half of the day they teach the stakeholders about the technological options available (it used to be screen scraper type integration, more recently he's been data integration with a web front end). For the second half of the day, they start by using the mission of the organization to help decide what projects to focus on. The education from the first part of the day informs the discussion about what projects are possible. Obviously, before the retreat, my brother and his team do a lot of preparation and have a list of problems (and possible projects) they can address. This also helps them focus the presentation of the technical options.

I've discussed some of the tools I use to help develop shared understanding in meetings on my list of project management tools.

IT as an Organizational Change Maker

My feeling is that because the technology that IT introduces is often a disruptive force in business processes, the technology has to be married to the business purpose and business stakeholders. As an example, our intranet project will be documenting business processes college wide. We could simply document the processes that are in place in each department and let people from each department use their department's version of the process. Or we could encourage and work with the business stakeholders college wide to have them develop common processes. This tehcnology project provides a great opportunity and impitus to identify needlessly disparate processes and help make them more consistant.

The Administrative Systems Funding Model

It is clear that the Administrative Systems funding model drives the IT governance and decision making behaviors we see on campus, both within CIT and across campus. It also explains why CIT's Admin systems group has historically seen its customers as the ASP, rather than the campus at large. It is not clear that this can or will change in the short term however. That said, I think there is much we can do and a great deal of interest in improving IT governance and behaviors accross campus.

______________________________________________
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://intranet.engr.cornell.edu/intranet/it
http://intranet.engr.cornell.edu/home/prd9