SLA poll

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

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

Hi Denver,

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

Regards,

Doug