A Few Hard Truths About Cloud Vendor SLA’s

From an IT perspective, cloud computing is amazing. Although, from a vendor management and contract management perspective, it’s not. Like a bad haunted house, it’s full of “gotchas” around every corner, not only in the contract language but in the SLA’s (Service Level Agreements) that don’t allow you to effectively manage the vendor when things go wrong.

What’s so difficult about cloud computing SLA’s? Well, to name a few…

1) Silver, Gold and Platinum are not your friends. When reviewing the contract, take a look at the SLA’s. Do you have a choice of “Silver”, “Gold” or “Platinum” service plans to choose from? It seems pretty easy, right? Yes and no. It’s like one of those burritos at the 7-11. They’re wrapped up nicely underneath those hot lamps in that silver foil. When you’re desperate, you’ll buy one, only to open it up in the car and realize that it’s a molten blob of artery clogging goo that smells like roadkill. It’s similar with these cloud service plans. If you have mission critical systems that will be running in the cloud, closely analyze these service plans and fully understand how your Sev 1 issues will truly be handled. Otherwise, you’re in for a bumpy ride on the burrito express.

2) Pray for 90.0% uptime and hope you get 91.0%. It’s really amazing that these vendors can get away with 90.0% uptime. What’s your company’s SLA around uptime? Do you have one? If not, it should be at least 99.99% (if not 99.999%). However, most cloud providers will fool you into thinking that 90.0% uptime ain’t so bad. Is it? Yes, it actually is. In fact, if you do the math (and this is pretty scary, so hold onto your hat) on 90.0% uptime, it comes out to 36 days and 12 hours of downtime per year (in a non-leap year). Can your company handle this much downtime? Really? I didn’t think so.

3) Everyone has the same SLA’s.  Everyone that purchases the product from the vendor is on the same version, and everyone has the same SLA’s. Going back to the Silver, Gold and Platinum plans, there is no deviation from these SLA’s and they’re mostly in favor of the vendor. So, what to do? Don’t choose the first cloud vendor that you met at that great conference in San Francisco. Put it out for an RFI / RFQ / RFP and see what each vendor’s capabilities and SLA’s are before buying.  It’ll save you heartache (and heartburn) in the long run, I promise.


Demystifying the Statement of Work

whoIn your project, Statements of Work (SOW’s) are where the rubber meets the road and unfortunately, many project managers don’t put as much work into them as they should. If there’s a conflict with your vendor, you better believe they’ll pull out the Statement of Work you both signed 10 months ago and gleefully identify the section you forgot to include. Get ready for the “get out of jail free” card!

Using the Who, What, When, Where, Why and How method to keep things simple, here are some questions to get you started on that ever-elusive Statement of Work and stop the dreaded writer’s block.

1) Who?

  • Who are your stakeholders? What do they want out of the project? Do you have business requirements or a project plan?
  • Who will perform the work for the project? Will you perform a majority of the work or is the vendor performing the heavy lifting for you? Use a Work Breakdown Schedule (WBS) format to list the specific tasks for each party (you and the vendor) and be as specific as you can about the work.  Avoid “mutual responsibilities” if you’re able to, as this is always an area of contention.

2) What?

  • What will the vendor do for you and your company?  Are they performing a gap analysis or are they coding?
  • What deliverables will the vendor provide your company at the end of the Statement of Work (i.e. Requirements Document, Design Document)? This is overlooked in a majority of SOW’s. You’re paying the vendor for a service and at the end of the service, you should get something in return. So, what are the deliverables? Make sure you’re not paying them $250,000 for a fifteen page PowerPoint presentation!
  • What’s your acceptance criteria for the deliverables? This is also overlooked. What do the deliverables have to look like for your company to accept them? Do they have to pass heavy QA within your IT department? Or, does your CEO have to review and sign off on them? Identify your acceptance criteria give yourself time in the Statement of Work to review the deliverables before accepting them.

3) When?

  • When does the work with the vendor need to start?
  • When does the work with the vendor need to finish?
  • When do you need the project deliverables from the vendor?

4) Where?

  • Where will the vendor perform the work for your company? Onshore? Offshore? Onsite? Offsite?

5) Why?

  • Why do you need the vendor’s services? Is this work that can be done in-house or do you have to use a vendor (make vs. buy decision)?

6) How?

  • How much will the services cost? Have you gotten a quote from the vendor? Will they perform the services on a fixed fee (less risk to you and your company) or a time and materials basis (more risk to you and your company)?