SLA poll

[Doug_Den_Hoed__AtAppStore]

Last week I developed a Service Level Agreement (SLA) solution for one of our Workfront clients. I'd done so before, but this time was different. Here are the two styles:

Response Based SLA:

• an Issue of a certain Priority, on a certain day and time of the week is raised
• calculations based on Priority and Business Days compute the SLA deadlines for responding and resolving
• timers immediately start. recording the elapsed time to respond, and/or the time to resolve
• timers pause (and "don't count" against the SLA response or resolve resolution time) when the Issue is put On Hold (e.g. for feedback)
• the Issue Status flips back and forth between In Progress and On Hold until eventually it is marked Complete
• at time of Completion, if the elapsed timer is less than the SLA deadline, it is "within SLA" (no penalty); otherwise "outside SLA" (penalty)

Commit Date SLA:

• a request is raised
• no timers kick in automatically, as such
• instead, such requests are batched, reviewed, prioritized, approved to be worked upon, and released for negotiation
• negotiation then occurs, wherein the scope is finalized, effort established, and a mutually agreed upon Commit Date is set
• such items are then monitored relative to their Commit Date
• if they are marked as closed before the Commit Date, they are "within SLA" (no penalty)
• if they are still open as of the Commit Date, they are "outside SLA" (penalty, plus new Commit Date renegotiated)
• if they are on hold as of the Commit Date, they are "within SLA" (no penalty, plus new Commit Date renegotiated

Both are valid, and (as it turns out) both lead to similar Workfront Dashboards showing % in/out of SLA by Month, etc., but not being as familiar with the latter, made me curious.

Which of these two (or other) SLA styles fits best with your use of Workfront, and how successful were your modeling efforts?

Regards,

Doug

[DenverLe]

Hey Doug,

Our teams are in the process of developing and rolling out SLAs. We are taking more of a "Commit Date" approach.

In our SLAs there will be two key sections 1) project tiering and 2) project timelines.

Tiering: We will categorize all of our project by tiers which are defined by the project's level of effort, scope, complexity, etc. Tier 1 projects are demanding and more complex while tier 3 projects are more simple and generally quicker to complete.

Timelines: In the SLAs we provide time ranges for how long certain projects typically last. For example tier 2 email campaigns with these deliverable typically take x-y days or creating a tier 3 new social graphic will take x-y days.

Our process for executing work will be:

1. Request is submitted by a client

2. Traffic coordinator will review and scope the request.

3. Typically a kickoff meeting is held

4. The commit date is determined (this may be more or less than the SLA date)

5. Request is converted to a project and project team starts execution (when the request is turned into a project, the SLA 'timer' starts)

We will look at project overall durations compared to the documented SLA timelines. These will help shape and refine our SLA timelines.

We haven't rolled this out yet, so no successes or failures. I'm curious if you have had any issues or successes with your SLAs?

Thanks,

Denver

[Doug_Den_Hoed__AtAppStore]

Hi Denver,

Thanks for the backstory on your Commit Date SLA intentions; very similar to what we've worked out.

We've built out our solution out (including some snazzy dashboards), completed initial testing, workflow walk throughs, and our main users are conducting testing over the next 2-3 weeks. So far:

• THE GOOD: we've confirmed the general flow, the views of interest, calculations to confirm the various possible SLA States, and (in general) have agreed and committed to the overall workflow and visualizations
• THE BAD: there is a (relatively significant) portion of the business that needs to be held accountable to the Commit Date SLA concept, but the nature of their work (quick turnaround, high pressure) does NOT lend itself (think "mutiny") to pausing that flow to negotiate and set a Commit Date; so I've proposed (gasp) that where a Commit Date has NOT been set, the sensible convention will be to then use the Planned Completion Date AS IF it was the Commit Date. Stay tuned on how that that all goes down.
• THE UGLY: the Achilles heel in this approach is the whole what-if-we-miss-and-have-to-move-the-Commit-Date scenario. Although we've added some fit for purpose auditing to track how many times the Commit Date is moved (e.g. "nine...times?") and to what Date it was moved each time, there is still an implicit flaw in the logic whereby you and I might agree that I'll Commit to finish an item for you by Thursday, and I then finish out of SLA on Friday, I could inadvertently or maliciously then "reset" the Commit Date to Friday, thereby tricking the the stats to show that I finished within SLA. You, seeing the Green Light might then overlook that trickery, which kinda defeats the whole purpose. If and when you dig into it, and later confirm it was malicious, certainly could send me to detention (or worse), but -- seeking a better solution -- I'm still mulling over a way to close the loophole.

Regards,

Doug

[DenverLe]

Thanks Doug for this insight! This is good to know as we continue pushing forward on SLAs. I'm curious about your dashboards. Do you have different dashboards per role (manager, team member, client/stakeholder)? What reports are on those dashboards? Thanks, Denver Denver Lemont Cardinal Health

[Doug_Den_Hoed__AtAppStore]

Hi Denver,

The SLA dashboards are similar to this example, and this other one.

Regards,

Doug