The perils of using someone else’s work

On Saturday in another forum, I noticed a post about boilerplate terms being used in website Terms of Use. The original poster commented that they thought it was quite funny that about 200 websites had all used the same boilerplate language which required any lawsuits to be brought in King County, Washington (where Microsoft is based).

This wouldn’t be nearly as funny if the websites weren’t all based in Australia or New Zealand.

Try this Google search.

Interesting, eh?

Moral of the story? DO NOT USE SOMEONE ELSE’S LANGUAGE UNLESS YOU KNOW THE MEANING AND IMPACT OF EVERY SINGLE WORD!

I understand that we all want to not reinvent the wheel – it doesn’t make sense to redraft an indemnification clause if someone else has already worked up something good. But you’d best understand what you’re including in your contracts.

Now, as for the folks in Australia? Well, I tried sending an e-mail to all of them. I wonder how many will never be read as a result of a spam filter or be dismissed as a joke. [Yep, at least one was taken as a joke and required additional commentary to get them to believe me – and to not think I was soliciting them for something.]

Advertisement

Let’s Make a Deal!

When was the last time you bought something? Today? A few days ago? Do you have the item in your possession now, or did you order it online? At what point in the transaction did you pay for it? I keep twisting these questions over in my head each time I read payment language that wants payment for software at the time of signature.

Of course I can see the vendor’s point. They are granting immediate license to use the product, thus I should pay now as I can have immediate benefit of the license. But for the vast majority of products, some kind of implementation or installation must occur first… and almost always, the vendor is the installer.

In such a case, when should I have to pay? My gut feeling is that I don’t pay until I receive value from that which I have purchased (or will be immediately able to receive value – for those items that are being shipped to me). Which means, in the case of most software – that I shouldn’t pay until installation/implementation is completed.

Again, on the vendor’s side, this is a huge problem. Some implementations can take months. Cash flow is a serious concern for everyone, especially for smaller software vendors. So how do I address the vendor’s concerns of getting paid promptly, while still making sure that I get what I’m paying for?

Know first that this is all a matter of personal preference and corporate choice. Your organization may have no qualms about paying 100% upfront vs 100% at acceptance. But if you do HAVE the choice, I recommend considering the following things:

1. Software which requires installation should not be more than 50% paid for prior to acceptance. If you can’t use it in its un-installed form, it’s not worth anything to you yet.

2. Installations or implementations that take an extended period of time protract the risk for both parties. Decide upon a payment schedule that makes sense given the apportionment of the risk. This means understanding thoroughly the complete deal and where responsibility lies for each task.

3. ALWAYS, ALWAYS, ALWAYS have an acceptance testing procedure and tie the bulk of the fees/payment obligations to successful completion of the LAST acceptance test. My favorite analogy for this is the one about building a house. If everything else is done on the house but the roof isn’t put on properly, do you still want the house? Of course not. Make sure you end up with a completed project.

4. Payment breakdowns can be whatever you wish them to be. Milestone based is my preference.

5. Added to #3 above, make sure you also have the ability to get a full refund in the event that the project is never finished due to the vendor’s behavior. My vendor audience will cry bloody murder about this, but let’s be honest and depersonalize it for a moment. If I was selling you a car, but was doing so in pieces that could only come from me, would you want the body if I didn’t give you the wheels? I doubt it. The same is true with software. Those products which require vendor assistance to install need to be fully installed or the product isn’t worth anything to the buyer.

At the end of the day, however, and like everything else in the contract world, these points are all negotiable. Giving up payment terms for lowered cost – or the inability to get a full refund for a fixed price installation, for example, might be worth the risk.

What odd payment agreements have you made to close your deals? Comment below and lets learn from each other!

Quick Note of Thanks!

Hi.

As this is an off-day for the blog, I thought I would take a few moments to thank all of you who are reading my little notes, tips, tricks and missives. I hope that you’re getting something valuable out of the time you give me – and with each post, I remember those who have come before me and have offered suggestion, comment, praise and criticism, as it is only with the help of those around us do we achieve more than we would on our own.

To that end, I also wanted to take a brief moment to (as personally as I could) thank those of you who have thought highly enough of what I had to say to buy my book. I can’t believe it’s done as well as it has – Lulu tells me that it’s the 492nd most popular item out of 250,000+ works available. Simply incredible. And it’s thanks to you.

So – I’ll look forward to seeing you on Tuesday. Enjoy the rest of your Sunday!

Sign Here ->

One of the greatest inventions of the 20th Century was the Post-It. Created completely by mistake by the awesome folks at 3M, I’m sure all of you use them on a daily basis. In the last few years, 3M has continued to innovate with the Post-It, tape flags being an excellent post-Post-It product. The tape flag style I use most is the “Sign Here ->” flag.

You’ve seen them, right? They have a yellow tab with red writing and a red arrow that you align with the place you’re looking to have someone sign.

I love these little pieces of cellophane for the sole reason that they help get my documents signed. Yes, really.

One would think that contract signatures would be a no-brainer. That somehow folks would understand that without a signed contract, there is potentially no contract at all. But alas, such is not the case. In almost every organization I’ve ever worked, there are almost always a slew of documents that are sitting in the contract files, but aren’t signed.

When I ask about these documents, I get a variety of answers.

“I dunno.”

or

“Oh, we only need THEIR signature…”

or my personal favorite:

“Well, the work was already done, so what did the document matter? Who cares if it was signed?”

I care. I care because I know what can happen when there’s a dispute and no fully executed agreement. I care because I understand that people forget things with time. I care because details matter… and the final steps of closing a deal are just as (and perhaps more) important than those at the beginning.

Get your contracts signed.
Use tape flags, smoke signals, bribes. My most successful method is to hold up payment until I have the fully-executed document. This technique even works from both sides, as the vendor wants to get paid and the customer wants to not be late with payment. So, whomever is “slow” with signature will be prodded by the other for you.

Simple.

Oh, and as long as you’re doing that – get originals, not faxed or e-mailed/scanned copies. Nothing is better in your hands to know that you have your ducks in a row. And if you’ve got your ducks lined up and quacking in unison already, start asking for signatures in blue ink so you can always distinguish originals from copies. Then scan your originals after full execution into a searchable contract management system.

Business of Software

The world is getting smaller by the minute, significantly made possible by the internet. People connect in more ways than ever and it’s interesting to dissect the connections themselves.

Joel Spolsky is a software developer, author, renaissance man. His company, Fog Creek Software, not only produces cool tools, but the company itself is a model for others in how to treat your employees with respect and admiration. He also runs a few websites, among them www.joelonsoftware.com and, as part of that, a discussion board on the Business of Software. Conversations happen on a daily basis between developers and business folks alike – all working on the problems that smaller, usually independent software developers face when creating products.

One of the participants on the the board (and a co-founder of Red Gate Software), Neil Davidson, is helping assemble the 2007 Business of Software Conference. This event is essentially a live version of some of the discussions that happen frequently (plus a lot of bonus material). Additionally, one of my favorite speakers (besides Joel) is going to present this year, Guy Kawasaki.

Feeling a little overconfident, I contacted the organizers and asked if they wanted someone to talk about licensing or negotiation. Come to find out, they have a few slots available – and were going to try something a bit novel to fill them: Software Idol. Each hopeful has 3 minutes to pitch an idea, posted on YouTube. Business of Software newsletter subscribers get to vote. The top three get to come to the conference to present their idea.

It took a few days to arrange, but here’s my submission. Shameless plug: If you’re a Business of Software newsletter member, please vote!

And if you want to attend the conference, I would highly suggest it for almost anyone reading this blog – you’ll learn a lot about the fundamentals of this interesting business.

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!