General Discussions

**JeremyMiller** · 11:17 PM

I have recently had some clients who take an inordinate amount of time to reply to inquiries on contracts or otherwise just don't make themselves available. This causes problems as I often need the answers to these questions in order to proceed.

To resolve this, I'm thinking of adding a clause into contracts to require replies to inquiries in a timely fashion. The question, posted as a poll, is what do you use as time requirement or, if you're not currently using a time requirement, what do you think is fair?

EDIT: "More than 4 days" should mean "More than 3 days". Made a typo. If an admin could patch that, it'd be appreciated.

**VirtuosiMedia** · 06-18-2008, 11:55 PM

It can be frustrating when clients don't get back to you, but if you require a response time through the contract, what is your compensation if they breach? Do you charge them? Is the contract terminated and you walk away with whatever they've paid you up to that point and they get your project as it existed at the point of their last payment?

I'm not quite sure I know of an easy answer to this one. Sometimes there are legitimate emergencies that cause delays, but a lot of people just aren't good at following up. If it becomes a real problem, I'd say don't work with them again. You can choose your clients just as much as they can choose you. If you can, try weeding them out beforehand.

**splenditello** · 06-19-2008, 08:05 AM

24 hours..after that someone else has already helped them and you've possibly lost the customer

**JeremyMiller** · 06-19-2008, 08:07 AM

Quote:

Originally Posted by splenditello

24 hours..after that someone else has already helped them and you've possibly lost the customer

I think you misunderstood the question. I get back to people within minutes. It's them getting back to me.

@Virtuo: Good points! I hadn't thought of enforcement.

**Learning Newbie** · 06-19-2008, 04:00 PM

Quote:

Originally Posted by JeremyMiller

To resolve this, I'm thinking of adding a clause into contracts to require replies to inquiries in a timely fashion. The question, posted as a poll, is what do you use as time requirement or, if you're not currently using a time requirement, what do you think is fair?

We have an SLA that details (1) what they'll pay us, (2) what we'll deliver, (3) the schedule it will be deployed at, and (4) KPIs.

We have a clause that automatically waives our requirement to meet deadlines when (if and only if) the customer doesn't provide information necessary to meet our obligations. I'd have to go ask the business people how the legalese defines all that, but honestly, I don't think it really matters. The point here is the spirit of the thing - VM pointed out some issues with the contract route. This allows us to keep the client and the project, but at the same time lets us off the hook if the customer sabotages things, accidentally or otherwise.

This actually hasn't come up since we rewrote our agreements, but there's the ominous threat that if they don't get back to us in time when we need to know how to implement something in particular, that everybody is still under contract, but we've suddenly earned the right to deprioritize the project. I think that has a sort of deterrent effect.

**JeremyMiller** · 06-19-2008, 04:03 PM

Thanks Learning. That's probably the best and only realistic consequence one could reasonably impose.

BTW: What's KPI?

**VirtuosiMedia** · 06-19-2008, 04:10 PM

Quote:

Originally Posted by Learning Newbie

We have an SLA that details (1) what they'll pay us, (2) what we'll deliver, (3) the schedule it will be deployed at, and (4) KPIs.

We have a clause that automatically waives our requirement to meet deadlines when (if and only if) the customer doesn't provide information necessary to meet our obligations. I'd have to go ask the business people how the legalese defines all that, but honestly, I don't think it really matters. The point here is the spirit of the thing - VM pointed out some issues with the contract route. This allows us to keep the client and the project, but at the same time lets us off the hook if the customer sabotages things, accidentally or otherwise.

This actually hasn't come up since we rewrote our agreements, but there's the ominous threat that if they don't get back to us in time when we need to know how to implement something in particular, that everybody is still under contract, but we've suddenly earned the right to deprioritize the project. I think that has a sort of deterrent effect.

Great point. I'll have to include that for when I do it as well.

**Learning Newbie** · 06-19-2008, 04:13 PM

Key Performance Indicator.

No data loss, certain types of transactions will commit within a particular length of time (if your client is an online stock dealer, that might be an order for a trade is executed with 1 minute), etc.

On that note, I've known a lot of people who insist in writing that all KPIs for a database be waved while reports are being run.

**highanddry** · 04:16 PM

Quote:

have to go ask the business people how the legalese defines all that,

Contract law is ridiculous, most contracts are not even legally sound.

I give the client as much time as they want, as long as they do not expect a specific date from me. I prefer quick and efficient customer care.

**JeremyMiller** · 06-19-2008, 04:17 PM

Quote:

Originally Posted by Learning Newbie

Key Performance Indicator.

No data loss, certain types of transactions will commit within a particular length of time (if your client is an online stock dealer, that might be an order for a trade is executed with 1 minute), etc.

On that note, I've known a lot of people who insist in writing that all KPIs for a database be waved while reports are being run.

Thanks. I've never included those (and don't remember the profs in college every mentioning those). I'll look into it more and most likely add it to future specs.

I'd give you more TP, but apparently I've been thanking you a lot.

**Learning Newbie** · 06-19-2008, 04:40 PM

No worries on the toilet paper - I stocked up last week. Really, I just hope this is useful, plus it's a great bonus if it winds up helping other people, too.

So, really, at the end of the day, High And Dry hit the hammer right on the head of the nail. Given the customer as much time as they want, if they're paying you to do what they want, but it has to be known that delays feed into the whole cause and effect thing, which feeds into when you deliver what they paid for. Trouble is, there are actually predatory clients. And so we need iron clad defenses against all that.

**Learning Newbie** · 06-19-2008, 04:48 PM

It seems like a satisfying answer was found for the original question? Normally this would be rude, but since KPIs came up and we're talking about SLAs, I went and found something I'd read a while ago that stuck with me. I hope people don't mind the big copy and paste post here, but (even if it's from the other direction) I think this is informative. Heck, think of it this way - if the customer is ruthlessly protecting their interests, it makes sense you should do the same.

So, here's a post from the SQL Server Storage Engine blog on MSDN.

Quote:

Here are some questions around SLAs - if you can't answer YES! to all of them, then you may be in trouble.
Do you know what an SLA is?
SLA = Service Level Agreement. SLAs are agreements between you and your customers. If you're a DBA, then your customer is typically the company for whom you work. Examples of SLAs are:

In the event of a corruption, or other disaster, the maximum amount of data loss is the last 15 minutes of transactions.
In the event of a corruption, or other disaster, the maximum amount of downtime the application can tolerate is 20 minutes.

Usually, it's a combination of SLAs such as those above.
Do you know why SLAs are important?
Here's the catch - an SLA is really more than just an agreement between you and your customers - it's more like a contract that you're obligated to meet. This means that if you're a DBA with zero-downtime and zero-data loss SLAs, you need to make sure that in the event of a corruption you can actually meet those SLAs. The obvious thing is that if the SLAs cannot be met then the business will suffer downtime and data loss. The not so obvious thing is that if you're the one who agreed to the SLAs in the first place, and when the disaster strikes, the capabilities of the system are far below the SLA's requirements, then you could lose your job - resume/CV time - I've heard of it happening...
Do you know your SLAs?
You have to know what your SLAs are so you can make sure the system can meet them. Several DBAs I discussed this with don't know what their business' SLAs are, even though they are responsible for making sure they are met. I find this astounding - how can you sign up for meeting an SLA when you don't know that the SLA is? Especially if failing to meet the SLA could lead to resume/CV time...
Do you think you can meet your SLAs?
The other reason to know your SLAs, of course, is so that you can correctly architect your system to meet them. There are a bunch of technologies you can use and strategies you can employ to work towards meeting your SLAs (well beyond the scope of this blog post but will be covered through the year). If you find that you can't meet your SLAs, you need to push-back on your management - otherwise you're setting yourself up for trouble when a disaster occurs and you can't meet the SLAs - you'll be held responsible.
Do you know you can meet your SLAs?
Your disaster recovery plan looks great on paper - but have you actually tried it? I know of one company that has a 15 minute downtime SLA for a 300+GB database but the DBA is relying on clusters to provide that for him. That won't work if the database is corrupt (remember a failover cluster has a single point of failure in its shared-nothing configuration - the disks) and needs to be restored from the last full backup... Another company I know of relies on database mirroring to failover in the event of a disaster but has never tried it to see if their application fails over gracefully... You have to make sure you've practiced recovering from a disaster before the first real disaster happens - you'll be amazed at the little things that are discovered (e.g. if the on-site backups are bad, how long will it take to get the offsite copies brought in-house from the off-site location 100 miles away? Can you still meet your 15 minute downtime SLA in that case?)
Summary
As you can can see from my short list of questions and answers above, its vital that you understand your SLAs and know that you can meet them - your business (and job!) may depend on it. If you're having trouble, drop me a line (prandal@microsoft.com) and I'll see what I can do to help.

PS Don't forget to checkout the .NET Rocks! show tomorrow!

**ForrestCroce** · 06-19-2008, 08:49 PM

I borrow from agile and tell them "I'm blocked." Of course, for a lot of things I'd like a response about, I can make an arbitrary choice, stick my value in an xml file, and let them swap it out to their hearts' content.

**JeremyMiller** · 06-19-2008, 09:27 PM

Quote:

Originally Posted by ForrestCroce

I borrow from agile and tell them "I'm blocked." Of course, for a lot of things I'd like a response about, I can make an arbitrary choice, stick my value in an xml file, and let them swap it out to their hearts' content.

Huh? I don't understand this at all. Did I miss something? I haven't had a chance to read through the whole SLA definition (which I very much appreciate), but ... what am I missing?