Third Party Providers

Happy New Year!

I saw an interesting article today that high-tech vehicles were posing problems to some mechanics.  The mechanics claim that they can’t afford the thousands of dollars that are necessary for them to obtain the specialized diagnostic tools for each auto manufacturer.  The manufacturers are claiming that they’re trying to protect their intellectual property.

Sound familiar?  Yup, it’s exactly like the issues Frank Scavo and Ray Wang have written about with regards to third-party software providers being blocked from performing various maintenance/implementation tasks by the contracts and software licenses and services agreements of certain primary vendors.

On the automotive side, it’s apparently gotten to be such an issue that there’s a congressional bill called the Motor Vehicle Owners Right to Repair Act of 2009.  The stated purpose of this Bill is to “protect the rights of consumers to diagnose, service, maintain, and repair their motor vehicles”.  What’s really interesting are the Bill’s findings, among which say that:

• Motor vehicle owners are entitled to choose which service provider will diagnose, service, maintain, or repair their motor vehicles.
• Promoting competition in price and quality… will benefit consumers.
• Only service technician with the necessary tools and information can access the computers to perform diagnosis, service, maintenance and repair…

And the requirements of the Bill, specifically:

• Duty to Make Tools Available:  The manufacturer of a motor vehicle sold, leases or otherwise introduced into commerce in the United States must offer for sale to the motor vehicle owner and to all service providers on a reasonable and non-discriminatory basis, any tool for the diagnosis, service, maintenance, or repair of a motor vehicle, and provide all information that enables aftermarket tool companies to manufacture tools with the same functional characteristics as those tools made available by the manufacturers to authorized dealers.
• Replacement Equipment: The manufacturer of a motor vehicle sold, leased, or otherwise introduced into commerce in the United States must offer for sale to motor vehicle owners, and to all service providers on reasonable and non-discriminatory terms, all equipment for diagnosis, service, maintenance, or repair of a motor vehicle.

The only thing the Bill protects for the manufacturer are things that are actual trade secrets.

Wow.  Of course, there are a LOT of people (and more specifically, a lot of trade association and advocacy groups) behind this Bill.

Could you imagine what would happen if this passes and someone realizes that software in cars isn’t that dissimilar to plain old enterprise software?  If only there was a trade association group for buyers of enterprise software apps.  😉

But let’s talk about the other side of the issue for a moment.  Do consumers have a right to have third-party companies provide service?  A right?  No.  I don’t think there’s a right to be able to have third-party providers.  [Keep in mind, when we’re talking about rights, we’re talking about things equal to “life, liberty and the pursuit of happiness…”.]

Absent a right, should third-party providers still be allowed/encouraged?  I’m really torn on this.  On one hand, I’m all in favor of things that inspire commerce.  I like behaviors that create business, allow more people to work… and of course, things that drive down costs and dissipate apparent monopolies.  On the other hand, an individual or organization who creates something should be able to protect their idea/invention and not have to give up the secret sauce simply so that other people can benefit.  But there seems to be a line somewhere that once you cross it should allow for third-party companies to fill available niches.  Maybe it’s where the original vendor is no longer able to provide a quality-level of service.  Maybe it’s a situation where the original vendor is charging exorbitant rates.  I’m not sure.

Anyone have a solution?

Advertisement

Comic: Why you should have a lawyer negotiate your contracts

Change “lawyer” to “contracts professional” and you’ve got it.

On Acceptance Testing…

My car needed an oil change today.  It’s been about 5 months, 6,000 miles and while I know I can push it that far, it was finally time for me to get it done.  I thought about doing it myself and decided that Jiffy Lube would more efficiently meet my needs.  But I always feel a little weird about oil change places – they show a long list of things that they supposedly check… but unless I stand out there hovering in the bay, I don’t feel confident that they’ve actually completed the work.

Today I didn’t hover, I was reading e-mails.  When they called my name to pay, they quickly read off the list of things they checked and reviewing the computer screen, I asked the guy behind the counter: “Did you check the engine coolant level?”  With a slight hesitation, he replied “Yes.”

I paid, took my keys and walked out to my car.  Deciding to check the coolant level, I popped the hood and looked.  Sure enough, the fluid was below the line marked “Fill”.  I walked back inside and told the same employee that I thought that the fluid wasn’t checked and could he come confirm.  He looked a little shocked, walked out to the car and confirmed that the fluid was low.  He apologized and made some sort of excuse about the shop being busy and that my question during check-out didn’t raise any red flags – that he figured I’d asked them to check it and that his employees did (apparently, he was the manager).  I said it was no big deal, but that I would like it topped off.

[OK.  If you haven’t already figured it out, this story parallels many services-type engagements from the IT world.  You pick a provider when you realize you don’t want to do it yourself, you “order” a set of services… and at the end, you are presented with a completion check-list and asked to pay.  What services providers don’t want prior to payment is anything conceptually equivalent to an Acceptance Test.  They want payment first and then resolution of any “defects” under their services warranty provisions (if any).  This way, they have control of the money and can book the revenue as earned.

But don’t let their desire to avoid Acceptance Testing sway you… and don’t fall into the trap I did today and pay first.  What happened next was predictable and I should have seen it coming.]

The manager then said, “well, we normally charge for topping off the coolant.”

Oh.  Alright, I thought, whatever… just get my car finished and get me on my way. “How much does that cost?”, I asked.

“Five dollars.”

Thank god my negotiation-sense kicked back in … and I just stood there silent for a few beats too many.

“But because of the confusion, I’ll take care of it.”, he continued.

I smiled and said “Thank you.”

While he was retrieving the coolant I scanned the engine compartment and realized that the large rubber gasket between the hood and the firewall had completely come off and was just laying across the engine!  Holy cow.  I was really glad I popped the hood today – this piece of rubber, which probably came off during the oil change and was simply overlooked due to its matching blackness to everything else under the hood, could have gotten wound into various belts, heated and set afire or fallen down to the road and lost.  It was a no-brainer fix to simply push it back onto the car’s frame – but catching it was the biggie.

The same is true for many acceptance testing issues – the no-brainer is to look for them at the right time (preferably before payment).  Don’t get suckered into someone else’s process (they moved my Jeep out of the repair bay and into the parking lot (keys in it and running) as “customer service” perk.  But it’s meant also to get you off the lot before you notice anything wrong (where they can attempt to reasonably say that the problem happened outside their control).

One again, learn from my mistakes.  🙂

Delivering Perfection

In thousands of meetings over the years, I’ve been privvy to a very common conversation.  It’s a discussion of deliverables – what is needed, what is wanted, how much money is available to pay for the needs/wants, who can create the best solution, etcetera.  Regardless of the actual nature of the deliverable, the basics are always the same:  We want what we want, when we want it, at the least total cost.  The end result, however, varies widely on a huge number of factors.  One of them is the quality of the “spec” – the document describing what’s being created; and another is the quality of the group performing the work.

The deliverable is never perfect.  At some point in the process, either the vendor makes errors or the buyer doesn’t adequately describe what they want (or consider all of the various contingencies).  The net result is payment for something that doesn’t do what you hoped it would do – or going over budget for the fix.  So how do you deliver perfection?

Well, the folks who write the software that runs NASA’s Space Shuttle have it about right.  It’s a four-part process that keeps their code running virtually bug free for the last 20 years, and like the Five Fundamental Skills for Effective Negotiation, it’s not (pardon the pun) rocket science:

1. The product is only as good as the plan for the product.
2. The best teamwork is a healthy rivalry.
3. The database is the software base.
4. Don’t just fix mistakes – fix whatever permitted the mistake in the first place.

This is a fascinating story about a group of 260 people working normal hours and achieving extraordinary results (the last 11 versions of the software have only had a total of 17 errors).  Equaly important from a stats perspective are the specs.  For the current application (420,000 lines of code – for comparison’s sake: WindowsXP has 40,000,000 and MacOSX has 86,000,000), the current spec is 40,000 pages long.

Now, granted, many of the projects your teams are working on aren’t operating systems.  But how many of you have seen a spec document that’s even more than 100 pages?  How about 50?  Very few.  In fact, I am used to seeing spec documents of less than 5 pages – 10 at most.  It’s no wonder that there are errors.

I also don’t believe that many of us will be effective in getting our development teams to change, either.  But if they only got a little better, the cost savings would be immense.  So share the article with them from a human interest perspective (ie: don’t push an agenda).  The worst that happens is you start a dialog.

Recovering from a Disaster

I love to play a simple, yet addictive game called Bejeweled on my Palm Treo.  Recently, Pop Cap Games – maker of Bejeweled – released it on Facebook, too.  It’s free to play and hey, they even award prizes based on collective team scores earned every week.  So not only would I normally play because I love the game, I play to perhaps win a prize, too.  What’s important to note, though, is that I don’t pay anything to play.  I don’t pay to access Facebook (at least not yet) and I don’t pay to play Bejeweled.

Yesterday, there was a fire at the Seattle-based hosting facility which Pop Cap uses to host their games.  It apparently brought several organizations to their collective knees – hopefully no one was hurt in the blaze.  Bejeweled, though, was down.  Pop Cap owed no explanation to anyone – there were no paid users, no SLAs, no force majeure.  But their response to the user community was exactly what I would expect from large corporate vendors, yet never receive.

First, Pop Cap posted a notice on the Bejeweled page stating: 1) an apology for the outage! (remember, they didn’t cause it); 2) what happened to cause the outage; 3) reassurance that each users’ data was safely backed up and would be restored when the servers were back online; and 4) an estimated time when the game would be available again.  Second, today the game is back online.  You still see a notice about what happened and why things will look a little funny with your friends’ scores for a little while.  And they apologized again.

Generally speaking, discussion of force majeure in the commercial contracting world (the suspension of contractual obligations as a result of an unforeseeable event) is usually fairly quick and pretty painless once you know the basics.  Both sides usually only spend a maximum of 30 seconds discussing this section of the contract and thus if anything actually does happen that would require invocation of the provision, many are flummoxed about how to handle it.  In fact, some even forget to invoke – they simply look to Service Level Agreements to see if there’s anything that can be done to recover from the other side.

Part of this could be easily solved if enterprise software vendors would follow Pop Cap’s lead in terms of how they handled downtime.  But again, generally speaking, they don’t.  They want the customer to have to report a problem; the customer to have to call in for status updates on fixes; and almost never explain why there was a problem in the first place.  Oh, and I’ve never heard a vendor apologize, either – which, as any psychologist will tell you, is really easy and goes a long way to assuaging feelings.

So, take it from Pop Cap – who with millions of probable users (I don’t have an exact count, of course) and none of them paying a cent, managed to just make me want to go buy something from them simply because of how they handled a problem with a free game and without having any contract tell them how to behave, either.

The reason I draft language the way I do

How I love xkcd.com

Friday Fun

I found an interesting site that covers the trial and tribulations of customer service representatives – stories from the frontlines.  A few even relate to negotiation (and one on contracts), so I thought I would share:

The Lesser of Two Evils

Reorientation Disorientation

They Start So Young

Why Our Contracts Are a Gazillion Pages Long

Have a great weekend!

More on 5-9 Availability

I had a few posts on 5-9 availability in the last two years.  Today, ZDNet reports that 3Tera is offering 5 9’s.  The really positive thing I saw in the article is that 3Tera plans to provide automatic SLA credits in the event of downtime that blows the metric – which, if there’s truly 5-9 availability, shouldn’t take much doing.

I’ll ask the question again that I asked before:  Is it worth the cost?

Software Licensing Education Series – 400s Track Now Available!

Designed for the busy or on-the-go professional, the Software Licensing Education Series (SLES) is video-based training on the complete gamut of software licensing topics. Presented in a college-course level format, with topics increasing in complexity and building upon prior lessons, the SLES allows an audio-visual learner another way to gain knowledge on licensing topics.  Each video is approximately 20-30 minutes in length, so each Track contains about 2 hours of expert instruction in core software licensing topics!

The 400 Track videos include:
SLES 401 – Services Issues 2
SLES 402 – Maintenance and Support 1
SLES 403 – Maintenance and Support 2 (special 1-hour course)
SLES 404 – ASP and SaaS Issues

(500s Tracks are currently in production and will be released shortly!)

Videos are formatted for a computer or portable video player (such as an iPod) and consist of a slide-show format with voice-over instruction, so you can even learn just by listening!

Service Levels and Remedies

We’ve been discussing Service Levels for the last few weeks.  We covered construction, setup, drafting and even some recommendations on how the Service Levels might look.  But what happens in the event that the Service Levels aren’t met (they’re “blown”)?

We should start with a review of why we sought Service Levels in the first place – which is usually because you really just want what you’ve been promised in terms of service or performance.  In this case, remedies for blown Service Levels should be two-fold:  1) to get service restored as quickly as possible, and 2) to recompense for any damages caused as a result of the blown service level.  So you’ve probably even drafted the Service Level metrics so as to put a lot of importance on fewer outages or less downtime – with significant financial penalties.  But you don’t really want the money, you want great service.  The net result is that in the event of a blown Service Level, you probably won’t enforce the financial penalty… it’s more bark than bite.  But you are a stickler for responsiveness and attentiveness, and you will enforce the remedies if you feel that not only have the Service Levels been blown, but that you’re getting ignored, too.  This is justifiable.

But maybe you’ve got a little more jaded view and you already know that you’re not going to get exactly what was promised.  You drafted the Service Levels with really tight controls – trying to count every little thing (without regard to what’s really important) in the particular deal.  You instead feel that software or services are exact sciences and that if the vendor is silly enough to make a promise, you should get everything you’re “entitled” to.  The result is that at the first hint of a blown Service Level, you’re on the phone with the vendor asking for service credits (never mind restoration of service).

Personally, I hope you’re in the first group of folks and not the second.  Software and Services, by their nature, are going to have hiccups.  This is just how it goes.  Even older, established products can have difficulties (environments are constantly changing).  So instead of trying to beat the vendor with your contract, you use the contract strategically to make sure that you’re getting what is really important to the deal … and not some sort of small financial benefit for each blown level.

However, there are times where it is absolutely justifiable to use the contract as a sword and a shield.  One of these cases is what’s known as “death by ducks” – the situation where you have many small Service Level issues.  None of them, on their own, would be worth enforcing as a true blown event.  But together, you get pecked to death by the small things because they cumulatively add up to a significant performance issue.  Here, you should have anticipated this issue and have a small extra section in your Service Level language detailing the remedies available in the event of x number of small issues that add up to a certain Severity Level.  Heck, you can even define it as a certain number of Sev3’s = a Sev2.  And a certain number of Sev2’s = a Sev1.  How would you handle it?