| University of San Francisco
We had a 3-month implementation. I was expecting a year to 18 months from
other vendors, so I thought the 3-month implementation from ServiceNow
The University of San Francisco case study is based on an interview with Tracy Schroeder, University of San Francisco VP of IT
USF is a private Jesuit institution – one of 28 in the United States. USF was founded in 1855.
We are approaching 9,000 students, and a grand total of 1,500-2,000 employees depending
upon the time of year and the count on adjunct, full-time, part-time, etc. We have a large
number of alumni, but if you count the alumni active in our portal using our IT services only,
we count our active user base at about 20,000.
Past challenges prior to using ServiceNow
The first service desk was implemented at USF back in the 2000 timeframe, and it was before
the IT group really knew anything about ITIL or ITSM. We used Remedy in a very componentbased
way and not with the perspective of what service anything was a part of. So you'd have
category type and item schemes for categorizing incidents that would end up being, say,
hardware or other. And it was very difficult to map metrics for the various incidents that would
occur to say, "How many incidents did we have this month related to e-mail?" and "What was
our resolution time around all of our collaboration and communication services?"
Ultimately, we were able to do it, but it was an expensive, manual mapping process for us to
make that happen given the structure we'd established in Remedy. No fault of Remedy, of
course, but just the fact that it pre-dated our understanding of a service-based approach to
incident and problem management. That was something that we really wanted to re-do, and a
question was whether we should re-do it in Remedy or in a new tool.
Some of the other issues we had were our workflows and client self-service – everything
required custom development in Remedy. In my experience with it, you had to hire
consultants, you had to have custom development. Their recommendation for rolling out selfservice
was basically that the client would see the same thing that the IT service tech would
see, and it was way too much information and many more tools than people needed, and we
knew that to point self-service in that direction was going to generate yet more support calls.
So we hired consultants, we created customized forms, etc., and that took a lot of time and
effort and we were concerned about having to replicate that in a new environment.
We also had no service level agreement tools. We couldn't build in schedules, alerts or
escalations based on priority. I couldn't get an alert if there was a Priority1 incident, except
with custom programming, for which we had no budget. If I wanted to know what was going
on, I had to log on to Remedy and search and explore, and as a CIO I just don't have time to
do that, so I really wanted alerts from a new tool.
We implemented a tool for change management process, but
we had to handle it by e-mail and ended up tracking it in a
spreadsheet because developing the workflows to do that in
Remedy was just going to be yet another costly services
engagement for which we didn't have the resources.
Finally, our system was at end of life. We knew we had to
upgrade, and that it was going to be costly. They made it clear
that it was going to be a re-implementation and we would be
starting over. At the same time, we were in the middle of an
ERP implementation, so all of our programming and
administration resources were fully spoken for.
I couldn't pull programmers or system administrators off of a
banner implementation to spend time on a back-office tool for
the IT department to be more productive. I didn't even try to
make that sell to my client community. We didn't have the
resources to put toward an extensive implementation from the
infrastructure and programming perspectives.
Requirements for a modern IT service
How did we deal with all of those issues? We continued to use
Remedy and developed workarounds. We did things the oldfashioned
way for several years, and to some extent that was
good for us for a few years because it forced us to focus on
process, and to learn how we needed our RFC and incident
processes to work, how we wanted to prioritize our incidents,
and which metrics we wanted out of the system.
We started building our requirements for what we really wanted,
and that we wanted a tool that was going to take an ITIL
approach from the beginning and be structured based on
services, comprised of elements from the CMDB. We wanted
something we could deploy easily, that would not suck up all our
programming and admin resources to support.
We were most focused on incident, problem and change,
because we were most mature in these and we knew what we
wanted. We had aspirations to do more in other areas, but those
were our top three priorities.
We needed to be able to integrate with our campus portals for
single sign-on and with our asset management tool, LANDesk,
and our knowledge base, RightAnswers.
We wanted to be able to customize very simply – adding fields,
renaming labels. We wanted to be able to leave a note that if
somebody entered data in a given field, it would go to the client.
We wanted to be able to do all of this without hiring consultants
and without need for a programmer, at least in most cases.
We wanted our clients to have good, clean self-service that we
weren't going to have to build and I wanted to be able to get
data out, to be able to show easily what was happening with our
services without a lot of manual labor from my assistant for
We explored our upgrade options with Remedy and saw it was
going to be a re-implementation - as costly as purchasing a new
system. So we put out an RFP and got responses from CA, HP,
Remedy and ServiceNow, but in 2007 we didn't have the
funds to proceed so we sat tight for a year.
In Spring 2008 we decided we really had to do it. We had a call
with a Gartner analyst about what our goals and constraints
were, who was new in the marketplace, and they really
recommended that we take another look at ServiceNow and a few of the other newer vendors in the space, and we
really liked what we saw in ServiceNow. We had more
success in talking about the business arrangement with them,
and our help desk and technical staff really liked what they saw
in ServiceNow as a next-generation application that they
would actually enjoy using.
That helped build internal buy-in for the project. Also, our system
administrators saw that they weren't going to have to build this
out; they were just going to be able to use it.
Results: three month implementation
We had a three month implementation. I was expecting a year to
18 months from other vendors, so I thought the three month
implementation from ServiceNow was extraordinary.
I get notifications for all of our Priority1 incidents or any level I
want. We get notifications when we're escalating. We've set in
what our business rules are for when incidents escalate. It has
eliminated a lot of manual work for the help desk manager to
watch the aging of tickets and see who is moving things through
their queue; instead, it's just coming to her, and she knows what
she needs to follow up on.
Our request for change (RFC) process happens entirely in
ServiceNow, without issue. We integrated LANDesk and
RightAnswers. As an unexpected bonus, we've been able to
adopt [ServiceNow Project Management] to track our
pending projects and our project queue and track major work
We have streamlined our metrics process, we can get them
straight out based on how we've built our service categorization
We've also implemented client satisfaction surveys and selfservice
ticket submission. We had done these in Remedy, but
they were custom development and they were old and had
browser incompatibilities, which hindered adoption. We've been
pleased by how much of a difference the ServiceNow experience has had on clients' willingness to fill out surveys and
to submit their self-service tickets.
Between March 2008 and March 2009, the number of clients
that took the time to respond to our satisfaction survey upon
resolution of their incident or service request, more than
doubled, and the responses have gotten much more positive
about service happening in a timely manner, knowledgeable
staff, good customer service and issues resolved to satisfaction.
Some of the credit goes to my staff, but at the same time, the
tool has certainly helped.
The most common comment I used to get from my executive
colleagues was "Your staff is really great, but all the system
sends me is a note with a big numeric string with my ticket
number. I can't tell what it is or what it was about." It's good to
have something as simple as having a customized resolution
notice with the logical name of the incident or service request
and who worked on it. One client told me how much he
appreciated that he could go into ServiceNow self-service
and see the entire work history, and he'd know how we were
doing on it and when he could expect it back. Having those
simple pieces of the system that touch the client be less of a
kludge improves people's perceptions of IT.
I have a variety of metrics related to our services on the USF
ITSF Website www.usfca.edu/its. For example, in March 2009
we resolved about 900 incident tickets and about 600 service
request tickets. Our average resolution time has gone up in the
last few months, but that's been a conscious choice on our part.
We got survey feedback that we were very good at responding,
but that we didn't always solve the problem. We've been
focused on that and it has increased some of our resolution
We integrated ServiceNow with a single sign-on from our
Luminous portal from Sungard. That does use the Sun1 LDAP.
And we populated the person or client information with a feed
from Banner. The ServiceNow single sign-on uses a
somewhat old protocol that the version of Luminous requires,
but I think there wouldn't be an issue with single sign-on or
LDAP compliance on the part of ServiceNow.
I was convinced. The university didn't have the resources to
host the application locally. The application doesn't contain any
sensitive data or academic records or anything of a confidential
nature. It didn't fall into a category of being protected by our
information security policy. My institution frankly doesn't care
how I source something; they want me to source it in the most
cost-effective way, and from my perspective, sourcing it through
ServiceNow was going to provide probably higher
availability and security that we'd be able to provide locally.
What's up next for University of San Francisco?
Next, we're going to work on service catalog, and on building
out our CMDB. We have data in it now, but we need to bring in
additional components and build out our business service maps.
We're also hoping to use our Project Management application