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

Why RFP’s Suck for Both Sides

RFPs suck for both sides of the equation. Bidders hate responding to them and the requesting organization hates reviewing them.

Why?

Well, because they’re time consuming… and each side believes that the other side is: 1) Only spending enough time to barely glean the financials off the top; 2) Inserting default language from prior RFPs which may or may not have relevance to the current project; and 3) Only doing this to appease some misguided sense of a “strategic sourcing process”.  These assumptions are all 100% true:

1. Using RFPs correctly can be a valuable part of a strategic sourcing process.  But generally speaking, they’re hastily assembled, from a template, and sent out without consideration as to who will get them.
2. Responses almost always arrive at the last possible moment – not because they’re the product of countless hours of taxing effort and meticulous drafting – but because they’re tossed in a drawer and forgotten until the last possible moment.
3. Reviews ARE hastily done… with receiving “teams” designated to score RFPs by section but having no real training as to how to do it properly (usually because they didn’t spend enough time working on a requirements document for the project to begin with).

How do I know this?  Well, it’s easy, really.  After a decade of using them, I long ago learned to monitor the Word document’s properties for the RFP itself.  It’s where I’ve asked responses to come electronically, so I can see EXACTLY how much time has been spent editing the document.  Do I really think that it only takes an hour of editing to respond to one?  Ha.  Only if it’s a copy-paste job.

But I’d wondered what bidders were doing to monitor our review.  Now I know.  And I think it’s an excellent smack-down.  Reviewers SHOULD be held accountable for the efforts they ask others to expend on their behalf.  As time-consuming processes go, you should at least be willing to put in the effort to review something that you’ve asked someone else to create.  Oh, and by all means should you have LIMITED the number of potential respondents long before sending out the document package.

By the way, all of the food, drink and alcohol provided by these various agencies sure smacks of impropriety to me.  NEVER send a reviewing organization ANYTHING until after the deal has been signed… and then you’d better comply with that organization’s gift policy or you should expect to get it back.

 

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.

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!

Zen and Art of Service Levels (with apologies to Robert Pirsig and Eugen Herrigel)

“The aim of Zen practice is to discover [this] Buddha-nature within each person, through meditation and mindfulness of daily experiences. Zen practitioners believe that this provides new perspectives and insights on existence, which ultimately lead to enlightenment.” —Wikipedia

As silly as it sounds, the way to master service levels is to draft them over and over.  Yeah, this is the same way to get better at anything, contracts especially.  But service levels are a little special.  I think it’s because they’re going the way of the Dodo.  As few people ask for them, even fewer know to even think about them.  It’s the same cycle that increases the quality of service levels – just in reverse.  Pirsig’s book was focused on trying to define “quality” and in the end, he settled upon a mix of rationality and romanticism.

I said before that service levels have to be SMART: Specific, Measurable, Attainable, Relevant, Time-Bound.  We’ll blend the rationality and romanticism as we go.

Specific – Service levels start with an understanding of the exact quantities of some metric.  This could really be anything, but tempered with the next quality, you have to be able to count it.  Typically, we start with things that are time-related: uptimes and downtimes, repair times and fix times.  Rationality wins here almost every day (the truly romantic notion is that service levels aren’t needed at all because everything’s going to work out as planned) – these things are really easy to measure… and frankly, ease of measurement is necessary because the folks who will be monitoring the service levels aren’t really interested in tracking them.  But why not be a little romantic, too?  Pick something unique about the particular situation.  Maybe you’re licensing software that processes transactions (so you’d count the transactions processed), or maybe you’ve hired an outsourcer to answer your support calls and service levels could be managed based on the number of successful versus unsuccessful customer service resolutions.

Measurable – This might seem obvious, but you’ve got to be able to measure what it is you’re going to base any metrics upon.  Just counting isn’t necessarily enough.  Rather, you might need to be able to track start/stop times/days (and then do the math to calculate the difference).  If the calculation is manual, you also need people who can keep track.  This, perhaps, is the most problematic part of any service level management… as the folks who want the benefits of the service level (usually managers) are not the people watching the clock or experiencing the outages first-hand (the staff).  So unless the staff has some sort of reason to monitor the metric accordingly, none of this is going to matter.

Attainable – I promised you before that the Myth of the Nines would come back into your life, and here it is.  The simple truth is that Five-9 availability is a pipe dream.  5.26 minutes of downtime a year.  Just think about how long your average PC takes to power-cycle.  Servers are typically a little longer.  Even with redundant systems, backups, high-availability resources and every other techincal resource… it’s just not reasonable.  Notice I didn’t say that it was impossible.  It’s 100% possible.  You can have 100% availability.  The issue is cost.  No one ever wants to PAY for that kind of availability.  Not even your most demanding customers.  Wanna’ test this theory?  Price it out from your vendor(s) (as it’ll take more than one to keep even a single service up 24/7/365) and ask your most demanding customer if they’ll pay for the ENTIRE service themselves (since that’s the real cost to get it).  Let me know if they’re willing to do it, because I have a bridge or two to sell them.  Seriously, I’m not trying to be facetious.  I’m a pretty demanding customer myself, but even I know and understand financial limits.

Relevant – Tied to measurable and specific is that each of your service level metrics be relevant to whatever service you’re receiving/providing.  So if you’ve chosen to measure successful versus unsuccessful customer service resolutions, but it’s not tied to the behavior of the service provider, that’s not a relevant metric.  The provider doesn’t have any control over what is being measured, even with perfect behavior.  So where is their incentive to work towards meeting the metrics (or agreeing to them in the first place)?

Time-Bound – Service levels are limited to time.  At first, this sounds quite limiting, but we’re not talking about time in terms of the length of the relationship (service levels should extend for the entire length of the relationship).  Rather, the time we’re talking about here is the time frame in which each metric will be measured.  So, perhaps you’re watching uptime on a daily basis… or the number of widgets produced in a week… or the number of successful service calls completed in a year… or the average length of time it takes to fix a problem of a given severity level over the span of a quarter.

OK, so now that you’ve considered all five requirements, you should have one or more appropriate service levels.  If you still need some ideas, check back with me for the next installment.  Meanwhile, if you have some ideas for inclusion in the next installment, send them along!

Service Level Basics

I eat out a lot – exempting breakfast (I don’t eat it), I would say that I’m at a restaurant for about 10 of every 14 available meals.  Never mind what this does to my budget, let’s focus on the food.  Now, I’m a pretty simple eater – in fact, I love things plain.  When I go to McDonalds or Burger King, I get the burgers with nothing on them – just meat and bread.  Add in some fries and a drink, and I’m a happy man.

So in most situations, I’ve got three components to my meal: an entree, a side and a drink.  Statistically speaking, there are eight possible combinations of quality (assume that each item can only be good or bad):

bad burger, bad fries, bad drink
bad burger, bad fries, good drink
bad burger, good fries, good drink
bad burger, good fries, bad drink
good burger, bad fries, bad drink
good burger, bad fries, good drink
good burger, good fries, bad drink
good burger, good fries, good drink

Thus, for any given purchase of just these three components to my meal, I have a 1 in 8 chance of getting all three “good” items.  That’s a .12512.5% [thanks to John O. for correcting my math] chance – WAY less than 1% that I’m going to enjoy all three items.  On the other hand, there’s also only a 1 in 8 chance of having all three be “bad”.  There’s a 3 in 8 chance that one will be “good” and a 3 in 8 chance that two will be “good”.  So what do I do?

I set my expectations accordingly and know that there’s a 50% chance that I’ll enjoy at least two of the items (the 3 in 8 that two will be good plus the 1 in 8 that all three will be good).  Yes, I know that there’s a 50% chance for the reverse – but remember also that there are some other variables that we need to account for.  In all name-brand fast-food joints, there are quality standards set by the franchisor.  McDonald, Burger King, Chick-Fil-A, Wendy’s, Arby’s, KFC, Taco Bell, etc… they all have: food that is pre-packaged and sent to the stores (reducing the likelihood of differentiation by store); cooking standards (look behind the counter some time and see if you can find the poster showing the correct “doneness levels”); even standard equipment (fryers, etc) to reduce variations.

So in actuality, there’s a better than 50% chance that my food will be “good” (meeting the corporate standard) because of these outside variables.

OK, so what does this all have to do with software, services and service levels?

Well, it’s 100% the same.  Service levels are quality-based promises a customer seeks from a vendor.  There are a lot of variables (such as the software), a few standardized items (usually the hardware), and you try to pick a few key metrics that you think will be able to give you a quality rating on the meal (the service itself).  The question is whether you can appropriately gauge how often you’re going to be satisfied with what you’ve purchased and cope with it when you’re not.

In the software and services world, service levels are typically measured in response time or uptime, used to enforce the vendor’s sales-pitches that the particular good or service will be as incredible as it was during the demo.  Vendors, of course, don’t like service levels, and customer’s predictably, love them.  However, in all of the years I’ve been playing this game, I very rarely see service levels that benefit either party.

To be effective, service levels have to be SMART (as made popular by Peter Drucker):  Simple, Measurable, Attainable, Relevant and Time-Bound (we discussed these earlier when talking about writing SOWs, too).  So while you might have a service-level grid in your template agreement, for any particular product or service, you have to evaluate those pre-defined levels and see if they make sense for whatever it is that is being purchased.  This is no easy task and requires a lot of input from your colleagues down in IT support, architecture, engineering and management.  You have to look first at the product or service’s use (Is it customer facing?  Is it mission critical (yes, be honest on this one)?  Is it internal-use-only?  Is it backend-use-only?)  Then you have to look at WHEN the product is going to be used (day, night, weekends, random).

But most important, you have to look at the actual impact of being without the product or service and for how long you can be without it before a real negative impact sets in.  So, for example, how long could you be without your word processing application company-wide before productivity takes a significant hit?  Can you actually calculate the damages that would result if noone had access to e-mail for an hour or two?  Probably not.  So you’re left with guess work.  Which makes a vendor (and many customers) pretty squeemish about putting hard dollars to soft numbers.

Over the next few posts, I’m going to talk about a few specifics and we’re going to re-visit the Myth of the Nines.  Get out your red pens and engage track-changes… we’re going to alter your service level perceptions.

Oh, and because I was talking about the 1 in 8 chance of getting three good food items earlier, well, it happened yesterday.  The Burger King in the Charlotte Airport nailed a plain Whopper, fries and a coke.  And it was at a time when I was REALLY desperate for good food, too.  Less than 113% chance, perhaps, but still possible.

Consortia – the other side

Jason Busch over on SpendMatters was talking recently about consortiums.  He was pretty positive about them – and praised their use as the “easiest way to save money while improving internal customer satisfaction inside a company”.

I’m not as convinced.

A few years ago, I was working for an organization that wanted to join a buying consortium.  The proposed result would be a buying entity that would supposedly garner savings as a result of larger purchases – thus passing along the cheaper per-unit costs to the consortium’s members… sorta’ like a Sam’s Club, Costco or BJ’s Warehouse – just at the large company level.  On its face, this sounds like a great idea.  Pay a small membership fee (someone has to get paid to manage the relationships), get large savings in a number of commodity purchases (paper products, general office supplies, etc).

Oh wait.  Did I say commodities?  Yes, yes I did.  Commodities are an excellent use for consortia buying.  They’re ubiquitous (everyone needs toilet paper and almost everyone’s buying the cheapest they can find), relatively easy to source (and hard to screw up), and bulk quantities clearly reduce overall expense.

But what if your consortia wants to offer something else… say, intellectual property?  Software, for example.  Now I think there’s a problem.  The member companies no longer have identical interests.  Your organization wants Exchange email… mine wants Groupwise.  You want an enterprise license … and I do, too, but my enterprise is 3x bigger than yours.  Consortia buying stumbles in the face of diversity of interests.

Another area where I personally had a lot of issues was the realm of cell phone and long-distance telephone plans.  The consortium wanted a cut of the plan revenue.  I didn’t want them to get money from me this way, as I would prefer to have more cost savings straight from the vendor.  Oh, and the consortium was buying a bulk group of “minutes” that were then allocated to the members.  If I didn’t meet my minimum usage requirements, I had to pony up (which is normal).  But the twist was that if any other member organization didn’t meet their minimum, I was also responsible for helping cover the shortfall.

So, how did I find out about all of these nits in the deal?  Well, me being me, I asked to negotiate the contract(s).  And what I got in return was a lot of static about how the contracts were already complete and that I simply needed to see/sign the Member Enrollment agreement to add us to the consortium.  I said no thanks – that I had specific needs and I wanted to have my own contract (where we could/would selectively incorporate terms from the consortium’s agreement).  Boy did that go over like a lead balloon.

What I learned by reading the consortium’s agreement (which they originally didn’t even want to give me) is that I’m ultimately paying for someone to negotiate a deal that’s good for them, not me.  When I wanted to change the terms with the vendors, they, of course, balked, too (they thought they had done-deals with the consortium and its members).

So the net result is that I’m not a huge fan of consortia buying.  Consortia are essentially negotiation and contracting outsourcers.  I don’t need help getting discounts or better deals… and I definitely don’t need “help” that only really benefits the consortium organization (and not the consortium members).  But I do see value in using a consortium to get the bulk-quantity ubiquitous products of everyday office living.  I suppose, as all else in life, the key is moderation and to read before you sign.

Outsourcing article at SearchCIO.com

Rachel Lebeaux wrote a great article on outsourcing issues over at SearchCIO.com.  And it would still be great, even if I wasn’t quoted.  😉

99.999

Back in the day, we used to fight for five-nine availability.  This meant that you would have access to the product or service 99.999% of the time.  (If you’ve not read Wikipedia’s article on the Myth of the Nines, now’s your chance.)  Mathematically, this equates to only having 5.26 minutes of downtime a year.  Pretty impressive, when you consider how long it takes the average computer to simply reboot.

We would tie the availability requirement to a penalty (aka “financial incentive”).  This is a kissing cousin to service and support response/repair times and similar penalties… and it heavily applies to situations where you need steady and consistent access to a particular product.

For ASP/SaaS products, uptime is extremely important, as it not only defines the amount of time you have access to use the product but also is a measure of the service provider’s value/responsibility (you don’t have access to the product to fix it yourself).  Until recently, though, network bandwidth wasn’t really available to sustain the offerings and was the scapegoat for much of the argument to reduce or eliminate uptime requirements, even if it was the vendor’s back-end server performance causing the problem(s).

As a result, compromises were made to allow uptime calculations only based on daytime work hours (so downtime at night wouldn’t be counted) for those businesses which didn’t have 24/7 operations.  Compromises were also made to allow vendors the ability to challenge a request for credits based on downtime.  Of course, compromises are fine so long as you’re not compromising your business model.

Flash-forward almost a decade.  Gigoam commented recently about the fact that the current movement towards more cloud-based computing is going to require more attention towards availability.  I agree.  And I’m a little disappointed that I haven’t yet seen a likewise return of significant uptime commitments.

The bandwidth is here (to understand the difference between then and now, check out this table and compare 10Base-T versus Gigabit Ethernet, almost a 1000x speed difference) and applications are designed to be a little more efficient, too.  The result is a resurgence of ASP/SaaS products.  There are several that I love, actually.  They’re incredibly good products, with good support and they don’t typically have downtime problems.  But I’m not seeing uptime guarantees of any significant amount.

To get decent uptime availability commitments from your providers, you need to be in-the-know regarding your own proposed usage and the product offering:  Know what the service’s value is to your organization.  Know when it must be available and when it can be down.  Know about server-loads and peak-usage periods.  Know the difference between hot/warm/cold backups and have an understanding of what failover might require.

99.999% availability might never be offered again… but something should be.  Make sure you’re asking for an uptime guaranty from your providers. Never forget that the middle name of ASP and the last name of SaaS is service.