Managing Expectations

[sippo]

How do you do it for staff?

 

We are trying to implement an SLA, does anyone have one they wouldn't mind sharing.

 

Is P1-P3 enough. P1 being passwords etc. P2 being a broken projector, P3 being new hardware/software?

[simpsonj]

I can send you mine if you want, I think I 'borrowed it' from elsewhere, so it's fairly comprehensive and also, completely ignored by staff despite being in the Staff Handbook given to all staff.

[simpsonj]

Generic SLA attached

 

ICT SLA 2020-Generic.docx

[paulkerton]

Whatever you do, you should set an "external" target to be larger than your internal target.

Saying "5 minutes for a password reset" is all well and good internally, but set the expectations a little wider for staff and students. Otherwise, it's a rod up your back when you've had to go all hands for an emergency, but this password still needs resetting...

[simpsonj]

Whatever you do, you should set an "external" target to be larger than your internal target.

Saying "5 minutes for a password reset" is all well and good internally, but set the expectations a little wider for staff and students. Otherwise, it's a rod up your back when you've had to go all hands for an emergency, but this password still needs resetting...

 

Why I have the word 'Normally' within 5 minutes of being reported. Normally does a lot of heavy lifting in that sentence!

[DrBeaker]

Managing Expectations.

 

Stuff that's broken and needs fixing - first come first served also tied in with WHO and WHAT and HOW it affects. E.g. A kids password is more important to me despite admin saying they're more important needing that new toner ASAP as "they can't print" (Read they can print to other printers, but don't want to)

 

Stuff that you want but don't need - takes longer.

 

Some stuff we have to go away and figure out out.

[jmak]

I'd look carefully at what you use as classifications. Personally I prefer service impact as criteria to classify rather than specific tasks.

 

P1: Issue impacting health and safety of staff or pupils

P2: Issue affecting multiple systems and departments

P3: Issue impacting a whole system or department

P4: Issue affecting teaching and learning

P5: Issue affecting integrity or performance of systems with little immediate service impact

 

All issues reported through the recognised channels will be assessed and prioritised within X time of receipt*

 

 

*Half an hour is more realistic than 5 minutes unless you have someone who's job is to monitor the helpdesk)

 

Obviously if you're doing something that can easily be paused, resetting a password in under a minute will make your average resolution times look great, but if the same lame a$$ requests their 5th reset of the day you don't want to give them a stick to beat you with when you're trying to do something more important than fix their incompetence. I'd also look at implementing an SSO platform based on either Azure AD or Google Auth with self service password reset. Note to the wise: of you do that, make sure you don't get battered with KPIs that penalise you because your now taking longer to fix a smaller number of issues. What you've done is got rid of pointless issues and the ones that are left are more complicated and you should be rewarded for that.

[nicholab]

I would work in block of hours as a minimum and also a possible second sla for out of term time.

[DrBeaker]

Is your SLA working to the assumption you've had adequate and prior notice of things like moves, new starters etc though in order to plan resources, logistics etc? Otherwise I can't see how it will be achieved (generally speaking) as we know what planning in schools is like.

[TechMonkey]

Is your SLA working to the assumption you've had adequate and prior notice of things like moves, new starters etc though in order to plan resources, logistics etc? Otherwise I can't see how it will be achieved (generally speaking) as we know what planning in schools is like.

 

This should be where your SLA also sets out notification times. If the request does not meet the notification time then the SLA does not apply and it is best effort.

[FN-GM]

You should split everything into 2 categories.

 

Incidents - something is broken.

Requests - request for a product or service.

 

Eg:

 

Computer fails to boot - incident.

Web filter not blocking sites it should - incident.

Request to install software - request.

Reset a password - request.

 

Incidents usually get priority over requests.

[DrBeaker]

You should split everything into 2 categories.

 

Incidents - something is broken.

Requests - request for a product or service.

 

Eg:

 

Computer fails to boot - incident.

Web filter not blocking sites it should - incident.

Request to install software - request.

Reset a password - request.

 

Incidents usually get priority over requests.

 

The interesting debate with ITIL on this topic years ago anyway was is a password reset an incident OR a service request?

[FN-GM]

The interesting debate with ITIL on this topic years ago anyway was is a password reset an incident OR a service request?

 

The way is see it is nothing is broken. The system is working as designed. The user is requesting the password reset because they forgot it. So it’s a request.

[jmak]

The way is see it is nothing is broken. The system is working as designed. The user is requesting the password reset because they forgot it. So it’s a request.

^^This

[mrstrong]

slightly off topic but made me think "Eisenhower's Urgent/Important Principle"

e.g. see

https://www.imperial.ac.uk/media/imperial-college/administration-and-support-services/staff-development/public/impex/Prioritisation-and-Time-Managment.pdf

[jmak]

slightly off topic but made me think "Eisenhower's Urgent/Important Principle"

e.g. see

https://www.imperial.ac.uk/media/imperial-college/administration-and-support-services/staff-development/public/impex/Prioritisation-and-Time-Managment.pdf

That sums up all of management theory in three A4 sheets [emoji2]

 

As well as being a very effective way to plan your day...

[mbedford]

Critical - Fix or workaround within 60 mins - This is reserved solely for issues that prevent teaching and learning

1 - 4hrs - Urgent but not critical

2 - 8hrs - Need to be working tomorrow

3 - 16hrs - This is our default, expected turnaround time on the majority of calls

4 - 24hrs - We rarely use this one

Project - At least 3 months, more of a placeholder than an expected completion time, a completion time has probably been agreed in the project scope.

 

All of these are measured directly in our ticketing system (OSTicket) and are business hours (measured between 0830-1700hrs, so a 4hrs timer starting at 1600hrs, would run until 1130hrs the following working day), we don't change the due date, if we miss the target, that's not always a bad thing. Perhaps we need more resources to ensure it doesnt happen in the future. The critical calls are honestly looking at a 99%+ compliance rate, teaching and learning is our bread and butter, so we put a huge effort into that.

Edited September 29, 2021 by mbedford

[DrBeaker]

Critical - Fix or workaround within 60 mins - This is reserved solely for issues that prevent teaching and learning

1 - 4hrs - Urgent but not critical

2 - 8hrs - Need to be working tomorrow

3 - 16hrs - This is our default, expected turnaround time on the majority of calls

4 - 24hrs - We rarely use this one

Project - At least 3 months, more of a placeholder than an expected completion time, a completion time has probably been agreed in the project scope.

 

All of these are measured directly in our ticketing system (OSTicket) and are business hours (measured between 0830-1700hrs, so a 4hrs timer starting at 1600hrs, would run until 1130hrs the following working day), we don't change the due date, if we miss the target, that's not always a bad thing. Perhaps we need more resources to ensure it doesnt happen in the future. The critical calls are honestly looking at a 99%+ compliance rate, teaching and learning is our bread and butter, so we put a huge effort into that.

 

But how can you guarantee that fix or workaround within 60 mins? e.g. we had a major leak from the roof that knocked out lots of IT kit, no way that would have been fixed in a day, let alone the time it took them to actually fix it.

[mbedford]

But how can you guarantee that fix or workaround within 60 mins? e.g. we had a major leak from the roof that knocked out lots of IT kit, no way that would have been fixed in a day, let alone the time it took them to actually fix it.

 

Get the class moved to a room with at least one PC, so the teacher can take registers and teach students. Having IT for the kids is preferred, but teaching can still take place without it. In that kind of situation, its about managing the problem, not returning 100% service.

 

Or if there are no rooms available, get the room affected to be safe (facilities and environment wise) and get a laptop and projector screen bought in. This is going to require involvement from other departments (caretakers for power etc...) but from the IT point of view, we have provided a solution as quickly as possible, need the other teams to respond in a similar fashion.

[paulkerton]

...but from the IT point of view, we have provided a solution as quickly as possible, need the other teams to respond in a similar fashion.

“The best laid schemes o’ mice an’ men. Gang aft a-gley” :laugh:

[Zammo]

The interesting debate with ITIL on this topic years ago anyway was is a password reset an incident OR a service request?

 

Its neither. A password reset is the fix, not the issue

 

Thats like asking "is a new PC a service request an incident or a request?". Depends why you are replacing it.. did the old PC blow up (incident) or is this an item for a new starter (service request)

 

 

The password reset could be due to an incident (account compromised, erm... corrupt password database?) but more likely a service request (I need a new password because I forgot mine)