BA in the Wild – *New Series*
My husband and I went out for breakfast on this Labor Day morning, and I found ample opportunity to practice some business analysis. And it’s something that we often miss in the course of our practice – defining Service Level Agreements, or SLAs for short. Before I get to that, let me tell you a bit about how our breakfast outing went.
We went to a popular “hot spot” local breakfast place and were initially pleased to be seated right away. As we perused the menu, a manager approached and took our drink order and told us our server, “Faith” would be with us shortly. The manager had our coffee and water out promptly, but we continued to look over the menu, waiting for Faith. We waited and waited, until we got to the point in the process where we said, out loud, “gee, I wonder if we have a server?” Or, as I like to lament in times such as these, “man, I wish I could choose when this invisibility superpower takes over.”
Anyway, selections long since selected, Faith did arrive and meekly asked, “are we ready?” Yes, as a matter of fact, we were, and we placed our order, which she entered into one of those fancy hand-held tablet devices that are becoming popular at the coolest eateries. And that was the last we saw of Faith for a long time. Our order was delivered in a little-bit-longer-than-expected time frame by a runner. Nobody came by to ask if we wanted more coffee. Nobody came to check to see if our orders were correct. Which they weren’t.
Now, the restaurant was somewhat busy, but not overwhelmingly. Looking around, it seemed like each server had about 5, maybe 6 tables. There were a couple of large parties on the patio. The hostess was doing all jobs except for serving, and very efficiently. The other servers seemed to be moving quickly, but not frantically, and had smiles on their faces. Faith, not so much.
Not having much faith that Faith would actually stop back by to actually correct the errors in our meals, and given that the mistakes were reasonably small, we just accepted them and dug in. Tasty eggs! Overall great quality food. Still no check-in on how it is from Faith. When we finished eating, a runner came and picked up our mostly-empty plates, but another 10 minutes or more passed before we had that next conversation of, “well, just a few more minutes and then we try to figure out how much it is and just leave cash on the table.” Nothing. We could see Faith around her other tables, getting coffee and what-not, but she did not check on us. Finally we asked the hostess if she could let our server know we were ready for the check. Another 10 minutes passed, and she finally went to the printer and got our check. She made the remark, “can I grab you anything else?” Yeah, no…we gotta go.
I accept slower-than-pre-pandemic service at this point in time. I also realize that wait staff at restaurants is a very difficult job that I could certainly never do well for many reasons, so I do give some lattitude. I also consider myself a good, if not generous, tipper. But when you only see your server, the one who traditionally receives the tip, just when they take your order, and then you have to ask for her to return with your check, what do you base your tip on? And, how do you go about determining what a “reasonable” amount of time to wait is, or how many times contact with a server or staff member needs to occur?
Here’s where the SLAs come in. Yes, I know it’s silly to think that as a customer, a restaurant actually has an enforceable service level agreement with me, but it’s fun to think about. Well, OK, it’s fun for me and other like-minded business analysis geeks to think about. OK, well, maybe it’s just me…
What exactly is an SLA? According to Indeed.com’s Guide to Service Level Agreements, “a service level agreement, or SLA, is an understanding between a service provider and their client that outlines performance expectations, availability requirements, key processes and remedies for any violations (click here for more.)” I think the key here is that SLAs have to be measurable, because if they’re not, how can you hold anyone accountable for them?
Thinking about my restaurant example helps form a basis for determining what those measures in any SLA might be. The good news is, just like any requirement, we can look at them like user stories with acceptance criteria.
Example 1: What is the “right” amount of contact with a server/staff member at this restaurant?
User Story: As a customer, I want to be contacted by a server/staff member 5 times after being seated, so that I can order and enjoy my meal accurately and timely.
Acceptance Criteria (this is the hard part): As a customer, given that I have been seated at a table, I expect: 1. to be greeted by a staff member within 3 minutes of having been seated, 2. to be offered a beverage within 2 minutes of being greeted, 3. to have the beverage delivered and have my order taken within 3 minutes of step 2, 4. to have my order delivered accurately within 15 minutes of step 3, 5. to be checked on within 6 minutes of beginning to eat, 6. to be offered additional items and/or the check within 10 minutes of step 5.
It’s easy to see and agree upon the SLAs here of contact and timing expectations. The same is true in most software development and process-related efforts. What’s not so easy here is that word “accurately.” What does that mean? In terms of a restaurant order, does it have to be 100% accurate to qualify? Or can there be something lacking that would still qualify? In my example, my order included honey butter, when I had asked for plain whipped butter. Considering my entire plate, that affected the biscuit, which was about 1/4 of the meal. So was my order 75% accurate? And does that satisfy the SLA? What if I was able to get Faith to swap out the biscuit and butter and make it 100% correct? We would probably need some kind of fancy, compound measurement in this case.
Example 2: Accurate orders.
User Story: As a customer, I expect my order to be accurate, so that I can be sure to enjoy it.
Acceptance Criteria: As a customer, given that my order has been delivered, I expect that all elements ordered are 100% as ordered within 3 minutes of order delivery. Otherwise, the SLA fails.
Adding a recovery time to an SLA allows for those “human errors” and “unknown unknowns” that can occur, regardless of the setting. I always like to think back on SLAs we would establish for system up-time. Our business partners would always say the system must be available 24/7, and we always had to remind them that there would be times for maintenance and unexpected outages that we’d need to work into the mix. So, sometimes an obvious need (24/7 availability, 100% accurate orders and the like) isn’t always realistic.
Going back to the definition of an SLA, there’s also this pesky part about “remedies for any violations.” Yes, that means that SLAs also have an element of penalties for missing them. In the case of a restaurant, maybe I can get a discount if my eggs are cooked improperly and have to be redone. In software development, maybe there are ways to renegotiate a contract if there are more failures than allowed. There may be many options here, but the key is, you need to talk about them and agree on them. And make sure that they are reasonable; we want to set ourselves up for success, after all.
Example 3: Tipping
User Story: As a server, I expect a tip from a customer to be based on 20% of the total check before taxes, so that I can earn enough money to maintain my lifestyle.
Acceptance Criteria: as a server, given that I have participated in customer contact the prescriped number of times, and delivered their order accurately and timely, I expect the customer to add 20% of the pre-tax total onto their check as a tip to me.
If, as a server, the customer’s SLAs are not met, I expect a deduction in the amount of tip according to the value they assign to the severity of the failure.
OK, so this one is maybe a stretch, since servers often have tip-sharing policies with other servers and staff, but the concept is still valid. Just like the customer has expectations of the establishment, the establishment has expectations of the customer. The same is true in software development and other areas where business analysis is applied. So while you’re working on your SLAs, don’t forget to look at all the stakeholders involved, including those that are providers. And that penalty part? Well, in this example, we ascribe its determination solely to the customer. This is something that normally would not be done in the “real world” as opposed to “the wild” since we typically have a customer or a user involved in negotiating the requirements. But there may be outlying times when you do have to leave it up to a uncontrollable entity, like a customer who is not a user of a system. For example: if the cash registers are down at the store you operate, customers may penalize you by walking out and not completing their purchase. These are good things to keep in mind when developing SLAs that extend beyond your control.
Now you tell me – what are some of the things you’ve seen in “the wild” that may have triggered thoughts about SLAs? Maybe you waited too long at the doctor’s office. Maybe your flight got canceled (that’s a biggie these days). Maybe the heel of your shoe fell off the first day you wore them. I’d love to hear how these seemingly non-related events have translated into your work life. And, the stories will be fun to hear!
Leave a Reply