1. University of Washington
IT Resource Sharing Group
Needs Assessment Report
November 2005
Final Version Page 1

2. Table of Contents
Table of Contents........................................................................................................2
Executive Summary.....................................................................................................2
Project Background.....................................................................................................2
Project Approach.........................................................................................................3
findings ......................................................................................................................3
conclusions..................................................................................................................4
recommendations and Next Steps................................................................................6
E X E C U T I V E S U M M A RY
This report presents the findings of the IT Resource Sharing Group’s needs assessment
project regarding operational and reporting needs for student data at the School and
College level. Through interviews, surveys, feedback sessions, and data collection,
several observations surfaced:
• While many Schools share information needs that are unmet by central student
data systems, many individual units have unique needs that are not shared with
anyone else
• There is a lack of awareness about functionality currently available in central
systems, or under central development
• The frustration and inability to have needs met centrally have resulted in a
sizeable collection of “shadow systems” that are expensive, duplicative, insecure,
and jeopardize the integrity of data
• There are no apparent, consistent, definitive patterns as to when Schools use
central systems, develop their own system, or do processes manually for the same
function
In many ways, the most valuable aspect of the data collected is that it verifies the
intuitive sense among Deans that a better approach is needed. While the time allotted
didn’t bring us to the point of defining a specific application that would neatly solve all
the challenges at hand, we were able to unpack this complex set of issues enough to make
specific recommendations for next steps. In brief, they call for:
• Acknowledging the reality of decentralized application development
• Creating processes to support that reality in a secure and productive manner
• Re-exploring the long term strategy for student information systems at UW
P RO J E C T BA C KG RO U N D
In June 2004, the IT Resource Sharing Group received money from the Fund for
Innovation to “conduct a needs assessment and systems audit and then to outline an
implementation plan for the development of a School-based student information system.”
Final Version Page 2

3. An Advisory Group was formed to work with the Director of the USER Project, Patricia
Woehrlin, to interview candidates for the project manager role. The project manager was
hired and started on October 18, 2004.
Phase 1 of the project, the needs assessment, was undertaken as the top priority in this
funding cycle. The next step of developing a School-based student information system
was delayed when a proposal for phase 2 of the project received a low ranking during the
Information Technology Advisory Committee (I-TAC) process.
P RO J E C T A P P ROA C H
The project began in October 2004 when the project manager was hired. The USER
Project approach was followed. A process improvement team was established after the
project manager met with individuals from the Schools and Colleges who work with
student data regularly. The team members were identified in November 2004 and
included representatives from Student Affairs, Computing & Communications, the
Schools and Colleges who are members of the IT Resource Sharing Group, and a
representative from the College of Arts and Sciences. (See Appendix 1.) The project
startup meeting was held on December 7, 2004.
The team began meeting weekly in December 2004 and discussed different approaches to
gathering data that would help identify the common needs among the Schools and
Colleges. A variety of data collection methods were conducted over a six-month period
from December 2004 to May 2005. Over 100 members of the University of Washington
community participated in the project:
• The project manager interviewed approximately 50 people from Computing &
Communications, the Schools and Colleges, and Student Affairs.
• The team designed and distributed a student data survey broken down into 16
high-level business processes covering an academic year to document the “cradle
to grave” business processes for student data. The goal was to determine how
similarly the Schools and Colleges work with student data throughout an
academic ‘cycle.’
• Functional users participated in feedback sessions.
• Operational and reporting needs were collected at the School and College level.
• Inventories were compiled of both central applications and applications developed
within Schools.
FINDINGS
The process improvement team spent six months gathering and analyzing data. These
efforts revealed five major findings:
Final Version Page 3

4. •
The team discovered that whereas there are many common needs throughout the
Schools and Colleges, individual units have unique needs as well. All of the
Schools and Colleges recruit prospective applicants, manage inquiries, process
applications, register students, maintain student records, monitor academic
progress, grant degrees, and track alumni. However, the School of Public Health
and Community Medicine, for example, captures work experience for applicants,
the Law School assigns students an anonymous grading number, and the School
of Nursing tracks preceptor assignments.
•
Interviews further revealed that a number of identified needs are unmet by
central student data systems. For example, the Student Database (SDB) is
extremely limited in its reporting capabilities and its ability to access dynamic
student data for a cohort of students. The unique needs of Schools and Colleges
have not been explicitly represented when priorities have been set for central
system maintenance. The central student services offices (which set the priorities)
have focused the limited C&C resources on the most critical projects with broad
applicability such as student registration and tuition collection.
•
The team also determined that there are now approximately 30 central student
applications in production or development, and 37 systems have been
developed within the Schools and Colleges surveyed. (See Appendix 3.)
Though these “shadow” or local systems meet some of the needs that Schools and
Colleges identified, there are inefficiencies and security risks associated with such
an unmanaged, decentralized array of systems; they often do not meet the needs
of other campus users and so can’t be shared outside the unit in which they were
created; and many are duplicative of other systems.
•
The team learned that there are central systems and services in place of which
people are unaware. This indicates that there is a communication gap with
regards to the availability and capabilities of some central systems.
•
Finally, with only a few exceptions, we discovered that there are no consistent,
clearly definable patterns as to when Schools/Colleges use central systems,
when Schools/Colleges have developed local systems, and when
Schools/Colleges do processes manually. In order to understand this anomaly,
we need to conduct a much more in-depth conversation about why Schools are
approaching these tasks differently.
CONCLUSIONS
The needs assessment determined that:
• There is a high level of frustration from almost every constituency regarding
access to, and analysis of, student information.
• The inability to meet all of the growing demand for student information centrally
has had a demonstrable repercussion in the proliferation of so-called “shadow
systems” that often replicate data and processes in the central systems.
Final Version Page 4

5. •
•
These shadow systems tend to be expensive to maintain because they involve so
much duplication of equipment, training, software, and effort.
Shadow systems developed without employing “best practices” can jeopardize
both the security and integrity of important data.
Final Version Page 5

6. R E C O M M E N DA T I O N S A N D N E X T S T E P S
Recommendation #1: Acknowledge the de facto reality that some UW student
information is captured through central systems and applications while other UW student
information is captured through locally built systems and applications within Schools and
Colleges, and that both stores of student information are critical to the overall mission of
the University.
• Next Step: The University should actively address these questions:
o What are the principles on which UW bases decisions about what data and
functionality should be in central applications versus in decentralized
applications?
o How do the Schools and Colleges gain a better ongoing presence in the
planning activities for improvements to the central systems?
• Who: Mike Eisenberg will take responsibility for this Recommendation.
Recommendation #2: Design an environment that supports this distributed development
model in healthy, productive ways.
• Next Step: Build a comprehensive set of information exchange points between
central resources and the staff designing, building, and utilizing decentralized
student information systems and applications:
o Work with the UW Chief Information Security Officer to develop
resources, processes, and standards that ensure that decentralized
application development in Schools and Colleges is done in a secure
manner.
o Work with the UW Registrar and other stewards of University student
information to identify and/or obtain tools that make extracting data from
central applications (often needed to feed decentralized applications) as
robust and friendly as possible.
o Work with C&C and various project managers to strengthen and
consolidate ongoing information channels about such existing resources
as:
• The functionality available in central applications
• USER projects
• The Data Warehouse project
• MyGradProgram, which received an Innovation Fund award to
address some of the requirements specified by the process
improvement team
• The Departmental Shared Application Development Environment
(DESADE) project, a potential fee-based C&C service, possibly
layered atop Nebula, which would provide a standard toolset and
database environment for analysts/developer, and other projects
o Clarify how Schools and Colleges can submit requests for changes in
central applications.
Final Version Page 6

7. •
Who: John Drew and Jim Loter will take responsibility for this
Recommendation, and may consider using the remaining budget in this project for
these purposes.
Recommendation #3: Despite the suggestions/recommendations above for improving
“what is,” it is timely and important to re-examine the long-term future of the current
central student information system.
• Next Step: Engage the right people to address a long-term strategy and ask:
o Should we continue to extend our current system and build better
interfaces to the data in that system?
o Or would the University would be better served by replacing it?
• Who: Mike Eisenberg will take responsibility for this Recommendation.
If the University of Washington is to sustain its overall excellence, remain competitive
with peer institutions, and uphold its reputation for service and cost-effectiveness, it must
provide the tools necessary for student services staff to better gather, analyze, and report
on student data. The recommendations in this report are important steps to improving the
current frustrating and inefficient state.
Final Version Page 7