Category Archives: metrics

Yours, Mine or Ours

Every major (and most minor) sellers have a contract/agreement template that they will send you to sign at the time you purchase their product. Sometimes is as simple as a click-through agreement inside the installation process. Sometimes it’s a multi-page license and services agreement that takes weeks/months to negotiate. But if they send you their template form, they want you to use it.

Why?

Because starting with their template gives them power. They wrote the document covering those things that are important to them and with language that is obviously agreeable to them as well. Do you sign it?

Most people do – without looking. And frankly, that scares the heck out of me. If you’ve been following along these last few months, you know that I’m putting contracts into a contract management system. Along the way, I’ve seen a heck of a lot of not-so-great deals that were “just signed” because someone on the seller’s side knew that if you start with a form, the Power of the Template(TM) usually kicks in.

So how do you counteract the Power of the Template™?

First: You need to remember that a template is a suggestion, not a mandate. If the seller really wants to sell their product, they will negotiate.

Second: Negotiation means that they will modify their template with changes you make and will sometimes even use YOUR template.

Third: Wait! Your template? Do you even have a template? Depending on the situation, if you know you’re going to be consistently buying a certain type of good or service, then by all means, you should have a template for that type of transaction!

For me, this means that I have at least 10 template agreements: at least 2 types of NDA (unilateral and mutual); a Software License and Services Agreement (covers EVERYTHING anyone would want to buy when they buy software: software, maintenance, installation, training, consulting, etc); a Master Services Agreement (for non-IP-related services like mowing the lawn); a Consulting Services Agreement (for people developing IP for me, like new software code, design, etc); a Statement of Work and a Work Order template (to make sure that I always cover the concepts I want in my orders); and an Amendment and/or a Change Order template (yes, a little much at times, but good to have).

In some cases, I’ll even develop my own ASP/SaaS template (if my organization does a lot of that kind of buying).

Now, you might say “But Jeff, how can I create a template for software or ASP stuff when I have no idea about how the vendor licenses their product?”

Well, you’re right… it’s a bit more tricky to develop these templates from the buyer’s perspective and you have to include a lot of extraneous things (like definitions for all of the known software licensing metrics). But it can be done… and once you have it, you can start to enforce the use of your templates. This will result in two positive things for you:

1. Your speed to deal completion will increase. I don’t know if you’ve been measuring how long it takes you to negotiate a deal, but the huge time-sucking thing at the beginning (the first read-through/red-line) takes an incredible chunk of time. Off-loading that to your vendors is a huge time-saver. And even if the length of time on the deal signature doesn’t decrease, YOUR time is freed for other things.

2. You can measure the number of deals on your paper versus those on vendor paper (ie: managing risk). Which is a metric you can share with your management regarding a decrease in overall contractual risk. I simply tell my vendors the truth to get them to use my template, combining these two points: If you want to close this deal in a relatively short amount of time, you’ll start with my document.

But writing templates is initially time consuming and requires a great deal of thought and organization. It’s not something you want to do in a hurry and it’s not something you want to do if you don’t have a significant amount of experience in the subject matter of the template. So don’t be afraid to seek out help.

Anyone want to share their experience in using their own templates?

Writing Contractual Requirements

Last year, we spent the bulk of our time talking about a variety of what I’d call “base-level” contract terms.  Term, termination, breach, warranties, assignment, indemnification, etc.  But these are just usually the starting points for the relationship with the other party.  In almost all cases, you’re going to have at least one other document that actually describes what the other party is going to do for you (especially if you’re a buyer of services).  So, for 2008, I want you to improve your ability to write SOWs.

A Statement of Work (or a Work Order) is an add-on document to the base-level agreement.  It really only needs four simple components:  1) A description of the work; 2) A time-frame in which the work will be completed; 3) A way to measure that the work has been completed; and, 4) A description of how payment will happen.

Unfortunately, each of these four areas can get a bit tricky, even when you’re talking about a single piece of work.  When multiple SOWs start interacting together, things go from bad to worse.  In the next few weeks, we’re going to talk about each of these areas in sequence.   However, before you start writing SOWs for your customers or clients, I suggest you always, always, always, step back from document to talk with the project manager.

The reason for this discussion is that you need to have a perfectly firm grasp on what goals you seek through the creation of this SOW.  We’re going to do this with Peter Drucker’s SMART mnemonic, which we’ll use again in measuring the work (because at the end of the day, you’re writing this SOW for the measurement of the work).

SMART is an acronym that stands for Specific. Measurable. Achievable. Realistic. Timely.

Specific:  You need to be VERY clear.  You can’t just say, I want a content management system.  You need to say that you want a particular vendor’s particular version of a content management system.  This throws a lot of people off, especially the project folks.  They know what they’re talking about.  They believe that the vendor does, too, so why be this anal-retentive?

Measurable:   It’s hard to have a goal when you can’t tell whether you actually achieved the goal.  Telling the vendor to install the content management system isn’t enough.  You need to be able to say that you actually crossed a finish line somewhere.  Most contracts use dates – the content management system must be installed and in production by March 1, 2008.  Now you can say whether or not it actually happened per the agreement.

Achievable:  It might sound obvious that you want to achieve your goals.  But you might be amazed to discover that many goals simply aren’t achievable because no one has wanted to admit that the goals, as stated, can’t be reached.  If you’re trying to install “the best” content management system, you’ll have a much more difficult task than if you’re trying to install a content management system that has 5 key business features/functions and is compatible with your 3 related key existing systems.

Realistic:  If the installation of your content management system is supposed to happen by March 1, 2008, but it’s actually today and no work has been done, it’s not likely that all the work that has to happen can really happen by March 1.  Sometimes it’s easy to get swept up in the excitement of a new project and over-deliver… this is not a wise move.

Timely:  Well, I used the dates in the Measurable section above, but they’re true here, too.   You have to use time as a way to bind the parties.  Otherwise, some projects seem to take on a life of their own.  We use deadlines as a way to drive to successful project completion – and as a way to check and see if milestones have been reached.

Copyright, the iPhone and You

The new iPods were released on Wednesday, along with a drop in the price of the iPhone – and Steve Jobs then announced a little tweak to allow an individual to “buy” a song solely for the creation of a custom ringtone. He was excited that you’d pay $.99 for the song and then $.99 to allow it to become a ringtone – still less expensive than most “premium ringtone” services. But during his presentation, he let loose a little slip that I haven’t heard mentioned on anyone else’s blog or on any news outlet. He said that the extra $.99 was for the rights to make the song into a ringtone.

Woah. Wait a minute. Don’t you already HAVE the rights to turn your music that you’ve purchased into ringtones? Let’s break down copyright just a little bit and find out.

There are six exclusive rights granted to the creator of a work. These six (reproduction, creation of derivative works, distribution, public performance, public display and the right to perform via digital audio transmission) can be granted to a “buyer” independently of any other rights and in fact, can be parceled even within one specific right.

This is why, when you “buy” a CD, you can listen to the song anywhere you can take the CD – and you can rip the songs from the CD to your computer/MP3 player. But it’s also the reason why you have to remove the songs from you computer/MP3 player if you ever sell the CD. You have a license to the songs – you didn’t actually buy the songs themselves (hence why this is important to us in the software realm).

But the deeper meaning of what Jobs said, without elaborating, is that the license you get from a downloaded song on iTunes is actually a more limited license than was originally considered by most consumers. Namely, that there is NOT included in the license the ability to make a ringtone. I disagree.

The only way this would be possible is if one of two things were happening. First, if you actually received notice when you were downloading the song that there was a more restrictive license in place; or second, if the ringtone is somehow going to be considered as a derivative work. As I’ve downloaded a few songs from iTunes, and actually read all of the license language that came with iTunes, I haven’t yet seen anything that would restrict my usage of a downloaded song. In fact, iTunes itself has a restrictor built right in – knowing full well that people won’t remember differences in licenses for each song – so it limits your ability to create a CD with a certain playlist more than a specific number of times.

That leaves derivative works. And I’m just not sure that a 30 second clip from a song – which hasn’t otherwise been altered, really constitutes a derivative work. I’ve never heard of someone playing a ringtone (mine happens to be a-ha’s “Take on Me”) that’s anything other than a clip from the song. If the 30-second clip WAS a derivative work (ie: was altered by the consumer in a way that made it a derivative), it would be problematic regardless of whether it was a ringtone or not. But taking a chunk of a song and playing it on your phone isn’t a derivative work – you are not required to play an entire song every time you hit the play button, and you can play your existing CD, for example, in your house, car, boat or portable player. Thus, Steve’s comments the other day don’t reflect the derivative work option.

In all, that means that you CAN create a ringtone from any song that you’ve already lawfully purchased/licensed. Apple and iTunes are making the recoding industry happy to charge extra for something that isn’t required to pay extra for (at the moment). This also lead to two possible ends to this story, both of which affect us in the software world:

1. Apple is just getting away with what the consumer population will let them charge. The average consumer doesn’t know the law – nor do they realize that they don’t actually have to pay to make a ringtone. They’re paying for the feature in iTunes to make one more easily. In the software world, this happens all the time, with vendors selling products based on “value” to the customer. Fuzzy math at best.

2. Apple is introducing a new licensing model for music – more restrictive than anything you’ve been exposed to in the past – licensed per consumer’s use (as opposed to commercial use, which is already restricted in this way). As consumers, we will either have to manually manage these different licenses, or technology will come up to “help” – but “help” is a misnomer, as I don’t want help with losing rights I already had.

As before, the software world feels this already and it’s just getting worse. License metrics are getting more and more restrictive – it’s now quite common to find double, triple and sometimes even quadruple license metric restrictions. Be careful what you agree to – as you’re setting precedent for what the industry will do to everyone else.

Service Levels Redux

Back in March, I discussed the creation of service levels for the first time. I talked generically about how to create a service level and what key components were part of the process. At this past weeks’ IT Financial Management Conference, one of my sessions focused on performance guarantees (which is just a broader description that includes service levels). What I realized is that, along with maintenance percentages and other negotiable items, buyers have long been reducing their demands – which has increased the “boldness” quotient for our vendors.

So first, as with these other contract sections, please let me remind you that your actions DO impact others. The less you ask for now, the less I’m going to be able to get without a struggle later.

More importantly, however, is that you should remember that there are two primary classifications of performance guarantees.

First, Service Levels (and Service Level Agreements). SLAs, in my view, are to describe guarantees related to the performance of contractually-agreed upon services. This means that SLAs are usually used to measure performance against response and repair times in your maintenance agreement. In other words, SLAs measure quality. How well did the vendor do with respects to performance?

Obviously, you have to have stated response and repair times to make these work – and such times will also usually be based on a “severity” level determination, too. Thus, outages for Severity 1 (high) will require a much faster response than those for a Severity 4 (low) problem. But with proper definition, you can cover your bases adequately.

Second is the use of Standard Performance Obligations (SPOs). These are the types of things I was really talking about in the last post on SLAs. The distinction here is that an SPO is measuring output/availability/quantity as opposed to quality. So a SPO would cover uptime/downtime or the number of widgets your software is supposed to process in a given time frame, etc.

See the difference between SLAs and SPOs?

Your contract might need both for you to be sufficiently covered for any particular issue. Both require good definitions, measurability, reporting and “incentives” to meet the guarantee. But each one measures something a bit different than the other and it’s important to cover both.

How do you measure performance in your agreements? Comment below!

Strategic Sourcing

You read a contract because you are either buying or selling something. On the purchasing side of the transaction, many organizations have a procurement group (called “Purchasing” or “Procurement”, sometimes “Sourcing”) and many also have a contracting group (almost always just “Contracts”). And, within larger organizations, most believe that the combination of the two groups automatically bestows upon the organization the coveted concept of “Strategic Sourcing”.

The mere existence of Purchasing and Contracting teams, even if they’re working together (which isn’t always the case), doesn’t mean that an organization is doing any sourcing, nor does it mean that they’re doing it strategically. The plain truth is that it takes a dedicated effort, above and beyond having the groups working together.

The creation of a strategic sourcing team for your organization (and a strategic sourcing plan) starts with a recognition of the end goal: making purchase decisions based on significant data analysis and always with the best interests of the entire organization in mind. Sounds simple, of course.

Let’s talk about strategy first.

Information alone isn’t helpful. Most organizations’ contracts files are filled with millions of words in thousands of contracts. The information itself is already there – the key is to be able to sift through the data to get exactly (and only) what you need when you need it. This is the primary argument for a good contract management tool (Procuri, Emptoris, Nextance, etc). Once such a system is in place, much of the ground work has been laid – the trick then, of course, is being able to keep the information updated and to be able to mine it.

Your digging and mining is to discover not only where you’re spending your money – but what vendors are doing which types of work, where there are overlaps in skills, even where you have multiple pieces of software doing similar tasks. Again, this isn’t difficult. From the point where you decide to start looking at this information to the point where you have good research results can take as little as six months for an average sized organization. And unfortunately, this is where most organizations stop. They have “a system” – people are even using it faithfully. They know who is doing what, when, and for how much.

Which is why, to get to true Strategic Sourcing, you have to worry about the sourcing side of the phrase.

What’s lacking in most places is this next step: where decisions on purchases change as a result of the data in the system and where some vendors are even eliminated as a result of consolidation and house cleaning (ie: “sourcing” a solution rather than just buying one). This is admittedly a difficult task. Culling through your records (and staying on top of them at all times) to diligently maintain the discipline needed is a full-time task beyond the scope of most contracts and procurement people (who are usually just trying to keep up with demand). Thus, taking a strategic sourcing direction requires additional staff.

And remember when I said “vendor are eliminated”? As you might imagine, this isn’t always a popular decision. Selecting the downsized vendor(s) involves a painstaking process and requires political savvy within the organization. In fact, it might even add additional expense (contract termination fees, replacement systems on other vendor’s platforms, etcetera). No two organizations are identical, each one has to decide what is the right option – but at the end of the day, if strategic sourcing is the goal, the price to get there for an organization that hasn’t been doing it from the start is going to be significant.

On the reverse side of the coin, cost savings from moving to a strategic sourcing model are high. Volume discounts alone, via one or two vendors who do “x” task rather than 30 vendors each doing 1/30th of “x”, can net substantially-reduced expenses. Ask any organization that has done this exercise with their HR staffing contracts – the consolidation consultants themselves promise millions.

But it’s not just cost savings that makes strategic sourcing valuable. The real benefit is in reduced time to contract, fewer agreements/relationships to manage, and the overall reduction in risk from having so many different relationships.

Regardless of where your organization sits on the path, however, the ultimate goal should be Strategic Sourcing. It will take time, effort and cooperation – well worth it for the end result.

Service Levels

The last thing most people want to consider while starting a relationship is what happens if the deal goes south. As a result, areas of the contract having to do with breach, termination and service levels or performance guaranties tend to lack the same depth as others.

Specifically with respects to service levels, the goal is to create a measurable set of steady-state obligations that are able to be met by the product. The first two steps are then to list the obligations themselves and their associated performance level. This could be as simple as saying that the product will operate uninterrupted to a certain percentage of the day, or as complex as 30 or 40 individual operational features that have to perform to a certain degree or quality (such as providing a report generated in a specific time period).

After you know what obligation(s) to watch and the required operational level, the next step is to make sure that the obligation actually can be observed. Many SLAs are good in theory, but don’t provide practical metrics simply because there’s no way to know whether they have been met. For example, many parents want to know that their newly-driver-licensed children can’t or don’t exceed the speed limit… but until there was a device that could watch maximum speed, reliance was upon the integrity of the driver.

Next is determining WHO is responsible for tracking the SLA. This entirely depends upon the product – I’ve seen the responsibility equally distributed between both licensors and licensees… just make sure the party who is tasked with the job knows that it’s their responsibility. But, especially with services-related tasks (or ASP/SaaS products), the job normally falls to the vendor/licensor, as they’re in a better position to watch performance.

The “watcher” should then also be in charge of reporting the metrics to the other party on a regular/consistent basis. If the obligation is that a service will be available 24x7x365 with 90% uptime, then it’s reasonable that each month a report will be created showing any downtime and how that compares to the 90% requirement.

Lastly, and usually of primary importance to the licensee/buyer, is the issue of what happens if the metric is “blown” and the SLA is missed. Contractually-based remedies are my preferred method for handling this what-if – but unless the true damage of missing an SLA is calculable prior to the missed service level, there’s the chance that any contractual remedy will fall short of actually fixing the issue. So rather than focusing on penalties, which is often what happens in the negotiation, focus attention on how much effort will be used to solve the current problem and prevent future problems.

If a vendor is then unable to prevent the problem from recurring, or in the event that the SLAs continue to be missed, financial penalties can be included as a last resort to return some of the fees paid for the lack of 100% guaranteed service.

So, when creating SLAs, take the time to discuss the needs behind the SLAs with each other. As with other sections of the agreement I’ve discussed in the last few weeks, a little open, honest communication at the beginning of the relationship can avoid lots of future problems.

Assigning Software Licenses

Last week, we discussed Assignment, primarily as it relates to services-type work and the issues that come up in that particular arena. This time, we’ll add additional complexity by dealing with software license assignment.

[Note: the term “assignment” is used with respects to rights and the term “delegate” is used with respects to obligations. I will use the term “assign” or “assignment” through this post for both, but when drafting actual contract language, keep both terms in mind.]

Recall that assignment is the redirection of all or some contractual right(s). Template language in most agreements prevents unilateral assignment, usually requiring the permission of the non-acting party to complete the act. For services-type work, it’s fairly common for subcontractors to do bits and pieces of larger agreements… and prime contractors do have a tendency to disappear sometimes. But when you deal with software assignments, the game changes. A lot.

Assignments with respects to software manifest normally in ASP and SaaS relationships. As discussed in this blog before, a service provider relationship for software works by allowing the service provider to have some sort of right to host the software. In some cases, this is done with assignment language, allowing the licensee to grant a service provider the right to host the software on behalf of the licensee during the ASP relationship. With SaaS vendors, however, this right is part of the license itself, as the vendor is the service provider.

Assignments of all rights, however, get a bit more sticky. Software vendors price and license their products based on the perceived customer value that the software brings to that particular customer. The vendors, however, can’t know this value explicitly, so they guess and create a price they feel is reasonable and one that will be paid by the licensee. Again, as discussed previously, we’ve seen that licensing metrics are used as a way to calculate that value.

A customer who assigns all of their rights to another party can mess up this calculation, especially where site-based or enterprise-type licenses are involved. The problem can most easily be illustrated by imagining a licensee with 1000 employees in a single geographic location obtaining an “enterprise license” to a particular software product. They’re charged a fee, created by the vendor, based on the number of employees at the time of the initial license grant – and based on an estimate of how large the company will grow over time. This wasn’t usually a problem. Until companies began merging like wildfire.

Today, that same 1000 person company could be acquired by a 10,000 person company. If the assignment language isn’t written appropriately with this in mind, the software vendor may have unwittingly granted an enterprise license that is now for 11,000 people rather than 1,000. As a result, language in software licensing is now adjusted by software vendors to remove the ability to assign (and fewer enterprise licensing schemes are used, too).

But customers do sometimes need the relatively-automatic ability to assign a contract as a result of a merger, acquisition or other transfer of ownership of the organization. Most contract boilerplate language allows for this. Software vendors who are granting site or enterprise licenses, however, should continue to remember that this could lead to the example situation above. Therefore, take the time to perhaps create a “carve-out” whereby an assignment due to this type of transfer would convert the license to a set number of users… or to a very specific geographic location. This still allows for the assignment, but doesn’t open the software usage floodgates.

License Metrics

Technology is a wonderful thing. As a gadget geek myself, I love the latest tech toys. But some of the latest and greatest inventions have had a less-than-positive impact on software licensing. As you might have guessed, multi-processors and/or multi-core processors have tossed a wrench into traditional CPU-based licensing.

Software vendors decide how to license their products based on the estimated value the product will have to the licensee. For mainframe products specifically, and a few others as well, CPU-based licensing has been an easy way to calculate that value. The speed/type of the processor determines the quantity of processing power, thus the amount of processing cycles that can be utilized by the licensed software. So software vendors licensed the product based on the number of CPUs the licensee would want to use to power the software.

This was actually quite an easy metric to choose, both for the vendor and the customer. Easy to track/count by both groups, CPU-based licensing is not affected by fluctuations in users, helping the customer. On the flip-side, vendors could very easily manage a relatively small number of CPUs (usually monitored by CPU serial number), too.

The problem with CPU-based licensing, however, is that until recently, neither vendors NOR customers anticipated multiple processors or cores on a single chip. So once introduced, vendors predictably argued that each processor/core counted as an individual CPU, and customer obviously argued that a single CHIP was an individual CPU. This fundamental difference is a clear example of how contract definitions can prevent problems, as virtually no software license contained an adequate definition to resolve the definitional dispute.

To compound issues, consider the fact that many of these licenses are perpetual with annual maintenance contracts. If there is a lack of clarity with respects to the definition of a CPU, not only do the parties not have a way to know how many copies of the product are authorized to be used, but it also makes the computation of maintenance dollars unclear, too.

It is now imperative that CPU-based software licenses contain a clear and obvious definition with respects to what constitutes a CPU. Oh, and did I mention virtualization? 🙂 What do your licenses say?