Ricochet is the best place on the internet to discuss the issues of the day, either through commenting on posts or writing your own for our active and dynamic community in a fully moderated environment. In addition, the Ricochet Audio Network offers over 50 original podcasts with new episodes released every day.
Quote of the Day: Contracts
“A contract has two main parts that should be spelled out: exactly what you are getting and exactly what you are giving for it. Those two elements are the purpose of the contract. There may be other parts of the contract to set jurisdiction and take care of other legal formalities, but those two parts should be absolutely clear. If they are not clear, if you do not understand these aspects of the contract, it is not yet time to sign.” — H. Sherman Rundles
Sherm Rundles has been one of my Mentors. He is from a generation before mine, just eight months younger than my mother. He “retired” twenty-some years ago from his corporate job and devoted himself to running the side businesses he and his wife had. When I talked to him about a month ago, he was happy to report that in his retirement and nearing eighty, he has finally gotten his workload almost down to sixty hours per week. I learned a lot from him, not only when we were working together, but later as I would visit him at his small business locations where he still holds court. Sherm is a no-nonsense guy. He thinks most things are simple, and the truth is that he’s right.
As I had my own businesses over the last twenty years, I found that his advice was sound, so much so that I am always amazed when I run into someone who doesn’t think that way. For instance, for a time, I was back with a major mega-corp as a consultant. The fellow who was the principal consultant that I was working with didn’t really know what he was talking about at least half the time. He loved using buzz-words, but couldn’t really define them. I was a little reluctant to get involved in yet another engagement with this guy, but then I saw the contract. It was a beautiful contract. It was a gorgeous contract. It spelled everything out perfectly. It said just what we would do and how we would do it. I went into my first meeting with the client with a spring in my step. We were going to do what was really needed, and we were going to do it right.
One of the first things the client said was, “We don’t really want to do that.”
“What? Then why did you sign that contract?” I asked in a severe state of stupefaction.
“Well, we know we want to do business with you, we just don’t want to do this.”
Now, the contract terms, length, and consulting resources gathered for the project had been based on the contract, but why should that bother them? We wound up serving them well, although we did not give them the answers they wanted and expected. We also out-and-out told them they were doing the wrong things for their continued viability. Still, they were happy to do business with us.
Have any tales of contracts and broken hearts to tell? This is the conversation in which to do it.
Published in Group Writing
At most of my employers, the Program Manager is the first line of defense for the techies who aren’t expected to get too far into the contract details. “Do this by then and here is what we hand over at the end.” One of our program managers was more properly termed the program damager. (That was the day only CoC-compliant name for him.)
”No,” I’d frequently tell him.
”This one little change won’t impact the program, will it?”
”Doug, that is the question you should ask me before you agree to changes. No, there won’t be any impact, except to the budget, the schedule, the quality of the finished program, and my sanity.”
So, that’s what happened?
It’s a spectrum.
Most of my career was as an in-house lawyer at large corporations. I wrote and helped to write lots of contracts.
I was amazed at the number of times, late in negotiations, it became apparent that the principal negotiating business people did not have a clear idea of who was to do what when, and what would be an acceptable deliverable.
My pet peeve became the passive voice language that many lawyers like to use (“such and such shall be done by so and so date”). Who is responsible (i.e., who gets blamed if it doesn’t happen)? Often the “such and such” activity required input from both parties. I really pushed to have short, simple subject, active verb, object sentences.
A later pet peeve became the increasing trend to “jointly own” the intellectual property (inventions, software, etc.) resulting from a collaboration. Joint ownership is an administrative nightmare. And if they really insist on joint ownership, at least spell out who will take charge of the administration.
My “favorite” specific instance was when I was not told of a license agreement being negotiated until I was presented with the “final” draft on Friday afternoon before a Monday signing. I discovered “minimum royalties” in several different places in the contract. I added them up, and asked the negotiating business person about the total minimum amount due. He was completely surprised at how large the number was. No one had at any time prior added up the several different minimum amounts due. I got a certain amount of perverse entertainment watching the frantic last minute renegotiation to lower the total minimum without the other party realizing that’s what was being done.
I once worked on a project for AT&T. (I was a sub-contractor of a sub-contractor of a sub-contractor.) They brought in HP to do most of the work. A few months in, AT&T mentioned that of course they would own the IP for the project. HP replied that they probably should have read the contract they signed, because HP policy is that they don’t build anything unless they at least share the IP. And the whole thing ran aground from there.
The project was doomed anyway. The proposed product was questionable, the implementation plan was ridiculous*, and they were probably five years too late starting.
And that, boys and girls, is why you have a debit card in your wallet instead of a stored value cash card.
* They planned six or eight phases. But the plan for each phase was to throw away the work done in the previous phase and start from scratch; new platform, new technology, new design approach.
Your whole comment is singing my song, Tabby. Love the part about the total minimums.
Got it.
yeah, I spent a lot of time asking about contingencies that would reveal whether the business people really understood and had thought about the deal they were putting together.
Interesting that this comes out today.
I just put the finishing touches on the DoD contract “package” for one of the exercises we do.
It’s kind of the exact opposite of the QotD. This contract is unclass, but the tactics, techniques and procedures we’ll be using are not for public dissemination. I know what we’re going to do, whoever bids on the contract will know what we’re going to do, but I had to talk “cagey” building the performance work statement.
And the answer was, no.
Yeah, that is a slightly different situation. But as long as both sides know how to decode it, it still works out the same.
The Song of Arahant–an epic poem of 4550 verses, sung in Norse.
From this description, it looks like there are two types of consultants:
With the second type, the “hired gun” exists to take the blame if the project fails, and management takes the credit if it succeeds.
My guess is that the principal consultant was more of the latter type.
Join other Ricochet members by submitting a Quote of the Day post, the easiest way to start a fun conversation. We have many open dates on the February Schedule. We’ve even include tips for finding great quotes, so choose your favorite quote and sign up today!
Available individually on Amazon.
Does anyone have a story of a contract that didn’t end in heartbreak?
I have one story. Same story on almost all the contracts I worked on*. It was about the Project Plan, which is the mechanics of what I had been committed to do by the Contract.
The billable hours in the Project Plan have to be pared back until they get close to what the Salesman led the Client to believe this all would cost.
When the Customer and the Salesperson ask the PM why this plan is so expensive, they start to look at line items. Design? I thought the software did all this stuff out of the box, right? Coding, well sure, we did want a few minor tweaks. Installation and configuration…Now we are talking! That’s what we pay you guys for. Testing, User Training, yeah, we want some of that.
Wait, what is this Requirements Phase at the beginning? We already told the Salesman the requirements, and he said “no problem”.
The Project Manager tries to be firm. They talk him down to scheduling 4 man-hours for requirements for a major customization of the software for something its never been used for.
When I fly into town, I get a badge and a desk and then its time for Lunch. When we get back…..Time to Start Coding!
To have a successful implementation, you need to spend lots of time up front, in Requirements, and in Design, and a good bit in Detailed Design, before you ever start Coding, Testing, and Rollout. That’s for a typical customized supposedly out-of-the box Database plus Toolkit plus Out-of-the Box application type system.
Most projects fail to meet customer expectations. That’s the dirty secret of the industry. The most important factor by far is lack of clearly communicated requirements.
= = = = = = = =
*Projects from Madrid to far northern Canada (I golfed at midnight on one phase, in June; January wasn’t as nice) to Wellington, NZ and then the end of the world in Invercargill, NZ (next land over the horizon was Antarctica), to Sydney and Brisbane, Newark, NJ (where you didn’t want to be in the parking garage at night if you weren’t armed), to Bath, Maine (where a crack dealer was shot to death by cops right outside my hotel door while I was on the phone with Brown-Eyed-Beauty), to…
Amen, brother. Been there, done that, did it again just for fun. (Or because of idiots doing the negotiations.)
I understand why they don’t appreciate the importance of requirements, communication, and design.
Requirements and design are abstractions. They are theoretical. Coding and implementation are concrete.
We all find concrete thinking easier to understand. Theory, to a concrete thinker, seems like something disconnected from reality, because it is not reality itself.
It requires certain critical thinking skills (especially abstract thinking skills, which I have come to regard as a subset of them) to recognize the importance of starting with abstractions:
Understanding the importance of communication and documentation of what has been communicated also requires certain critical thinking skills, and these have to be learned. At one time, the education system viewed the development of the ability to think as a critical part of its mission. No more.
There was a certain control systems vendor that had a very good standard product, and some very good engineers. But they did not like to deviate from their standard. That has both advantages and disadvanges.
There came a time when we wrote a rather detailed bid specification outlining some functional changes. They bid with no objections, and got the bid based on price. Then they just provided their standard product. “We didn’t think you really meant it.”
We really did, and they got away with it once – but they really lost several million dollar contracts as a result. The issue is trust.
It is difficult for sales and customer people to understand how big some their seemingly small requirements are, and how small their seemingly big ones are.
A good analyst understands the need to get certain basic, seemingly trivial information about the customer’s intended use of the system, information needed to create a data model.
For example, I was always asking something like, “how many gaddle Specs can be on one Framflorg Request?”
To the customer, there was an enormous difference between “10,000” and “two”. And a trivial difference between “two” and “one”.
To the analyst, just the opposite. If the answer is “one”, and it is suddenly revealed when the final product is demo’ed that the answer is “usually one, occasionally two”, there is a catastrophic effect on the project. But to the analyst, “two” and 10,000″ is no difference at all during the data modelling process, which should occur during high-level design, right after Requirements.
A typical project based on out-of-the box products is driven by implementation people, who tend to be blind to the fact that their product has a built-in data model, and not every customer happens to use that model. There is no requirements analyst at all, and the failure to meet customer’s ACTUAL requirements isn’t discovered until it’s too late.
Everyone on the vendor side (who doesn’t think like a requirements analyst, anyway) then has the same reaction: “Well, you don’t seem to understand: that’s not how the system works!”
With music by Jim Trochee.
Nah. Boots Randolph.
I remember years ago hearing a statistic:
Mr. Customer, You vill have to conform to how ve do business.
Is it 1:1, 1:Many, or Many:Many? And ain’t we got fun?
I figured that the data modelers out there would recognize it as a reference to cardinality, and that it those who didn’t wouldn’t lose anything by my failure to mention it. (Once I start talking about anything I never stop, but once I start talking about cardinality I never, ever stop, which is much worse.)
Yep. Some of us can’t help ourselves.
My experience with contracts is a little different. As a musician I sign them, but they are in reality a one-way deal. Sometimes fellow musicians and entertainers get weird about this clause or that clause, but most of them go un-policed or unenforced.
They can use your image and music for example. Well, that’s only a problem if you get famous.
One contract I know of that wasn’t signed by some friends included a clause regarding polyamory. I’m not kidding. Apparently a cast member ( female) created so many problems having relations with other cast members, the next year management felt it necessary to include this prohibition. Of course it’s ridiculous, how would they enforce this? However this person felt like it was a dealbreaker and wouldn’t sign. (Although she had a great act and got hired elsewhere with no problem)
Bottom line for me is, they let many of these requirements slide if they like you, and will use those same things to fire you if they don’t . In my business, if you sue, you will have a very hard time getting hired by anyone again. And they know it.
I wonder if this is generally true in other fields.
Other art fields, yes.
Cardinality sins are the longest sins.
Or the most numerous?