Service Delivery

Attending:

Neptali Martinez – ITS

Justin Bromberg – ITS CFS

Chris Penido – ITS Security

Devin Nix ITS G.Apps  –

Monica McSharry – Project management ITS

Hani Basillous – NYU Poly

Bobby Brill – ITS

Cynthia Guy – Bobst Library

John Stucki – NYU Stern

Harvey Brereton: NYUAD

Natalie Hidalgo – GTS

Topics For Discussion

  • Defining the scope of service delivery
  1. John: Alignment with the university while maintaining the identity and uniqueness of each service provider/school
  2. Cynthia: Improving the communications between the parts of the organization
  3. Bobby: Delivering the services the client works, getting feedback on how we are delivering the service and monitoring the value we create for the clients
  4. Hani: Adopting standards
  5. Monica: Project management plugs in to service delivery. We say at times a project is done without understanding the impacts from a project upon the delivery of services. Defining scopes.
  6. Devin: Two parts: the framework (eg ITIL). 2nd- the standardization across the organization, meeting the needs of varying levels of rigor required by departments across the university
  7. Christopher: Be the facilitator/communicator between ex: the project manager, the user, the stakeholder in a sensible way. Able to manage expectations and deliver what we promise within a framework that is best suited to our needs.
  8. Natilie:
  9. Justin: Providing value to our clients

Neptali: we should turn the idea of service delivery around. We are often focused on the service provider, being service providers. We should focus on the expectations of our clients. Patterns of need. Their basic definitions of what is useful to them.

Responses:

Devin: It is often unclear what the client wants, often times they themselves do not know what they want.
Natalie: We’re starting to be at a place that we are starting to improve. At the very least with Service Link we are able to route the issues to the right group. We are able to at least get help to the people who need it seamlessly.

Christopher: Before we usually do a soft launch and gradually ramp up without management of expectations. We generally don’t use SLAs to manage expectations. We should be using them to guide expectations between the SP and the client. It would improve transparency and it reminds you what the level of service should be.

Hani: How many people actually read SLAs? Often times SLAs are defensive and hard to read (ex: legalistic)

Christopher: We should make simplified SLAs with basic, easy explanations. More complex service issues can be attached for reference. For easy understanding though it would enhance the likelihood of people understanding.

John: We use SLAs to students at varying level of support that specifies the tiers of service. In general it is simplified and can be “best effort”. We give choices though:you can get one type of standardized laptop and get a certain guaranteed level of service, or you can get something else of your own you get a best effort tier.

Christopher: This sounds more of a communication issue. If people arent reading it we should communicate better. SLAs are used by some as a shield but we can use them to temper expectations and if we communicate it better they will be useful.

Neptali: SLAs are a good approach as an agreement and there is room for improvement and experimentation with communications and terms. AD uses 20+ SLAs for varying services to good effect.

Christopher: What about OLAs? OLAs in support of SLAs are essential to underpin the SLA. They are complex and require agreements between the different groups and are probably a conversation all on their own.

Devin: When something is not technically a service but it has become commonplace, what then? Eg: Youtube. We can get to it and its expected it works. Google apps that are unsupported but accessible. What do we do in support of these? Especially in terms of VIPs, what service level should be expected?

John: We should put down what we realistically can do. AT some point we need to put together some research on who is on the other end of these services. We can’t do everything but we can’t tell the clients we don’t do it. If we know who is on the other end of those services we can direct people to them.

Hani: I don’t know if I would do that. Poly is much smaller. The feeling is why are we here if not to solve the problems. To tell the users go elsewhere for support.

Christopher: Boundaries should be set. We have been wanting to help everyone with everything without limits. This results in poorer service. We should use these request and feedback to generate our strategy for delivering support.

Devin: When you return “we aren’t going to support it” though it creates problems. We need a way to get feedback, to act on it and deliver it. We need to be able to have the end user not question our due diligence when we return an answer they don’t think is favorable. We need a process to be able to say “yes we will do it” or “no, not right now.”

Neptali: Right now there are many applications and good ideas that get lost in others priorities, with a feedback process it would be easier to sort out.

John: We need standards and a value set throughout the university. IT is at the forefront but many university components that tie into IT that IT depends on need to be brought into conformity as well.

Neptali: Does the university value access to the Youtube example? What are the business wants?

Christopher: Lets say we have a mechanism. We can say to the user “we have a process to evaluate business cases, weve studied it and here is the business case and we have made such and such decision.”

Natalie: SD is constant improvement. We get stuck in one of two methods. Reactive and maintenance or enhancing and changing. It is easy to live in reactive maintenance to the detriment of chances for improvement. We should keep in mind to have some balance.

What about NYUAD?
Harvey: SLAs are a two way thing. There often is a negative interpretation of them but they are useful for both sides. It establishes the expectations and requirements of both side. It is a win-win. They don’t have to be a defensive. It should be written by the SP with what they can provide and agreed upon by the client to meet their needs. It should be negotiated openly.

Hani: But often it doesn’t work that way.

Christopher: We may not do it in practice but there is an opportunity to work on our communications in our SLAs. It is useful to use the SLA to meet service delivery expectations.

John: Its a process. Moreso now that 5 years ago level of service is important to the client. Even once you get the SLA that is now only the beginning of the service delivery component. The SLA delivers a sense of comfort in that the expectations are known.

Bobby: We are recording trends for requests and incidents. We are making insights now in this direction.

ITIL:
Do people want more training?

Yes.

NYUAD has regular training once yearly.