Main Nav

Message from


I am an intern in Procurement Services at the University of Connecticut.  Currently, we are attempting to revise our policies regarding vendor service performance criteria. 

Current University policies and procedures require evaluation processes only pertaining to the submittal of solicitation responses.  The vendor is measured on a combination of criteria, most notably, cost and feasibility of their proposal.  Upon the award of the contract, formal evaluations cease and vendor performance goes unmeasured for the duration of the contract.  This makes it extremely difficult to hold vendors accountable for their actions; in addition, UConn does not realize the full potential value of its contractual relationships without checks and balances.

Do any Universities have more concrete policies in place regarding service levels on contracts?  Have these policies worked?  We are looking to define best practices heading forward


David A. DeNuzzio

Graduate Intern

Procurement Services

********** Visit the EDUCAUSE Policy website at


Hi David,

One best practice would be to budget for IT Vendor Management staff resources to manage the contract and relationship with the vendor throughout the contract lifecycle.  The contract resulting from the competitive bidding process should establish the terms of the relationship between the client university and the vendor, but the IT Vendor Management resources are needed by the university to ensure that the vendor continues to meet its obligations as stated in the contract.  Establishing/developing in-house IT Vendor Management staff resources is particularly essential as client institutions increasingly adopt cloud computing services.


Hope this helps!






Thomas Trappler, ASM

Director, UCLA Software Licensing



Phone: 310-825-7516

Twitter: @ThomasTrappler


David Denuzzio asked: #Do any Universities have more concrete policies in place regarding service #levels on contracts? Have these policies worked? We are looking to define #best practices heading forward My concerns with SLAs are several fold: -- As they say, "You can have as many nines as you want to pay for." That is, reliability or performance often comes at a cost. For example, you might need to build greater redundancy into a system, or have more headroom on a shared circuit, or maybe you'll get a more conservative peformance estimate from the vendor. Recognize that the SLA you demand will not be "free." -- If you buy the argument that SLAs are effectively "insurance" grafted on top of a base product, it is reasonable to expect that you'll be paying for two things, the price of the base product, *plus* that "insurance" policy disguised as an SLA. Some people really like insurance, others find that that investment is less useful for them (I think a lot of colleges and universities routinely self-insure), and would rather have a less expensive product. -- Some SLAs require the customer to track and document the failure to achieve target performance standards, and to request a credit when targets aren't met. That can be a pain, and is frankly disingenuous on the part of the provider, at least in cases where an outage affects ALL customers equally. Those sort of global outages should be automatically recognized and credited, whether some customers call and ask for those credits or not. -- Often SLAs provide stipulated payments if certain targets aren't reached, however (a) the targets are often fairly extreme, and (b) the compensation in case of those failures, fairly limited (and non-monetary, e.g., perhaps a free month of service or whatever). That combination of characteristics may limit the practical usefulness of SLAs. For that matter... -- If I'm having a problem with a service, I don't want a free month of service (or whatever), I want a service that works. SLA payments or credits never really seem to offset the pain associated with outages that get you to the point of getting one. SLA payment really only serve as a way of trying to ensure that vendor management is paying attention and is motivated to care about a problem. That said... -- Some SLAs can incent vendor weirdness. Imagine a scenario where a vendor is coming close to a magic threshold where they would incur liability if a little more downtime occurs. What happens? Arguably, the vendor becomes hyper conservative, and the goal then becomes "avoid anything that might push us across the SLA threshold" rather than "let's fix the underlying problem that's been dogging a service, even if it means we might take one more brief hit to get squared away." I think that's bad. Remember, I want a service or product that works, above all else. Anyhow, maybe some things to think about. Regards, Joe Disclaimer: all opinions expressed are purely my own. ********** Visit the EDUCAUSE Policy website at

This article is from 1999 but it is still apropos:

Ruth Ginzberg, CISSP, CTPS
Sr. I.T. Procurement Specialist
University of Wisconsin System

Hi David,


Here are a few resources that may be of help to you.


Vendor Statements of Work: Your Role as an IT Professional


Cloud Services: Policy and Assessment


Policy Development

Please let me know if you have any questions, thank you.

Colleen Keller
Electronic Resources Librarian

  Uncommon Thinking for the Common Good

282 Century Place, Suite 5000, Louisville, CO 80027

Ph: (303) 939-0309 / Email: / Twitter: @EDUCAUSElibrary