IT Council - George Mason University

Tech Council Notes
2/10/04

The only agenda item was a report from the options subgroup and a discussion of their proposal.

Anne gave a non-technical overview of what the group accomplished. She handed out a report from two School of Management graduate students, which gave an overview of content management systems.

In brief, they looked at 1) content management systems (management content for individual web sites) and 2) enterprise content management systems (allow you to manage content across multiple websites). Enterprise systems cost between half a million and a million dollars, but don’t allow you to share content across web sites, across the enterprise, which is one of the major requirements of our system.

If we can’t share content, we aren’t close to what we want GMU’s web architecture to do. This led to the proposal from the subgroup: to implement a mini-enterprise content management system. This system would be organized by type of information and not by unit. This would enable data sharing across the units. This requires us to have a system that allows us to build sequentially, to scale up from one mini-system to another. This means that we are adding to our requirements list.

Anne described briefly the Duke University presentation at the Mid-Atlantic Regional Educause conference. (See their pilot report online at http://www.aas.duke.edu/comp/fds/pilotreport.pdf). This is an example of a mini-content management system focusing on topic and not unit. Duke has developed one that focuses on faculty data.

The discussion that followed showed a consensus to proceed with this approach, and Anne walked the group through the specific recommendations of the subgroup.

1. The University should move toward implementing an enterprise Content Management System (eCMS) to achieve the desired web functionality.

2. Since this could be an expensive undertaking, the move should be done in stages, developing modules that enable the University to manage one kind of information across the enterprise and gradually adding modules as development resources become available. The group suggests defining a pilot program that would focus on one kind of content that could be managed.

a. Selecting an appropriate pilot is important to the ultimate success of the project. The pilot should be something that is currently problematic, so people will have an interest in the solution. The pilot should involve data that is used in multiple places on the web site so people will get a sense of the power of a CMS. The pilot should draw on one or more the projects already underway in order to use resources effectively. The pilot should be in an area where processes and procedures are already in place that the CMS can support.

b. The group’s recommendation for a pilot project is the development of an architecture to manage the proposals, approvals, and public dissemination of academic courses and degree programs.

i. This is an area where there is already pain and confusion. Many people would like to see this process improved.

ii. This information appears in multiple places on our web site each drawn from different sources. Developing a single source for the data would result in more efficient management of the information.

iii. This data is critical to the University.

iv. Business processes are already in place which would help enforce the use of the CMS architecture for this data.

v. This data is likely to be incorporated into Banner and other datamarts.

vi. CAS has already done some work on this area.

vii. Other schools in the region are interested in sharing this kind of data, opening up the possibility of collaborative development.

viii. Templates for courses and programs could be developed in conjunction with the University’s branding efforts.

3. Recommended strategy for proceeding:

a. Further investigate other schools’ experience using CMS in the management of course and program data through presentations or field trips.

b. Develop a more detailed concept of what the pilot module should include.

c. Develop a plan for implementing the pilot, including a timeline and the resources needed.

The subgroup also handed out a flow chart of the course proposal process so that members could visualize how the system might feed into the development of a course database that could feed various web sites.

Points that arose from the discussion that followed concerning the proposed pilot:

• Be sure that the pilot project would help us build up an infrastructure. We need to be sure we have a foundation. What will we use to do the course piece?
• In the process of the pilot, produce a best practices repository of the learning through the pilot so that we can learn from it for the next stage.
• Consider that we may have to throw it away. Remember it is a prototype.
• Once a course has been approved this is not the faculty’s main concern and so this particular area might not have the impact on the university community that we would like the pilot to have. Since getting access to current syllabi or current course information is really the critical element of most interest to faculty and students, perhaps the option of adding current information and archiving past syllabuses should be built into the flowchart and the web architecture. (We would need to design some mechanism for a repository of syllabi so that the course database could be linked to syllabus. This would give value to the system that all faculty and students would recognize and appreciate.

Turning to points 3 of the subgroup recommendations, the group felt we should spend some additional time looking into other schools’ experiences. Surely some have some of what we are looking for. We returned several times to the buy versus build question and the research that we need to do to figure this out. One member mentioned that the University of Georgia has developed a system for course approval that sounds like what we are proposing. Meihua will ask for guest ID so that we can look at it.

At the end, members of the group suggested other possible areas to pilot instead of the course approval process. Mentioned were directory information, news and highlights, listings of academic programs. Though directory information sounds easier, many more people are involved in collecting this information and there are no clear business processes for handling it, which makes the development of a content management system for it much more complicated (politically speaking).

Finally, the group decided it needed some more information before proceeding with a pilot. We asked for volunteers to come up with recommended strategies for proceeding. They would be asked to research what other universities have done already and to develop a sketch of pilot for two kinds of content management (e.g. course approval process and directory information) and on the basis of what the pilot would necessarily involves, estimate the costs and a timeline. They would bring back recommendations to the WAG in about a month.

Volunteers for this are: Anne (chair), John Crusinger, Andres Fortino, Mel Nichols, and Paras Kaul.

Attending:
Anne Agee
Dee Holisky
Creston Jamison
Deborah Keene
Andres Fortino
John Creuziger
MeiHua Zhai
Paras Kaul
Mel Nichols
Mike Wood
Cathy Hubbs
Roy Rosenzweig
Lara Bushallow
Ruth Kifer
Mike Behrmann
Stanley Zoltek

-top-




Home Members Projects Meeting Notes Information Technology Unit	Tech Council Notes 2/10/04 The only agenda item was a report from the options subgroup and a discussion of their proposal. Anne gave a non-technical overview of what the group accomplished. She handed out a report from two School of Management graduate students, which gave an overview of content management systems. In brief, they looked at 1) content management systems (management content for individual web sites) and 2) enterprise content management systems (allow you to manage content across multiple websites). Enterprise systems cost between half a million and a million dollars, but don’t allow you to share content across web sites, across the enterprise, which is one of the major requirements of our system. If we can’t share content, we aren’t close to what we want GMU’s web architecture to do. This led to the proposal from the subgroup: to implement a mini-enterprise content management system. This system would be organized by type of information and not by unit. This would enable data sharing across the units. This requires us to have a system that allows us to build sequentially, to scale up from one mini-system to another. This means that we are adding to our requirements list. Anne described briefly the Duke University presentation at the Mid-Atlantic Regional Educause conference. (See their pilot report online at http://www.aas.duke.edu/comp/fds/pilotreport.pdf). This is an example of a mini-content management system focusing on topic and not unit. Duke has developed one that focuses on faculty data. The discussion that followed showed a consensus to proceed with this approach, and Anne walked the group through the specific recommendations of the subgroup. 1. The University should move toward implementing an enterprise Content Management System (eCMS) to achieve the desired web functionality. 2. Since this could be an expensive undertaking, the move should be done in stages, developing modules that enable the University to manage one kind of information across the enterprise and gradually adding modules as development resources become available. The group suggests defining a pilot program that would focus on one kind of content that could be managed. a. Selecting an appropriate pilot is important to the ultimate success of the project. The pilot should be something that is currently problematic, so people will have an interest in the solution. The pilot should involve data that is used in multiple places on the web site so people will get a sense of the power of a CMS. The pilot should draw on one or more the projects already underway in order to use resources effectively. The pilot should be in an area where processes and procedures are already in place that the CMS can support. b. The group’s recommendation for a pilot project is the development of an architecture to manage the proposals, approvals, and public dissemination of academic courses and degree programs. i. This is an area where there is already pain and confusion. Many people would like to see this process improved. ii. This information appears in multiple places on our web site each drawn from different sources. Developing a single source for the data would result in more efficient management of the information. iii. This data is critical to the University. iv. Business processes are already in place which would help enforce the use of the CMS architecture for this data. v. This data is likely to be incorporated into Banner and other datamarts. vi. CAS has already done some work on this area. vii. Other schools in the region are interested in sharing this kind of data, opening up the possibility of collaborative development. viii. Templates for courses and programs could be developed in conjunction with the University’s branding efforts. 3. Recommended strategy for proceeding: a. Further investigate other schools’ experience using CMS in the management of course and program data through presentations or field trips. b. Develop a more detailed concept of what the pilot module should include. c. Develop a plan for implementing the pilot, including a timeline and the resources needed. The subgroup also handed out a flow chart of the course proposal process so that members could visualize how the system might feed into the development of a course database that could feed various web sites. Points that arose from the discussion that followed concerning the proposed pilot: • Be sure that the pilot project would help us build up an infrastructure. We need to be sure we have a foundation. What will we use to do the course piece? • In the process of the pilot, produce a best practices repository of the learning through the pilot so that we can learn from it for the next stage. • Consider that we may have to throw it away. Remember it is a prototype. • Once a course has been approved this is not the faculty’s main concern and so this particular area might not have the impact on the university community that we would like the pilot to have. Since getting access to current syllabi or current course information is really the critical element of most interest to faculty and students, perhaps the option of adding current information and archiving past syllabuses should be built into the flowchart and the web architecture. (We would need to design some mechanism for a repository of syllabi so that the course database could be linked to syllabus. This would give value to the system that all faculty and students would recognize and appreciate. Turning to points 3 of the subgroup recommendations, the group felt we should spend some additional time looking into other schools’ experiences. Surely some have some of what we are looking for. We returned several times to the buy versus build question and the research that we need to do to figure this out. One member mentioned that the University of Georgia has developed a system for course approval that sounds like what we are proposing. Meihua will ask for guest ID so that we can look at it. At the end, members of the group suggested other possible areas to pilot instead of the course approval process. Mentioned were directory information, news and highlights, listings of academic programs. Though directory information sounds easier, many more people are involved in collecting this information and there are no clear business processes for handling it, which makes the development of a content management system for it much more complicated (politically speaking). Finally, the group decided it needed some more information before proceeding with a pilot. We asked for volunteers to come up with recommended strategies for proceeding. They would be asked to research what other universities have done already and to develop a sketch of pilot for two kinds of content management (e.g. course approval process and directory information) and on the basis of what the pilot would necessarily involves, estimate the costs and a timeline. They would bring back recommendations to the WAG in about a month. Volunteers for this are: Anne (chair), John Crusinger, Andres Fortino, Mel Nichols, and Paras Kaul. Attending: Anne Agee Dee Holisky Creston Jamison Deborah Keene Andres Fortino John Creuziger MeiHua Zhai Paras Kaul Mel Nichols Mike Wood Cathy Hubbs Roy Rosenzweig Lara Bushallow Ruth Kifer Mike Behrmann Stanley Zoltek -top-
Contact: Anne Agee \| Updated June 7, 2004